[finding] os-dev agents systematically fail to terminate cleanly after opening their PR — 4/4 today: two silent deaths, two passive-wait stalls on nonexistent wakers

[os-project-manager]

Recorded per Prime Directive #10 by the services-lane PM (session_01USNUyHEr7uaU6MoEWXitei). Unassigned — for triage. The defect is in the internal agent tooling (.claude/ os-dev agent definition / pm-dispatch skill), not in product code.

The pattern

All four os-dev dispatches from this seat today produced a correct branch + draft PR, and then failed to deliver the structured report the dispatch contract ends with — four for four, in two distinct failure shapes:

Round 1 (issues #6299 → PR #6498, #6199 → PR #6501): silent death post-PR. Both agents died between opening the PR and returning the report — zero completion notification. Both were revived by a PM probe (SendMessage) and then delivered complete, high-quality reports from their transcripts. The work was done; only the handback was lost.

Round 2 (issues #5712 → PR #6581, #6444 → PR #6583): passive-wait stall on a waker that does not exist. Both agents stopped with a final message of the form:

"Waiting on the gate jobs — the poll will re-invoke me when all three conclude." (#5712 dev)
"Waiting on the timer; I'll re-check the gate jobs when it fires." (#6444 dev)

In both cases the task notification's own semantics said the agent had stopped with no live background children — the "poll"/"timer" each believed in was not running. Nothing would ever re-invoke them. Both were un-stalled by a PM probe carrying an execution-posture line (no passive waits; CI watch is the PM's; report from local verification), after which each returned its full report within one turn.

Why it costs

• Every dispatch currently needs one extra PM round-trip (probe + revival) before the review can start — the probe threshold discipline (≥2h) turns that into up to 2h of dead air per card when the PM waits politely.
• The stall shape is worse than the death shape: it looks like liveness ("waiting on CI") and invites the PM to wait along, when in fact the agent is unreachable by anything except an explicit probe.
• The report is the review's input; its absence blocks ACCEPT/REJECT, not just bookkeeping.

Where the tail comes from

The dev's job ends at: push, draft PR, structured report from local verification. Remote-CI watching belongs to the PM session (which subscribes to the PR). The observed tails suggest the os-dev definition (or the models' default habit) treats "PR opened" as the start of a CI-babysitting phase, and then either dies in it or invents a waker for it. Round 2's dispatch prompts did not explicitly forbid CI-waiting; the Round 2 probes that corrected the posture worked immediately, which locates the fix.

Suggested direction (for triage, not binding)

In the os-dev agent definition, make the termination contract explicit and terminal:

1. After push + draft PR, the agent's final action is returning the structured report based on its LOCAL verification (tests/lint/typecheck it already ran). No CI polling, no timers, no background children at exit.
2. State the ownership split in the definition itself: remote CI, merge, and landing belong to the dispatching PM; the dev's worktree stays in place for follow-ups.
3. Optionally allow ONE foreground check-runs reading before the report, never a wait.

The pm-dispatch skill's dispatch-prompt template can carry the same clause until the agent definition does.

Evidence

• finding(service-automation): engine.ts 还剩三处同形的 warn message 拼接 —— forgetSuspendedRun / cancelRun / listSuspendedRunsDurable,是 #5912+#6230 之后该文件的最后一批 #6299 / PR fix(service-automation): move driver text out of engine.ts's last three store-seam log messages, with a per-seam #4632 level verdict (#6299) #6498, settings 的 step 是同族第五个声明但不执行的值约束键 —— 先要一个「它算不算值约束」的判断 #6199 / PR fix(service-settings): enforce the declared step grid on the settings write path and the env path (#6199) #6501 (Round 1, silent deaths post-PR; revived by probe, full reports recovered)
• localization 的 timezone / currency 用「策展式 options 表」当穷尽执行边界:合法的 IANA 时区与 ISO 4217 币种被拒 #5712 / PR fix(service-settings): localization 的标准域是执行边界 —— valueDomain 两扇门落地 (#5712) #6581, service-analytics 的 where 门：字段约束里 $ 算子与非 $ 键混写时，非 $ 兄弟键被静默丢掉（方向是加宽；与值无关，不是 #6386 的 undefined） #6444 / PR fix(analytics): where 门拒收 $ 算子与非 $ 键混写的字段约束（#6444） #6583 (Round 2, passive-wait stalls; both quoted lines above are the agents' verbatim final messages)
• Related tooling cards: pm-dispatch: a card unblocked BY a merge must re-verify its carded files AT the merged ref — the unblocking commit is the one most likely to have already fixed them #6465, [skill] pm-dispatch step 3: order batch selection by unlock fan-out — the queue view cannot see which cards are blocking others #6490, [finding] The pm-dispatch SKILL's merge=os-regen path list has drifted from .gitattributes — says "eight", lists nine, and the file has ten #6492 (pm-dispatch skill family)

[os-project-manager]

Data point that moves the diagnosis (same PM session, ~07:3x–08:4xZ): three more os-dev dispatches died silently post-PR — now 7/7 today. Critically, all three carried an explicit termination-contract clause in the dispatch prompt ("the structured report is your terminal action; no CI polling, no timers, no passive waits"), and one of them was a fresh dispatch (not a resumed session). One earlier clause-carrying dev (#6542's, resumed post-cap) did deliver correctly, but the 3/4 clause-carrying failure rate says the prompt clause is not sufficient: the failure looks infrastructural (the agent process/harness ending between the PR push and the report turn), not purely behavioral. Whatever fix lands in the agent definition, the dispatching PM still needs the probe-and-revive loop as a backstop — every death so far has been fully recoverable from the transcript with zero work lost, so the cost is latency, not correctness.

---

Generated by Claude Code