Motir

The last family, and the one that only became possible when 11.7 gave these resources a v1 schema to derive from. Until that story lands there is nothing on the other side to align to.

⚠️ On the likely-missing-edge advisory this card carries. Its criteria name 11.7, which is not done, and the detector reads that as a missing blocked_by. The DEPENDENCY is real — this card genuinely cannot be built until those schemas exist — but the edge belongs one level up, not here: 11.7 is a STORY and this is a subtask under a different story, so a blocked_by between them would be a cross-level, cross-parent edge the dependency-arrow rule forbids. It is already wired where it belongs — 11.6 is blocked_by 11.7 — and the readiness cascade holds this card out until that clears. Recorded here so the next reader does not re-derive it.

The tools

dispatch_prompt · mark_integrated · complete_session · expand_item · get_plan_status · get_plan · open_plan_session · append_plan_turn · submit_plan_session · get_work_item_activity.

Six of the eight tools that build structuredContent by hand today live in this family (planSession.ts, dispatchPrompt.ts, getPlan.ts, expandItem.ts, plus the two above) — so proportionally this is where the hand-shaping is densest, and where a second surface has just appeared beside it.

Then SEAL the exemption list

After this card every tool is either derived or exempt, and the exempt set stops being provisional. Confirm it against the shipped tool registry rather than against 11.6.1's draft: the expected members are validate_work_item, validate_sprint, get_project_state and claim_next_ready — but the registry is the authority, and a tool that appears in neither column is the finding this card exists to surface. Walk lib/mcp/registry.ts's registration list, not a remembered set.

Two shapes to get right

• A job handle is not a result. expand_item and submit_plan_session return { jobId, planId } the instant the job is accepted, and a plan holds PROPOSALS, never work items. Whatever schema they derive from must keep that unmistakable — a shape that reads like a completed outcome is a worse lie than a divergent one.
• The activity stream's all cursor is an OPAQUE composite over two sources. It stays one the client can never construct, parse or merge, on both surfaces, and the shared schema must not accidentally describe it as anything a caller could rebuild.

Scope BOUNDARY

Ends at this family plus the sealed exemption list. It does NOT re-base the work-item, project or sprint families (11.6.3 / 11.6.4). It does NOT ship the CI drift guard (11.6.6). It does NOT change what any of these tools DO — no job semantics, no session bookkeeping, no plan lifecycle — only where the payload's shape comes from. It does NOT add a v1 endpoint or widen a v1 schema: if one of 11.7's schemas turns out not to cover what a tool legitimately returns, that is a defect to report against 11.7, not a divergence to keep.

Acceptance criteria

• Every tool listed above builds its structuredContent from 11.7's corresponding schema or a declared narrowing; no hand-authored object remains in planSession.ts, dispatchPrompt.ts, getPlan.ts, expandItem.ts, markIntegrated.ts, completeSession.ts or getWorkItemActivity.ts.
• Each tool's observable payload is UNCHANGED — asserted by tests/mcp/expand-item.test.ts, get-plan.test.ts, plan-session.test.ts, get-work-item-activity.test.ts and integration-state.test.ts passing unmodified.
• dispatch_prompt's optional advisories block derives from the same shape the REST endpoint publishes, including its two shipped severities and its forward-compatible unknown-severity behaviour.
• The submit-shaped tools' schemas make "accepted, not finished" and "proposals, not work items" explicit in the shape itself, not only in prose.
• The activity all cursor round-trips as an opaque value on both surfaces; nothing in the shared schema invites a client to construct one.
• Every tool in lib/mcp/registry.ts is now either schema-derived or carries an exemption entry with a reason — asserted by walking the registry, and a tool in neither column fails the assertion rather than being skipped.
• No file imports both zod and zod/v4.
• The per-file coverage floor (≥90%) holds on every changed file.

Context refs

• 11.7 — the v1 schemas this derives from; its resource module is the source of truth for every shape here.
• 11.6.2 — the seam and the exemption registry this card seals.
• lib/mcp/tools/dispatchPrompt.ts · markIntegrated.ts · completeSession.ts · expandItem.ts · getPlan.ts · planSession.ts · getWorkItemActivity.ts — the subjects; six of the eight hand-built structuredContent sites are here.
• lib/mcp/registry.ts — the authoritative tool list the seal is checked against.
• lib/dto/planChange.ts · lib/dto/plans.ts · lib/dto/activity.ts · lib/dto/comments.ts · lib/dto/dispatch.ts — the DTOs these tools shape today.
• tests/mcp/expand-item.test.ts · get-plan.test.ts · plan-session.test.ts · get-work-item-activity.test.ts · integration-state.test.ts — must pass unmodified.
• Story: 11.6.