Skip to content

分诊章程没有「发布是否已上膛」的判据 —— 一个席位据此手打了一个两仓都永不命中的查询,读成了假放行 #17830

Description

@os-musk

由分诊座位(#6015 · R+194,会话 session_015WpYyzhX8x2kEhouLBidt8)立卡,自 objectui#9134 分流而来。⛔ 未认领、未派发。

objectui#9134 已定级(pm:queue · priority:p2 · domain:devx),它承载的是本仓外的那一半:objectui 自己的两份文档教了一个错 title。这一张承载章程的那一半,按 anchoring rule 落点在 .claude/skills/pm-dispatch/**domain:skills,与那张不同仓、不同面,⛔ 不可合并。

缺口,实测

「这张卡会不会被下一次发布关掉窗口」是一个反复出现的定级输入——prioritypm:blocked 都可能挂在它上面。章程里没有任何地方说该怎么测它:

grep -rn "发布窗口\|release window\|changeset 窗口\|changeset-window" .claude/skills/pm-dispatch/
  -> 0
对照  grep -rc "分诊" .claude/skills/pm-dispatch/SKILL.md
  -> 44                      ⇒ 仪器在读这些文件

Version Packages 在章程里只出现 2 次(SKILL.md:34 / :683),两次都是禁令(⛔ 不合并、⛔ 不催),⛔ 没有一次是检测指令。

⇒ 每个席位在需要这个判断时都在现场自己发明一个,而且发明出来的东西没有任何东西会复核。

那次实例

objectui#9065 的 watch 复核(评论 5628564370,2026-09-11T02:31Z)记下:

Second control, for the thing that actually closes the window: open Version Packages PRs in this repo = 0(11 open PRs total)。⇒ no release is staged, so the six cannot ship this minute.」

它被明写成一条 control——即那位席位知道零需要对照,只是对照本身是坏的。当时:

常驻 Changesets 发布 PR 真实 title head
objectui objectui#5400(开了 23 天 chore: release packages changeset-release/main
objectstack #17076 chore: version packages changeset-release/main

两仓都不叫 Version Packages,而且两仓彼此也不同名release vs version)。⇒ 那个查询在任何状态下、任何时刻、两个仓里都恒返 0。它不是读数过期,它是一个永远打不响的查询,而它渲染出来恰好就是提问者想要的那个答案。

正确的判据,以及一个更锋利的形式

head 分支 changeset-release/main —— Changesets action 自己的约定,两仓逐字相同,⛔ 不受 title 配置影响:

is:pr is:open head:changeset-release        # 两仓各返 1

⭐ 但更值得写进章程的是:「发布是否已上膛」本身就是个信息量很低的问题。 只要有任何 pending changeset,那个 PR 就恒开着——它的存在几乎不携带信息。真正携带信息的是本张卡的那条 changeset 是否已经被折进该 PR 的 head,那是对 head 上 CHANGELOG.md 的一次直读,回答的是「离永久还有多远」而不是「发布开始了没有」。

⇒ 建议章程写后者,并把前者标成不充分。

为什么值一张卡而不是一次改词

  1. 它是假放行方向:错的那一侧总是「窗口没关,慢慢来」。
  2. 这个窗口关掉的代价有实测先例:.changeset/seed-locale-axis.md ships two present-tense claims that PR #17013 makes false, and it is queued in the pending release PR #15334 — the correction cannot be made from the PR that falsifies it #17026 —— 发布在立卡 47 分钟后跑掉,两条现在时的假陈述永久留在 packages/spec/CHANGELOG.mdpackages/metadata-protocol/CHANGELOG.md 里。
  3. ⚠️ 那位席位做对了方法论(零配对照),错的是对照的内容。这说明缺的不是纪律而是判据文本——纪律已经在了,它指向了一个不存在的仪器。

验收

  • 章程(SKILL.mdreferences/ 内合适的一篇)写入「发布是否已上膛」的判据,以 head 分支为准,并明写 ⛔ 不得以 title 判定、⛔ 两仓 title 不同且由 action 配置决定。
  • 同处写入上面那个更锋利的形式:对该 PR head 上 CHANGELOG.md 的直读,才回答「这条 changeset 离永久还有多远」。
  • 给出一条可照抄的查询与一条点亮对照(本卡正文两行即可用)。
  • ⛔ 不改任何禁令(⛔ 不合并、⛔ 不催发布 PR 原样保留)。
  • ⛔ 不建台账、不加门。

⛔ 明确未断言

查重:release staged window changeset detection predicate 在本仓返 2(#9500 · #17026),两张都不承载这一类;仪器活(有命中)⇒ 无重复。

Refs:objectui#9134(同源的另一半,本仓外)· objectui#9065(假放行发生处)· objectui#5400 · #17076 · #17026(先例)

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions