pm-dispatch skill 缺三条 operational note:advisory 门禁红了照样合并会毒化全仓、dev 报告先于 CI 收敛、死掉的 dev 子代理被误判成维护者中止 #5741

来源:cli 车道 PM 会话 session_016FNvXhtSdnEGEfLEsMmvxh 一天实操撞到的三个坑,.claude/skills/pm-dispatch/SKILL.md(1087 行)现状未覆盖。三条都符合该 skill「每条 operational note 是被咬过之后写下的」体例,建议增补为 notes 10–12 + step 7 的一行。按 finding 记录(观察类流程硬化,判级留发现分诊轮),domain:devx(skills/** 归 devx)。

① advisory 门禁红了照样合并、并毒化后续每个 PR(最严重,跨车道损伤)—— 建议 Operational note 10

实测链:PR #5584(callData not-found)的新测试文件触发 check:engine-double-contract(挂在 ESLint job 里),该 job 19:53Z 结论 failure——但 PR 在红了 19 分钟后照常过队合并。合并后,main 上这条红被 merge-ref 带进每一个后续 PR 的 ESLint job,#5601 等直接中招。热修 #5615 才解除,治理侧另立 #5617。

skill 现状为什么防不住:step 7 的 ACCEPT 写「once every check on the PR is green … the queue rebuilds the PR against current main and lands it only if that result is green」。这句话对 required 检查成立,对 advisory(非 required-status-check)门禁不成立——一条不在 required 集里的红门禁,merge queue 的 merge_group 检查集同样看不见它,「队列会把关」这个假设在 advisory 门禁上是假的。Operational notes 1 讲的是「怎么判 PR 在不在队列」,没有任何一条讲「一条 advisory 红门禁会合并进 main 并连累所有人」。

建议 note 10 两句:

• 合并前,PM 必须确认承载门禁族的 job(本仓即 ESLint、TypeScript Type Check——check:engine-double-contract / check:error-code-casing / check:route-envelope 等都跑在 ESLint job 内)已达 completed: success,不是「暂时没 failure」。「every check is green」要读成「每个门禁 job 的结论已出且为 success」,in_progress 不算数。
• 「队列会把关」只对 required 检查成立;advisory 门禁一旦红着合并会毒化 main,是共享损伤,任何车道发现都要立即止血 + 立单(hotfix(runtime): route #5138 test engine doubles through assertEngineDeleteDispatch #5615/红的 ESLint job 没有拦住合并:PR #5584 在 ESLint 已红 19 分钟的情况下过队合入 —— main 的 required-status-check 集需要维护者核查 #5617 即此形)。

② dev 报告先于 CI 收敛就返回 —— 建议 step 7 增一行 + note 10 的配套

①之所以漏,一半原因是 dev 在自己的 ESLint 还没结论时就交了报告(「本地绿」)。本会话此后把「PR 开出后等 CI 收敛再交报告」写进每条派发词并见效(#5644/#5581/#5638 的 dev 都照做了),但这是会话级临时补丁,skill 里没有。

建议:step 7 review 清单加一行——「报告到达 ≠ CI 收敛。arm auto-merge / 入队前,亲核门禁 job 结论(不止 pull_request_read get_status 的聚合,要看 ESLint/type-check 那两个具体 job 的 conclusion)」;os-dev 定义侧对应加「PR 开出后等 CI 收敛再交报告,本地绿不等于 CI 绿」。

③ 死掉的 dev 子代理被误判成「维护者手动中止」,立成不可退的门 —— 建议 note 11

实测:#5085 的 dev 子代理零推送、零分支就没了(子代理正常的 /compact/中断死法)。前任 PM 推断是维护者手动中止,设了「未经维护者明确示意不得重派」的硬门。该门一整天压着一个 p0-邻近的真 bug,直到维护者本人说「我没终止啊」才发现是误判。

skill 现状:step 4 的 stale-claim reclaim 覆盖「死认领」(24h + 无分支 → 回收),「Handing off an interrupted dev」覆盖 /compact 杀子代理——但没有一条区分「dev 子代理自己死了(正常,按 stale-claim 回收)」和「维护者介入了(真 hold)」。把前者误读成后者,就造出一个没有重启条件、谁也不敢退的 pm:on-hold(还违反了 skill 自己「hold 必须带重启条件」的纪律)。

建议 note 11:dev 子代理消失(零推送/零分支/无报告)是子代理的正常死法,按 stale-claim reclaim 处理,不得推断为维护者意图。「维护者中止」只在有维护者显式发话的记录时才成立;没有这条记录就当死认领回收,别升级成不可退的门。

关联:#5617(治理半边——required 集配置,与本单的流程半边互补)、#5584 / #5604 / #5615(① 的实测链)、#5085(③ 的实测)。三条建议都是 skill 文档 + os-dev 定义的定向增补,不改任何产品码。

Filed unassigned、finding,交发现分诊轮判级。