由分诊座位(#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,与那张不同仓、不同面,⛔ 不可合并。
缺口,实测
「这张卡会不会被下一次发布关掉窗口」是一个反复出现的定级输入 ——priority 和 pm: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 的一次直读,回答的是「离永久还有多远」而不是「发布开始了没有」。
⇒ 建议章程写后者,并把前者标成不充分。
为什么值一张卡而不是一次改词
它是假放行 方向:错的那一侧总是「窗口没关,慢慢来」。
这个窗口关掉的代价有实测先例:.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.md 与 packages/metadata-protocol/CHANGELOG.md 里。
⚠️ 那位席位做对了方法论 (零配对照),错的是对照的内容。这说明缺的不是纪律而是判据文本 ——纪律已经在了,它指向了一个不存在的仪器。
验收
章程(SKILL.md 或 references/ 内合适的一篇)写入「发布是否已上膛」的判据,以 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 (先例)
由分诊座位(#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,与那张不同仓、不同面,⛔ 不可合并。缺口,实测
「这张卡会不会被下一次发布关掉窗口」是一个反复出现的定级输入——
priority和pm:blocked都可能挂在它上面。章程里没有任何地方说该怎么测它:Version Packages在章程里只出现 2 次(SKILL.md:34 / :683),两次都是禁令(⛔ 不合并、⛔ 不催),⛔ 没有一次是检测指令。⇒ 每个席位在需要这个判断时都在现场自己发明一个,而且发明出来的东西没有任何东西会复核。
那次实例
objectui#9065 的 watch 复核(评论
5628564370,2026-09-11T02:31Z)记下:它被明写成一条 control——即那位席位知道零需要对照,只是对照本身是坏的。当时:
chore: release packageschangeset-release/mainchore: version packageschangeset-release/main两仓都不叫
Version Packages,而且两仓彼此也不同名(releasevsversion)。⇒ 那个查询在任何状态下、任何时刻、两个仓里都恒返 0。它不是读数过期,它是一个永远打不响的查询,而它渲染出来恰好就是提问者想要的那个答案。正确的判据,以及一个更锋利的形式
✅ head 分支
changeset-release/main—— Changesets action 自己的约定,两仓逐字相同,⛔ 不受 title 配置影响:⭐ 但更值得写进章程的是:「发布是否已上膛」本身就是个信息量很低的问题。 只要有任何 pending changeset,那个 PR 就恒开着——它的存在几乎不携带信息。真正携带信息的是本张卡的那条 changeset 是否已经被折进该 PR 的 head,那是对 head 上
CHANGELOG.md的一次直读,回答的是「离永久还有多远」而不是「发布开始了没有」。⇒ 建议章程写后者,并把前者标成不充分。
为什么值一张卡而不是一次改词
.changeset/seed-locale-axis.mdships 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.md与packages/metadata-protocol/CHANGELOG.md里。验收
SKILL.md或references/内合适的一篇)写入「发布是否已上膛」的判据,以 head 分支为准,并明写 ⛔ 不得以 title 判定、⛔ 两仓 title 不同且由 action 配置决定。CHANGELOG.md的直读,才回答「这条 changeset 离永久还有多远」。⛔ 明确未断言
.changeset/seed-locale-axis.mdships 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 的损失由这一类检查造成;它只作为「窗口关掉值多少钱」的实测先例被引用。查重:
release staged window changeset detection predicate在本仓返 2(#9500 · #17026),两张都不承载这一类;仪器活(有命中)⇒ 无重复。Refs:objectui#9134(同源的另一半,本仓外)· objectui#9065(假放行发生处)· objectui#5400 · #17076 · #17026(先例)