Skip to content

moooon

Motir

Vibe your whole project. Bring an idea — Motir's three AI layers plan it, track it, and ship it, end to end. You're looking at Motir, built in Motir.

  • Vibe Project
  • Open Source
  • AI Agent
  • AI Loop
1
requests
0
upvotes
145
planned
1,361
shipped

Motir · Work items

MOTIR-2213Done

11.5.5 The DISPATCH + SESSION methods over `/api/v1` — transitions, the prompt read, integration and session close-out

⚠️ RE-PLANNED 2026-08-07 (story-level). This card was 8 points and carried TEN methods plus a command-file migration; it now carries FIVE.

  • nextReady and the exclusion migration LEFT11.5.19 moves the exclude list to key, on the transport that ships today. That work was parked here because 11.5.4's boundary forbade command-file edits; the boundary was the defect (the planning bug), and the work turned out not to need this card's endpoints at all.

    ⚠️ CORRECTED 2026-08-07 — the referrer sweep this re-plan owed (MOTIR-2399, notes.html #240). This bullet originally read "11.5.19 retires next_ready outright and moves the exclude list to key", and it was true when written (00:45:41Z). At 01:07:38Z — 21m57s later — 11.5.19 re-scoped ITSELF out of the port and handed it back here in prose, without editing this card. Neither card's acceptance criteria then contained it, and nextReady reached 11.5.6 unported. The port is 11.5.23.

  • The PLANNING CONVERSATION methods LEFT to 11.5.20 — five methods with their own command, their own semantics and no shared state with these five. At 8 points this card was over the estimation gate's split line before either change.

The five methods that make motir run, motir auto and motir batch work, ported onto 11.5.3's transport and 11.5.4's adapter layer.

methodendpoint
transitionStatusPOST /api/v1/work-items/{key}/transitions
dispatchPromptGET /api/v1/work-items/{key}/dispatch-prompt
markIntegratedthe integration record
completeSessionthe bulk session close-out
expandItemthe expansion submit

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

These are the methods where a subtle change is a behaviour change, so each keeps the contract its MCP wrapper documents:

  • dispatchPrompt is a pure READ. It never claims the item and never moves its status, so re-printing an in-progress item's prompt stays safe. sessionBranch is a FALLBACK the server may ignore — an item already on a lineage keeps its own — so the client can seed a run's first item without redirecting an existing chain. The CLI prints the returned text verbatim and assembles no prompt grammar of its own.
  • The advisories block stays OPTIONAL and never refuses a dispatch. It is printed; the human decides. An UNKNOWN severity must render nothing rather than print another member's fields as undefined — the CLI meets newer servers routinely, so renderDispatchAdvisories' fall-through is load-bearing and must survive the port unchanged. A port that "tidies" it into an exhaustive switch turns a forward-compatible client into one that crashes on the next advisory type someone adds.
  • transitionStatus on an illegal move surfaces the allowed targets the endpoint returns as DATA — that is what makes the surface self-teaching, and it is why the error path must read the structured body rather than a message.
  • markIntegrated and completeSession are transactional server-side (status move plus branch stamp; bulk close with per-item outcomes). The client reports what came back per item and never re-derives an outcome.

Scope BOUNDARY

Ends at these five methods. It MAY change a command file — but only a line that consumes a view-model field this card changed, and never an output string (the boundary 11.5.4 now carries, for the same reason). It does NOT port the planning-conversation methods (11.5.20) or the reads. It does NOT change the agent-launch, git or worktree code, which never touched the transport. 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 dispatch or session-close paths.
  • motir run, motir next, motir auto and motir batch produce output identical to the MCP-era implementation for the same data — asserted by the existing command-level tests with their assertion strings unchanged.
  • Fetching a prompt does not change the item's status or claim it — asserted by reading the item's status before and after.
  • An advisory whose severity this build does not recognise prints nothing and does not throw; both shipped severities print exactly as before.
  • An illegal transition surfaces the allowed targets from the response body, not from a parsed message.
  • A bulk session close reports the server's per-item outcomes verbatim, including a partial result where some items closed and others did not.
  • 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.
  • 11.5.23 — retires nextReady. ⚠️ Until 2026-08-07 this ref named 11.5.19, which does not retire it; see the corrected re-plan note above (MOTIR-2399).
  • packages/cli/src/mcpClient.ts — the five wrappers and, in their doc comments, every semantic listed above; DispatchPrompt, DispatchAdvisory and its two narrowing predicates, CompleteSessionResult.
  • packages/cli/src/render.tsrenderDispatchAdvisories and the unknown-severity fall-through that must keep working.
  • packages/cli/src/commands/dispatch.ts · auto.ts · batch.ts — the call sites.
  • Story: 11.5.