Planning bug: MOTIR-3324 ships a consumer whose motir-core PRODUCER half owns no card — a conditional in a card body defers a decision the run cannot act on

Filed by the motir run MOTIR-3322 session, 2026-08-21. MOTIR-3324 ships a CONSUMER with no PRODUCER, and no card owns the other half.

MOTIR-3324's own body anticipates the seam — "If the envelope has to change in motir-core, that half is a named sibling card, not a second repo on this one. Read the envelope first and say which it is in the PR" — and its last acceptance criterion is "If the envelope change lands in motir-core, the PR names the sibling card that owns it."

The envelope was read, and the answer is that no motir-core change is REQUIRED for 3324 to be complete: JobContextBag (motir-ai/src/envelope.ts) is motir-ai's own loosely-typed reserved-hole bag, so declaring and defensively parsing context.replanTrigger is entirely a motir-ai change. 3324 is buildable and asserted as shipped.

But nothing SETS it. motir-core composes the re-plan job envelope, and until it populates context.replanTrigger, parseReplanTrigger returns null on every real re-plan, replanMayCaptureMistakes refuses, and the capture tools are withheld from every re-plan in production. The consumer is correct, live, and permanently in its fallback arm. The card whose criterion says to NAME the sibling was authored with no sibling to name — the AC is dischargeable only by prose, and a criterion answered in prose is what leaves a seam unowned ([[orphaned-deferral-planning-gap]] shape).

The planner-side lesson. A card that says "if this needs the other repo, that is a sibling card" has stated a conditional whose TRUE branch has no owner. The condition was resolvable at PLAN time by one read of the envelope type, and the outcome either way owed a card: if the bag were typed, a motir-core sibling for the type; since it is untyped, a motir-core sibling for the PRODUCER. A conditional in a card body is a decision deferred to the run, and the run cannot create the card the decision calls for.

The correction, already applied

• MOTIR-3324's consumer half is shipped and the fallback is deliberate and defended (absent / unrecognised ⇒ refuse to capture).
• The seam is named in the pull-request body rather than left implicit.

What is still owed (a card for the approver to place)

A motir-core subtask: the re-plan submit sets context.replanTrigger on the job envelope — agent_card_wrong when a dispatched agent's run concludes the card is wrong (the motir run / scoped-run re-plan path), user_initiated when a person re-plans in the UI. Without it, MOTIR-3322's whole loop stays inert on the re-plan path in production.

Context refs

• motir-ai src/envelope.ts — JobContextBag.replanTrigger, REPLAN_TRIGGERS, parseReplanTrigger, replanMayCaptureMistakes.
• motir-ai src/jobs/handlers/replan.ts — the consumer, reading it off the envelope.
• MOTIR-3324 — the card that carries the conditional.