Repository navigation
[finding] governed 面的唯一推送通道对 author=os-zhuang 的 PR 失效 —— 「终局四件套」第③条隐含了一个不成立的前提 #10843
Description
由 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、不在任何队列、零推送。唯一还知道它存在的地方是轮次报告 —— 而轮报正是第④条设计来兜底、不是设计来独自承担的。约定把「推送通道仅此一条」写死了,于是这条断掉时没有第二条通道接手。
可能的修法(不替维护者选)
- 约束建 PR 的身份:要求 dev agent 一律以
claude[bot]开 governed PR,把前提变成真。代价:多一条 agent 侧纪律,且靠纪律而非机制。 - 换通道:author 是
os-zhuang时改用@os-zhuang提及式评论(需实测是否同样触发手机推送 ——⚠️ 未验证,不能假设)。 - 接受并显式声明:在四件套里补一句「③ 失败时,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
Activity