[finding] governed 面的唯一推送通道对 author=os-zhuang 的 PR 失效 —— 「终局四件套」第③条隐含了一个不成立的前提

[claude]

由 domain:devx PM 席(#6023,session session_01DdCnBGcHeufjrq7drTD3wt)在补做四件套第③条时实测发现。未认领,仅记录 —— 修法落在 .claude/skills/**,本身是 governed 面,该由维护者裁定。

约定

.claude/skills/pm-dispatch/SKILL.md:501-510,governed 面 ACCEPT 的「终局四件套」:

③ 在 draft PR 上 request review os-zhuang(维护者 2026-08-19:「还是应该在 pr 的审核流程,发给 os-zhuang 审核。我的手机github 应该会收到推送消息吧」;当日实测 draft 可点名审核且推送到达手机,维护者确认「推送到了」;推送通道仅此一条,同日裁定:「只有需要我审核的pr 推给我。」)—— 「等人合」清单从此活在 GitHub 的 Review-requested 队列,合并自动消项

实测:同一轮三个 governed PR,两成一败,差别只在 author

PR	author	request review os-zhuang
#10718	claude[bot]	✅ 成功
#10777	claude[bot]	✅ 成功
#10837	os-zhuang	❌ failed to request reviewers: Review cannot be requested from pull request author.

GitHub 不允许把审核请求发给 PR 作者本人。dev agent 建 PR 时用哪个身份并不受本约定约束 —— 同一批派发里两种身份都出现了 —— 所以这不是偶发,是只要 author 落在 os-zhuang 就必然复现。

为什么是缺陷而不是小摩擦

四件套的②(留 draft)和③(进 Review-requested 队列)是配套的:②让 PR 停住,③让它看得见地停住。第④条自己写明了失去③的后果:

「等人来合」与「被忘了」在 GitHub 上长得一模一样

第③条失效时,PR 处于:绿的、draft、不在任何队列、零推送。唯一还知道它存在的地方是轮次报告 —— 而轮报正是第④条设计来兜底、不是设计来独自承担的。约定把「推送通道仅此一条」写死了,于是这条断掉时没有第二条通道接手。

可能的修法(不替维护者选)

1. 约束建 PR 的身份:要求 dev agent 一律以 claude[bot] 开 governed PR,把前提变成真。代价:多一条 agent 侧纪律,且靠纪律而非机制。
2. 换通道:author 是 os-zhuang 时改用 @os-zhuang 提及式评论(需实测是否同样触发手机推送 —— ⚠️ 未验证,不能假设)。
3. 接受并显式声明:在四件套里补一句「③ 失败时,PR 必须在轮报的 awaiting-a-human-merge 项里单独标注推送未送达」,把隐性缺口变成显性记录。本轮我已按这个方向在 docs(pm-dispatch): carry UNRECOGNISED gate rows into the round report #10837 上就地记了一条,但那是我的临时处置,不是约定。

⚠️ 三条都改的是 .claude/skills/pm-dispatch/SKILL.md,governed 面,人工合并。

当前受影响

#10837(#9884,轮次报告模板补 UNRECOGNISED 行)—— 内容侧已完成、八族门禁全绿、Check Changeset 补 skip-changeset 后为 skipped;保持 draft、未 arm、未入队,等人工合并,但没有推送发出去。

回链:#10837 · #9884 · #10718 · #10777

---

Generated by Claude Code