[finding][devx] The dev-dispatch model policy lives only in SKILL prose — `os-dev.md` frontmatter has no `model:` pin, so a PM that forgets the parameter silently burns the orchestration model's budget on implementation

[os-project-manager]

Filed by the services-lane PM (session_01USNUyHEr7uaU6MoEWXitei) against its own miss, per Prime Directive #10. Unassigned, for triage. Tooling only (.claude/), no product code.

The policy, and where it lives

.claude/skills/pm-dispatch/SKILL.md §5 (Dispatch), lines 1225-1228:

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.

That sentence is the only place the policy is expressed. .claude/agents/os-dev.md's frontmatter declares name and description and no model: key, so an Agent call that omits the parameter inherits the parent session's model — silently, with no warning and no observable signal at dispatch time.

What that cost today (measured, not hypothetical)

This PM dispatched 11 os-dev agents in one session (#6299 #6199 #6499 #5712 #6444 #6579 #6542 #6587 #6580 #6550 #6654) and passed model on none of them, having missed the clause. All 11 therefore ran on the PM session's model instead of Opus. Per-agent subagent token usage from the dispatch records ranged 84k–283k, well over 2M tokens总计 — the entire implementation load landed on the orchestration model's budget.

Consequences observed in the same session:

• a usage-window cap at ~06:4x–07:20Z terminated three in-flight devs mid-task (all recovered from transcript by probe, no work lost, but ~35 min of lane throughput);
• a model-specific limit later terminated the finding(service-automation): engine.ts's five name-shaped splices — author-metadata / caller-supplied identifiers interpolated into log messages with no newline constraint #6654 dev mid-verification;
• neither failure was diagnosable as a policy miss from inside the dispatch loop — the symptom is a generic limit error, and nothing ties it back to the missing parameter.

Why the fix belongs in the agent definition

The skill's prose is correct and binding, and a PM that reads §5 attentively complies. But the failure mode is asymmetric: complying costs one parameter, forgetting costs an entire session's implementation budget on the wrong model, with the damage invisible until a limit fires. The agent definition already has the slot the harness reads (model: in frontmatter, documented as the default when the Agent call omits the parameter), and it is currently empty.

Options (for triage, not self-decided)

• A — pin it in os-dev.md frontmatter (model: opus). Defense in depth: an omitted parameter then resolves to the policy value rather than to inheritance. The explicit model: "opus" in the SKILL stays (it is still the documented contract and still wins), so nothing about compliant dispatches changes. ⚠️ Check first whether any caller legitimately wants an os-dev on a different tier — a frontmatter pin overrides inheritance for everyone, including non-pm-dispatch callers.
• B — make the SKILL's dispatch template carry it literally, i.e. show the model: "opus" argument inside the copy-paste block rather than in prose above it, so a PM filling the template cannot drop it.
• C — accept as-is: the policy is written down and a careful reader complies; this instance was one PM's misread.

A and B compose (definition pin + template-visible argument) and are cheap; the PM records no ranking beyond noting that C leaves the asymmetry intact.

Related

#6586 (the other dev-dispatch tooling defect from the same session: post-PR report delivery is lossy), #6490 / #6492 / #6465 (pm-dispatch skill family).

[os-project-manager]

重复 #6686