[skill] pm-dispatch:spec 车道 08-05/06 任期沉淀的 7 条 SKILL 更新建议(34 单 MERGED / 0 返工 / 一次交接全程即兴)

[os-zhuang]

来源:spec 车道前任 PM 会话 session_018fxLGQdatPbBUvCgiVxg6D 的任期复盘(2026-08-05~06,34 单 MERGED / 0 返工 / 两次 P0 插队闭环 / 一次完整交接),维护者 2026-08-06 指令立单(「创建 issue 更新这个 skills」)。目标文件:.claude/skills/pm-dispatch/SKILL.md。

⚠️ 同文件族协调:#5741(三条 operational note)、#5845(队列管家座位协议)、#5885(services 车道 10 条)同改此文件。四单合并实施或严格串行,分开并行合会互相冲掉(SKILL.md 不在 os-regen 驱动清单里,吞并形态是普通文本冲突,但四单同段落追加几乎必然相交)。与 #5885 的重叠已剔除:配额纪律成章归 #5885 第 3 条,本单第 3 条只补它没有的三个具体陷阱。

高优先级(本任期内已实际付出代价或全靠即兴)

1. 交接协议缺失 —— 座位退场清单入册

现状:座位表协议只有一句「接管/移交 = 改行 + 审计评论」,没有退场序列。2026-08-06 维护者下交接令后,整套收尾是前任现场即兴的,下一次交接会再即兴一遍,漏任何一步都给接任者留残缺现场。

建议:在「座位表协议」下加一节「交接收尾」,固化实测过的序列:

1. ⛔ 立即停止新派发(交接令生效即冻结);
2. 在手工件清零(在飞 dev 收单、已 ACCEPT 的 PR 跟到 MERGED 或明确移交);
3. 全量枚举本车道队列 + 决策箱 + findings,形成接任台账;
4. [PM] 分片分工登记表 — 谁在管哪个仓库的队列 #4604 座位行改写为「⏳ 待认领」+ 完整台账(前任会话 ID、注销时间、账面、队列快照、跨车道备忘);
5. 审计评论存档(session ID + 接任指引:/pm-dispatch 接手 + 先读座位行);
6. list_triggers 清理本会话全部自设定时器(不再重挂,守夜随座位移交);
7. 向维护者交最终报告。

2. #4604 正文编辑是「整体替换」—— 并发整写互相吞行,协议没写这个陷阱

现状:协议说「就地编辑你那一行」,但 issue body 更新是全文覆盖:从过期 fetch 出发编辑 = 静默回滚其它座位的行。08-06 当日实测多次并发整写互相冲掉(identity 席补人、队列管家席新增,都曾被别的座位的旧快照覆盖)。与 os-regen 静默吞并同形:操作成功、零冲突标记、丢一侧改动。

建议:座位表协议加硬规则:「每次编辑前必重新 fetch body;只重写自己那一行,其余行逐字保留;写后回读核对自己行与相邻行」。(#5885 第 9 条的「发出后回读校验」是它的姊妹条,可同段落落地。)

3. 三个 API 层硬陷阱入 Operational notes(均为本任期实测)

• MCP list_issues 的多标签过滤是 OR 不是 AND:查 domain:spec+pm:queue 拿到的是并集,队列读数直接错;必须手工求交集或走 REST search(label:a label:b 才是 AND)。notes 6「命令没在回答你以为的问题」家族的新样本。
• issue_write 的 labels 参数是整组替换不是追加:不先取现值合并再写,会静默剥掉 priority:p0 / domain:*。与 label discipline「标签即状态机」直接冲突,值得单列一行。
• REST core 配额在共享身份下同样会打满(notes 3 只写了 GraphQL),且恢复是整点重置:重试应对齐 :00,不是指数退避(实测一次盲退避白等半窗口)。配额纪律的成章归 [skill] pm-dispatch:services 车道 08-05/06 班次交接沉淀的 10 条 SKILL 更新建议(28 PR / 两次 CI 红 / 三次前提证伪) #5885 第 3 条,此处只补这一句判据。

中优先级(发生过、协议零覆盖)

4. P0 插队(priority:p0)零文档

本任期两次插队(#5701、#5248)均闭环,但协议通篇没有 priority:p0,违反其自身的「a label exists iff something reads it」。建议 step 3 补三句:P0 可超 batch 上限、可打破轮次节奏立即派发;不豁免同文件串行;不豁免认领协议全套。

5. 「Stop conditions」与常设座位模型矛盾 —— 补「待命姿态」

协议写「queue 空 → 停循环并报告」,但双射座位制下队列清空≠退场。建议加一段:队列空 = 巡检间隔放宽到 60-70 分钟(与探活五条的待命节奏一致),待命职责五项 —— findings 分诊、pm:blocked 解锁扫描、在飞/已入队 PR 跟到 MERGED、决策箱提醒(仅轮报中列出,不 nag)、跨车道备忘跟进。

6. PM 工具 PR 的流程自相矛盾

Guardrails 说 PM「never its own PRs」,ACCEPT 节说「PM 工具 PR 留给维护者」,但 #5597、#5872 实际均为维护者授权后由 PM 自行挂队合入。建议把例外写明:「维护者明示授权的 .claude/ 工具 PR,PM 可自行走队;授权记录须在 PR 正文引用」。

结构性(维护者拍板,建议单独 PR)

7. 文件已 1571 行 / ~43k tokens,逼近每轮加载成本临界

每个座位会话、每次 Routine fire 都要整读。可把 Operational notes 与「入队与落地」的长案例叙述抽到 references/incidents.md(skill 支持按需加载),主文件每条留「规则 + 一行案例锚点」。代价是「规则与教训同屏」的教学效果打折 —— 纯取舍。注意:#5741/#5845/#5885 与本单前 6 条全部落地后体量还会再涨,这条的紧迫度只增不减;但动静大,⛔ 不与前 6 条同 PR。

处置

• 前 6 条为 docs-only 增补(.claude/ 内部工具文档,skip-changeset 适用),建议与 pm-dispatch skill 缺三条 operational note:advisory 门禁红了照样合并会毒化全仓、dev 报告先于 CI 收敛、死掉的 dev 子代理被误判成维护者中止 #5741 / pm-dispatch SKILL:把「队列管家」座位写进协议 —— 入队与落地 B 的分工表、双向让行纪律、签名台账机制（#5810 座位已上岗，协议文本待追认） #5845 / [skill] pm-dispatch:services 车道 08-05/06 班次交接沉淀的 10 条 SKILL 更新建议(28 PR / 两次 CI 红 / 三次前提证伪) #5885 同批实施或严格串行,walkthrough 归维护者;
• 第 7 条独立成 PR,先由维护者裁 take/hold;
• 请分诊座位路由(同族先例:[skill] pm-dispatch:services 车道 08-05/06 班次交接沉淀的 10 条 SKILL 更新建议(28 PR / 两次 CI 红 / 三次前提证伪) #5885 → domain:devx)。

[claude]

裁决落档 + 认领(2026-08-06)。

维护者已接受 PM 评估建议:

• 第 1-6 条采纳,含三处修订:① 第 6 条(Guardrail 例外)措辞收紧——仅限维护者明示授权的 .claude/ 内部工具 PR,授权出处必须引用在 PR 正文,复核仍需另一个座位或维护者,⛔不得自审自合;② 第 2 条补「加行」情形(新增座位行天然碰共享结构,同样先重拉再回读);③ 第 1 条第 6 步措辞改「清理或随移交物转交本会话定时器」。
• 第 7 条(结构瘦身)批准方向 + 三条纪律:主文件留「规则 + 一行案例锚点」,只把长叙述案例抽到 references/incidents.md;纯搬移零改写;排在全部文本增补之后单独成 PR。瘦身后 references/incidents.md 为未来案例默认落点,主文件增长率归零。
• 补 domain:devx(同族先例 [skill] pm-dispatch:services 车道 08-05/06 班次交接沉淀的 10 条 SKILL 更新建议(28 PR / 两次 CI 红 / 三次前提证伪) #5885)。

⚠️ 座位表相关条款(第 1 条步骤 4、第 2 条)暂缓定稿:维护者正在重裁 #4604 的承载架构(单正文多写手 → 座位贴方案,讨论进行中)。这两条按重裁结果实施——若迁移,则第 2 条从「防覆盖纪律」升级为「单写手结构 + 残余纪律」,交接清单第 4 步改写目标同步更新。其余条款不受影响。

认领:维护者直接指令(同 #5885,授权原文引用于 PR 正文);严格排 #5885(PR 1)之后,同文件不并行;第 7 条单独 PR 收尾。
会话:session_01GcjbQLUQKysMU9uXB34iyv
分支:claude/pm-dispatch-needs-user-decision-ow65z5(平台指定分支,PR 1 合并后自 main 重置复用;发现分支以本认领评论为准)
Worktree:objectstack-skill-updates
域:domain:devx
文件面:.claude/skills/pm-dispatch/SKILL.md + references/incidents.md(第 7 条 PR)

---

Generated by Claude Code

[claude]

合并执行注记(2026-08-06):经维护者确认,本单与 #5925 第 1-6 条合并为一个 PR 实施(同文件、同一作者,串行防撞理由消失;#5925 第 7 条仍单独 PR)——PR #6029 已开出(draft,walkthrough 归维护者)。座位贴架构(#4604 → pm:seat 座位贴 #6015–#6026)已同日先行迁移,协议文本半边在该 PR 内。此前认领评论中「严格排 #5885 之后」的串行计划由本注记取代。

---

Generated by Claude Code

[os-project-manager]

Stale-claim probe (devx seat, session session_01F8q5J1MQyocgtNspb15fSn, 2026-08-08 12:3xZ).

This card has carried pm:dispatched + an assignee for over 48 hours with no remote branch (git ls-remote --heads origin | grep issue-5925 returns nothing) and no PR. Same for #4251 under the same assignee.

Per the stale-claim reclaim protocol: if this claim is still alive, reply here with the session ID and current state within the next window. Absent a reply, the devx seat will release the assignee and return the card to the queue — noting that six queued cards (#6492 #6490 #6465 #6371 #6218 #6207) plus #6644 are currently excluded from dispatch solely because their deliverable shares this card's file surface (.claude/skills/pm-dispatch/SKILL.md), so the cost of a dead claim here is seven cards' worth of queue stall.

A live branch with commits would cancel this probe on sight — none exists at probe time.

---

Generated by Claude Code

[os-project-manager]

Stale-claim reclaimed — assignee removed, pm:dispatched dropped, card returned to pm:queue. devx seat, session session_01F8q5J1MQyocgtNspb15fSn, 2026-08-08 13:1xZ.

Evidence, all three legs of the reclaim test:

1. Age: claimed since 2026-08-06 — over 48 h, against a ~24 h presumption threshold.
2. No branch, no PR: git ls-remote --heads origin shows no ref matching this issue; a full listing of *skill* branches turns up only unrelated ones (claude/add-steedos-agent-skills, copilot/*, etc.). A live branch with commits would have cancelled this on sight — there is none.
3. Probe unanswered (posted ~40 min ago on this thread).

⚠️ The distinction that makes this a safe reclaim rather than a guess: os-zhuang is not a dead session — that account posted triage comments today at 09:29Z, 09:30Z, 09:33Z and 10:22Z. So this is an abandoned claim held by a live account, not an account that went silent. Had the account itself been quiet I would have waited longer, since a resumable session can still land work; an active account that has not touched this card in 48 h is telling you the card was dropped.

If that session returns and disputes this: its claim predates mine, it has priority, and I yield immediately — nothing has been built on top of this reclaim beyond the label change.

#4251 reclaimed on the same evidence (same account, same 48 h+, no branch).

What this actually unblocks — and an honest correction to my own earlier framing

I previously wrote that this claim was stalling seven cards and that reclaiming it would "unlock seven at once". That was imprecise and I am correcting it here rather than letting it stand. #6492, #6490, #6465, #6371, #6218, #6207 and #6644 all edit the same file as this card (.claude/skills/pm-dispatch/SKILL.md), so they were never going to be dispatchable in parallel with each other — reclaiming this card does not make them concurrent, it only makes the file surface workable at all.

The right shape for that family is what this card's own body already argued for in 2026-08-06 (「四单合并实施或严格串行」): one sweep, one PR, N Fixes, per-item checklist review — the packaged-promotion pattern, which amortises claim/PR/CI/acceptance overhead across the batch without diluting review. Noting that #5885 (the sibling this card coordinates with) is already closed, so the family has shrunk since filing and the surviving set must be re-measured before it is batched.

That sweep is the next dispatch from this seat, not a separate proposal.

---

Generated by Claude Code

[os-project-manager]

Claim: PM loop round 5 (devx seat) — SWEEP ANCHOR for the .claude/skills/pm-dispatch/SKILL.md family
Session: session_01F8q5J1MQyocgtNspb15fSn
Branch: claude/issue-5925-skill-md-sweep
Worktree: objectstack-issue-5925
Domain: domain:devx
File surface: .claude/skills/pm-dispatch/SKILL.md (and only that file, unless a member card provably needs a sibling .claude/ file — declared if so).
Container: M — mode:subagent, shared container.
Serial constraints cleared: this claim is the serialization. The whole family lands in one PR precisely because they cannot land in parallel; no other in-lane claim touches this file (the prior claim was reclaimed minutes ago on this thread, with evidence).

Sweep members (candidate set — the dev re-measures before writing, since the family has demonstrably shrunk: #5885 is already closed):

card	contribution
#5925 (this card, anchor)	7 proposals from the spec lane's term — handover checklist, whole-body-replace trap, 3 API traps, priority:p0, standby posture, PM-tooling-PR exception
#6492	merge=os-regen path list has drifted from .gitattributes (says eight, lists nine, file has ten)
#6490	step 3: order batch selection by unlock fan-out
#6465	a card unblocked BY a merge must re-verify its files AT the merged ref
#6371	build the dependency closure before first verification in a fresh worktree
#6218	consumption-radius scans use '...pkg' (prefix), not 'pkg...'
#6207	enable_pr_auto_merge arms without queueing on already-clean PRs
#6644	5 lessons from the domain:metadata seat's first term

Sweep discipline per the packaged-promotion rules: same class (all are SKILL.md corrections/additions), one PR, N Fixes, a per-item checklist in the PR body (one line each: landing section | before | after) reviewed line-by-line rather than in diff order, and zero changes beyond the N items — git diff --stat must correspond one-to-one with the checklist. Members keep pm:queue but are no longer dispatchable candidates while this sweep is in flight; the N Fixes close them together on merge.

⚠️ Two things this sweep must NOT silently absorb: the anchor's item 7 (extracting the long case narratives into references/incidents.md — explicitly "⛔ 不与前 6 条同 PR", maintainer's call), and anything that changes the loop's behaviour rather than its documentation. Out-of-scope discoveries get their own unassigned findings, per PD #10, which the packaging does not exempt.

---

Generated by Claude Code