Motir

The five methods behind motir plan, ported onto 11.5.3's transport and 11.5.4's adapter layer.

Carved out of 11.5.5 by the 2026-08-07 story re-plan, which found that card at 8 points carrying ten methods. These five drive a different command, hold different invariants, and share no state with the dispatch loop — so they are a card, not a tail.

All five endpoints shipped with 11.7 (done) — read every shape off that story's schema module, never off the MCP tool.

Semantics to preserve exactly

• Appending is NOT submitting. appendPlanTurn persists a turn and starts no job and spends no credits; submitPlanSession sends the accumulated thread and returns a job handle. The two are one keystroke apart in the CLI and a paid job apart in effect, so they are asserted separately.
• A plan is PROPOSALS. Nothing here creates a work item. getPlan returns what was proposed; materializing is a different surface entirely, and no method on this card writes to the tree.
• No method WAITS for the planner. submitPlanSession returns a handle and getPlanStatus is polled by the command; a port that quietly awaits completion inside the client turns a responsive terminal into one that hangs on a long generation.
• getPlanStatus is polled, so its errors are not fatal by default — the command decides what a transient failure means, and the client reports rather than retries.

Scope BOUNDARY

Ends at these five methods. It MAY change commands/plan.ts — but only a line that consumes a view-model field this card changed, and never an output string (the boundary the re-plan gave every port card in this story). It does NOT port the dispatch / session methods (11.5.5) or the reads (11.5.4). It does NOT touch searchWorkItems, whose total reader in plan.ts:163 is 11.5.17's. It does NOT delete the MCP transport or the SDK (11.5.6). It does NOT add, rename or reshape an endpoint — if an 11.7 endpoint does not fit, that is a defect to report against 11.7, not to route around here.

Acceptance criteria

• All five methods call /api/v1 through the transport core; no MCP tool call remains on the planning-conversation paths.
• motir plan produces output identical to the MCP-era implementation for the same data — asserted by the existing command-level tests with their assertion strings unchanged.
• Appending a plan turn starts no job and creates no work item — asserted by driving a real append and reading back both the job surface and the tree.
• Submitting returns a job handle WITHOUT waiting on the planner — asserted by a submit that resolves while the job is still running.
• A plan read returns proposals and creates nothing in the tree.
• The per-file coverage floor (≥90%) holds on every new and modified file.

Context refs

• 11.7 — the endpoints and response schemas; the source of truth for every shape this card consumes.
• 11.5.3 — the transport. 11.5.4 — the adapter module these extend.
• packages/cli/src/mcpClient.ts — the five wrappers and, in their doc comments, every semantic above; PlanSession, PlanTurn, PlanSubmitResult, PlanJobState, PlanOutcome, PlanProposal, PlanWithItems.
• packages/cli/src/commands/plan.ts · packages/cli/src/plan.ts — the call sites and the proposal-tree renderer.
• lib/mcp/tools/planSession.ts · getPlan.ts — the services behind the endpoints, useful for the semantics; NOT the wire contract.
• Story: 11.5.