Motir

When an agent finds a card it cannot implement, it submits a re-plan and the card must stop being picked up until a human has acted on that plan. There is no status that says so.

Why blocked is the WRONG answer

blocked is in the to do category, and true blockedness is decided by the EDGE, not the status — readiness is computed from blocked_by dependencies. So a card at blocked is still ready, still in the pickable set, and gets re-dispatched on the next run. MOTIR-1762 is the live proof: status blocked, all twelve blockers done, readiness.ready: true.

Setting blocked and walking away is a status that lies and changes nothing. It also overloads a human annotation with a machine meaning.

What to build

A Planning status in the in_progress category, in the default workflow.

The category is what does the work. A run picks up the to do category — not a status key, because a project may define its own statuses there and the loop must take those too. A card at Planning is in the in-progress category, so it leaves the pickable set STRUCTURALLY: nothing special-cases it, nothing has to remember why.

It is also the truthful label. The card is not blocked and not abandoned — it is in progress, in planning rather than implementation.

The transitions to settle

At minimum in_progress → Planning (the agent, on finding the defect). The way OUT is this card's real question: back to todo once the plan is approved and the card corrected, or cancelled when the plan replaces it — and whether a human does that by hand or plan approval does it. Decide, and say which, rather than adding the status with no exit.

Existing projects

The default workflow is seeded per project, so shipping this to new projects only would leave motir auto broken on every project already created. Existing projects need the status and its transitions added. Say how — migration, backfill, or a lazy add — and make it idempotent.

Scope BOUNDARY

The status, its category, its transitions, and getting it onto existing projects. It does NOT change how readiness is computed — edges decide that, and this card does not touch it. It does NOT change what blocked means for humans. It does NOT implement the agent's use of it (11.5.25) or the loop's pickable rule (its own card). It does NOT add a second machine-only status: Planning is the one, and anything else the loop needs should be a finding, not a sibling.

Acceptance criteria

• Planning exists in the default workflow with category in_progress, asserted on a freshly-created project.
• Every existing project has it after the change, asserted — and the mechanism is idempotent, asserted by running it twice.
• A card at Planning is ABSENT from the ready set, asserted directly. This is the property the whole card exists for and it must not rest on the category rule being applied correctly elsewhere.
• The transitions in and out are legal and named; a card can reach Planning and leave it without an admin editing the workflow.
• ⚠️ Adding a status to the default workflow historically breaks count-shaped tests (DEFAULT_TRANSITIONS has three known consumers). Find them and update them deliberately rather than discovering them in CI.
• blocked is unchanged in meaning, category and behaviour.

Context refs

• prisma/schema.prisma — the workflow status / transition models; lib/services/workflowsService.ts.
• lib/services/workItemsService.ts — isOpenBlocker and getReadiness: readiness is edge-derived, which is why blocked does not do this job.
• MOTIR-1762 — a live card at blocked with every blocker done, ready anyway.
• 11.5.25 (MOTIR-2406) — the agent that will set it; corrected to Planning.
• 11.5.26 (MOTIR-2407) — the loop that stops on the plan submission; the status is what stops the RE-PICK, separately.
• Story: MOTIR-1855.