feat(agents): pm-dispatch 首轮实跑经验回写 — 认领协议、跨仓查重、决策落原 issue、开发模型策略 (#4554)

* feat(agents): pm-dispatch round-1 lessons — claim protocol, cross-repo dedup, escalate-on-issue, dev model policy

Four mechanics hardened from the first live dispatch round:

- Claim protocol: shared GitHub identity means assignee alone cannot say
  WHICH agent claimed — a fixed-shape claim comment (round + branch name)
  carries identity, a comment read-back settles races (first comment
  wins), early branch push closes the claimed-but-invisible gap, and
  stale claims (24h, no branch, no PR) are reclaimed after inquiry.
- Cross-repo dedup at triage: follow cross-references and keyword-search
  sibling repos for an issue's shadow; claimed shadow blocks dispatch,
  unclaimed shadow converges to one entry first, done shadow triggers a
  staleness check. The main backlog stays the only scheduling authority.
- Escalation lands ON the issue it belongs to (analysis comment +
  needs-user-decision label as the maintainer's inbox); a separate
  [decision] issue only when no natural anchor exists — decision cards
  no longer accumulate.
- Dev dispatches pass model: opus; the PM session keeps the stronger
  orchestration model (maintainer policy).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012C2cd7tL8QDoZ2QKN3djJ5

* feat(agents): pm-dispatch merge policy — accepted, fully-green dev PRs land via the merge queue

Maintainer policy: once the PM's review verdict is ACCEPT and every CI
check is green, the PM marks the dev-agent PR ready and adds it to the
merge queue (the repo's sanctioned path — the queue lands it only if the
rebuild against current main is green). Scope-limited: dev-agent PRs
dispatched by this loop only; the PM's own tooling PRs stay with the
maintainer; no red, unreviewed, or queue-bypassing merges.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012C2cd7tL8QDoZ2QKN3djJ5

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: os-zhuang

.changeset/pm-dispatch-round1-lessons.md

@@ -0,0 +1,4 @@
+---
+---
+
+Internal agent tooling only (`.claude/` pm-dispatch claim protocol, cross-repo dedup, escalation-on-issue, dev-model policy) — releases nothing.

.claude/skills/pm-dispatch/SKILL.md

@@ -149,6 +149,25 @@ routing isn't already decided:
   maintainer.** If after reading the code you genuinely cannot tell where a
   change lands, the issue is underspecified: escalate the *underlying
   product question* (step 8), not the routing.
+- **Cross-repo dedup — check the sibling repos for this issue's shadow**
+  before it can be dispatched: follow every cross-repo reference on the
+  issue's body/timeline, AND keyword-search open issues/PRs in the other two
+  repos (module names, error strings). What you find decides the action:
+  - shadow **claimed / PR in flight** → do not dispatch; write
+    `Blocked-by: <repo>#<n>` + a comment, revisit for *remaining* work when
+    it lands;
+  - shadow **open, unclaimed** → converge first: cross-link, make it a
+    sub-issue of the backlog issue (or close one as duplicate) so one thing
+    has exactly one dispatch entry — then queue normally;
+  - shadow **already done** → the backlog issue may be stale: verify what
+    remains, recommend closing if nothing does;
+  - **nothing found** → dispatch normally.
+  The main backlog is the only scheduling authority — two queues must never
+  dispatch the same work. Re-verify assignees (issue *and* linked shadows)
+  at claim time, not just at triage: the gap between them is where races
+  live. Known blind spot: work in a local worktree with no claim, no
+  branch, no PR is invisible — that is what the claim-first rule (step 4)
+  exists to shrink.
 
 ### 3. Select the batch
 
@@ -162,16 +181,40 @@ not dispatch.
 
 ### 4. Claim
 
-For each selected issue, **before dispatching** (repo rule: claim before code):
-assign it to yourself (`@me`) and add labels + a comment in Chinese, e.g.
-「已由 PM 循环派发给开发 agent(第 N 轮)。」Skip — and drop from the batch —
-any issue that acquired an assignee since step 1.
+All agents share one GitHub identity, so the assignee alone says "some agent
+claimed this" but never *which* — the claim comment carries the identity. For
+each selected issue, **before dispatching** (repo rule: claim before code),
+execute atomically, in order:
+
+1. **Assign** to yourself (`@me`) and add `pm:dispatched`. Skip — and drop
+   from the batch — any issue that acquired an assignee since step 1.
+2. **Claim comment** (Chinese), fixed shape — the branch name is the key,
+   every later artifact (worktree, push, PR) hangs off it:
+   > 认领:PM 循环第 N 轮
+   > 分支:`claude/issue-<n>-<slug>`
+   > Worktree:`<repo>-issue-<n>`
+3. **Race check**: assignment is idempotent, so two agents can both
+   "succeed". Re-read the comments; if an earlier claim comment with a
+   *different* branch name exists, you lost — touch nothing of theirs,
+   reply 「已有认领,让行」, and pick another issue. First comment wins.
+
+Dev agents push their branch early — a remote branch is the hardest evidence
+of work in flight, closing the gap between "claimed" and "PR exists".
+
+**Stale-claim reclaim**: a claim older than ~24 h whose promised branch does
+not exist on the remote and has no PR is presumed dead — comment asking, and
+after another window of silence, remove the assignee (note why) and return
+the issue to the queue. Never reclaim a claim that has a live branch with
+commits.
 
 ### 5. Dispatch
 
 One `Agent` call per issue, `subagent_type: "os-dev"` (fall back to
 `general-purpose` with the same prompt if the custom agent isn't loaded), run
-in parallel in the background. Prompt template — fill every placeholder, paste
+in parallel in the background. **Model split (maintainer policy): pass
+`model: "opus"` on every dev dispatch.** The PM session itself stays on the
+stronger orchestration model — triage, review, and decision framing are where
+its judgment pays; implementation goes to Opus. Prompt template — fill every placeholder, paste
 the full issue body, never a summary:
 
 ```
@@ -255,9 +298,14 @@ against the report's own claims:
 Verdict per issue:
 
 - **ACCEPT** — comment on the issue (Chinese) linking the PR and summarizing
-  what shipped; leave the PR for the normal human/merge-queue review flow.
-  **The PM never merges** — merge discipline (CI-green, serial/queue) belongs
-  to the repo, not this loop.
+  what shipped. Then drive it to landing (maintainer policy: review passed +
+  CI green ⇒ merge): once every check on the PR is green, mark it ready for
+  review and **add it to the merge queue** — the queue rebuilds the PR
+  against current `main` and lands it only if that result is green, which is
+  the repo's sanctioned path. Never `--auto`-merge outside the queue; where
+  no queue exists, merge serially per AGENTS.md §7 only after remote CI is
+  fully green. This applies to **dev-agent PRs dispatched by this loop
+  only** — the PM's own tooling PRs stay with the maintainer.
 - **REWORK** — concrete, itemized feedback; re-dispatch the same issue with
   the feedback block filled (same claim, new dev agent). **Max 2 rework
   rounds** per issue; a third failure escalates instead.
@@ -268,10 +316,19 @@ Verdict per issue:
 Whenever a dev returns `needs_decision`, an issue is too vague to dispatch, or
 rework has failed twice:
 
-1. **File a new issue** titled `[决策] <一句话说清要拍板什么>`, labeled
-   `needs-user-decision`, body in Chinese: 背景、具体问题、可选方案、你的
-   建议、关联的原 issue / PR / 分支。**每个方案必须沿两条固定评估轴分析,
-   这是决策分析的核心原则,不是可选项:**
+1. **Default: the decision lives ON the issue it belongs to — never a new
+   issue.** Post the analysis as a comment on that issue, add the
+   `needs-user-decision` label, drop it from the active queue. The label is
+   the maintainer's inbox (filter `label:needs-user-decision` shows
+   everything awaiting them); when they answer, the label comes off and the
+   issue re-enters the queue. No bookkeeping issues accumulate. File a
+   separate issue (titled `[决策] <一句话说清要拍板什么>`, same label) ONLY
+   when the decision has no natural anchor — it spans several issues (file
+   one, link it from each rather than duplicating the analysis) or arose
+   with no issue of its own.
+2. The analysis, wherever it lands (Chinese): 背景、具体问题、可选方案、
+   你的建议、关联的 issue / PR / 分支。**每个方案必须沿两条固定评估轴
+   分析,这是决策分析的核心原则,不是可选项:**
    - **项目长远合理性** — 哪个方案符合北极星方向与可持续架构(Prime
      Directive #5 no workarounds、#8 North Star、#12 contract-first),
      而不是眼下最省事;临时补丁式的选项要明说其长期代价。
@@ -282,11 +339,9 @@ rework has failed twice:
      绝不让 AI 能声明一个运行时不兑现的能力。
    推荐意见必须基于这两条轴给出理由;两轴冲突时如实呈现权衡,交维护者
    拍板。
-2. Comment on the original issue linking the decision issue, add
-   `needs-user-decision` to it too, and drop it from the active queue.
 3. If the session is interactive, additionally raise it via `AskUserQuestion`;
-   the filed issue remains the durable record either way. **Never** answer a
-   product/architecture question on the maintainer's behalf.
+   the labeled issue remains the durable record either way. **Never** answer
+   a product/architecture question on the maintainer's behalf.
 
 ### 9. Round report, then next round
 
@@ -307,7 +362,10 @@ Stop the loop and report when any of these hits:
 
 ## Guardrails (binding)
 
-- PM writes **no files** and merges **no PRs**. No exceptions.
+- PM writes **no files**. Merging is allowed for **reviewed, fully-green
+  dev-agent PRs via the merge queue only** (see the ACCEPT verdict) — never
+  its own PRs, never a red or unreviewed one, never bypassing the queue
+  where one exists.
 - Never force-push, never push `main`, never reassign an issue claimed by
   someone else, never dispatch a `needs-user-decision` issue.
 - Every dev agent works in its **own worktree per repo** (enforced by