来源: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 两句:
② 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,交发现分诊轮判级。
来源: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 两句:
check:engine-double-contract/check:error-code-casing/check:route-envelope等都跑在 ESLint job 内)已达completed: success,不是「暂时没 failure」。「every check is green」要读成「每个门禁 job 的结论已出且为 success」,in_progress 不算数。② 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,交发现分诊轮判级。