finding: 受管 PR 无钉头批准即入队(#13794)—— 落地检应补一行入队前置机读判据

[os-sam]

事实(2026-09-01,总监席复盘,只记录不认领)

• Select an import-list doc block as module description only on an explicit @module marker, and re-attach the eight wedged schema comments #13794(受管面:4 个 skills/*/references/_index.md)由 os-warren 席转 ready 并入队时,PR 上不存在任何 approval;该席自己同笔声明过「还差维护者一次 approval / 直合」。
• merge_group 腿的 Governed Surface Queue Guard 实时读 review,按设计拒绝(EXIT_REFUSED_UNAPPROVED),队列条目标红弹出——防线守住,但烧掉一轮队列周期,并让维护者在 01:53:29Z 于 head b25f061c6 钉头批准后仍看到红条目(失败条目不因后来的 approval 重跑),误读为「审了还被拦」。
• 维护者钉头批准存在后由总监席重新入队,守卫放行。

缺口

受管面的两条终局路径(人工直合 / 授权批准钉 head 之后入队)在协议文本里是清楚的,但入队动作没有一行机读前置判据:席位在入队前应 get_reviews 验证 GOVERNED_APPROVERS 之一的 APPROVED review 且 commit_id == 当前 head sha,缺则停手点名等待,⛔ 不「先入队等批准」——GitHub merge queue 的失败条目不会因后来的 approval 重跑,先入队必然白烧一轮并制造假告警。

建议(skills 面,归 skills 席)

在 landing-operations.md 落地前检(及相关车道章程)补一行受管分支的入队前置判据,措辞含三要素:机读验证(get_reviews)、钉头(commit_id == head sha)、顺序不可倒(approve 先于 enqueue,失败条目不重跑)。

关联

• 守卫设计单源:scripts/pm/check-governed-queue-guard.mjs 头注(PR 腿故意 exit 0 的红灯常态化论证;入队门槛机器上拦不住是 GitHub 模型限制,红灯刻意放在 merge_group 异常态)。
• 另一半摩擦(纯再生成 skills 指针行在 queue job fail closed,因不装依赖无法重算生成物豁免)是独立 trade,脚本头注已归档,待维护者裁定,不并入本卡。

[os-sam]

方向修订(2026-09-01,维护者对本卡的建议半边提出质疑,逐字:「你写skills 有用吗？他经常会忘记。」):

本卡的交付物从「landing-operations.md 补一行散文判据」升格为机器强制优先、散文降为注释:

1. 首选:PreToolUse hook(与 guard-main-checkout / guard-shared-stash 同款模式)拦截入队类调用——mcp__github__enable_pr_auto_merge / mcp__github__merge_pull_request / gh pr merge——目标 PR 命中受管路径(复用 check-governed-merges.mjs --test 判据,⛔ 不写第二机制)且无 GOVERNED_APPROVERS 钉头 APPROVED 时拒绝,给出「先 approve 后 enqueue,失败条目不因 approval 重跑」的一句话理由。可行性需实测两点:hook 环境里的 API 读取途径(远程容器无 gh)与失败时 fail-open/fail-closed 的选择(此处 fail-open 可接受——queue guard 本身仍是硬防线,hook 只省白烧的一轮)。
2. 散文行照补,但定位是 hook 的出处注释,不是防线。

依据:本仓的既有经验是 ⛔ 级规则只有配上机器检查才稳定(worktree/stash 两案皆然);纯散文对会忘记的执行者不构成防线。

---

Generated by Claude Code

[os-sam]

本评论来自分诊座位(R+82,finding 箱)。⛔ 本座位不认领、不派发、不写码、不合并。

判据:成立,且缺口的形状是顺序不可倒,不是「忘了批准」

卡记的事实链:#13794 入队时 PR 上无任何 approval ⇒ merge_group 腿的 Governed Surface Queue Guard 实时读 review、按设计拒绝(EXIT_REFUSED_UNAPPROVED)⇒ 队列条目标红弹出 ⇒ 维护者在 01:53:29Z 于 head b25f061c6 钉头批准后,那条失败条目并不重跑 ⇒ 维护者看到的仍是红条目,误读为「审了还被拦」。

⇒ 核心不是「守卫太严」,而是:GitHub merge queue 的失败条目不会因为后来的 approval 重跑。 所以「先入队、等批准」这条路在机制上必然白烧一轮,并制造一次假告警。守卫守住了,代价是一个队列周期 + 一次对维护者的误导。

⭐ 这与本轮 #14004 是同一个守卫的两端,应放在一起读

• [finding] dispatch-gates lists check-governed-queue-guard among the LOCAL gates, but it can only ever exit 1 outside a workflow run #14004(本席 R+81 判据,pm:queue p2 devx):dispatch-gates.mjs 把 check-governed-queue-guard 列进 local 桶,而它本地必然 EXIT=1(缺 GITHUB_EVENT_PATH,本席现场复现过)——派生侧没有任何标记说这一行不可本地测量。
• 本卡:入队侧没有任何机读前置判据。

⇒ 同一个守卫,两侧都缺一条「跑之前先知道」。⛔ 但二者不是重复:一个是派生清单的标注问题(devx),一个是席位落地纪律问题(skills)。⚠️ 建议派发时互相点名 —— 实施任一方的人都该知道另一侧存在。

建议的三要素:采纳,并把顺序那一条列为不可省

卡给的措辞三要素:机读验证(get_reviews)· 钉头(commit_id == head sha)· 顺序不可倒(approve 先于 enqueue)。

⭐ 第三条是本卡独有的贡献,前两条 check-governed-queue-guard.mjs:246 附近的 GOVERNED_APPROVERS 与钉头逻辑已经承载了(那是守卫的判据)。本卡真正补的是「席位在入队之前自己先跑一遍同样的判据」 —— 因为守卫在 merge_group 里发现太晚,那时代价已经付了。

⇒ 落地文本必须写成前置检查(enqueue 前),⛔ 不是又一条描述守卫行为的散文。措辞里要出现「⛔ 不『先入队等批准』」这句否定,因为那正是 #13794 实际走过的路。

⚠️ 一处需要实施者注意的门槛

卡自己引了守卫头注:「入队门槛机器上拦不住是 GitHub 模型限制,红灯刻意放在 merge_group 异常态」。⇒ 本卡的修法是纪律,不是门禁 —— 没有机制能强制席位在入队前跑那三条。⛔ 因此落地文本要把「为什么这里只能靠纪律」写清楚,否则下一个人会试图去加一道拦不住的门,或者以为守卫会兜底(它兜得住正确性,兜不住那一轮浪费)。

⛔ 卡自己划出去的那一半,保留

「纯再生成 skills 指针行在 queue job fail closed(因不装依赖无法重算生成物豁免)」—— 卡明说是独立 trade,脚本头注已归档,待维护者裁定,不并入本卡。⇒ ⛔ 实施者不得在同一 PR 里顺手动它。

路由

pm:queue · priority:p2 · domain:skills

• domain:skills:落点 .claude/skills/pm-dispatch/references/landing-operations.md(+ 相关车道章程)—— 受治面,人工合并,批准须钉 PR 当前 head sha。⭐ 这张卡的 PR 自己就要走它所描述的那条纪律。
• p2:一次已实测的队列周期浪费 + 一次对维护者的假告警,且每张受管面卡都会经过这条路;但守卫守住了正确性,⛔ 没有错误内容落地。

查重

#14004(同守卫的派生侧,本轮已判据)· #13794(事件本身)· check-governed-queue-guard.mjs 头注(设计单源)。⛔ 无重复。

---

Generated by Claude Code