Motir

The planner's prompt varies on two axes that are orthogonal to the variation that actually matters, and this epic replaces both with one.

What is wrong today

The OPERATION axis shapes the framing but not the rules. Five job kinds — generate_tree, expand_item, augment, replan, revise_plan — each carry their own situation prompt, and that prompt REPLACES the runbook wholesale. So expand an epic and expand a bug receive the same 2,476-char framing though they are completely different jobs, while replan / expand / augment a story receive three different framings though they are the same job. The axis is backwards in both directions.

The KIND/TYPE axis shapes the rules but not the framing. MOTIR-3891 cut the corpus on SUBJECT and MOTIR-3916 on PHASE, producing a 22-cell space that works — for the rules. The framing never joined it.

The intent classifier is a regex ladder. contextualScope.ts picks between replan / expand_item / augment from four lists of regular expressions over the turn text, falling back to augment as a safe floor. Its real defect is not inaccuracy: it is that it MUST return something. A planner that is not yet sure what it is being asked has no way to say so.

And replan was already found not to be a thing. MOTIR-3869 retired the operation axis from rule SELECTION on the grounds that replan IS plan — but only from the rules. The framing and the handlers kept it.

The model this epic builds

A planning run is a SEQUENCE OF SESSIONS. Each session is exactly one phase over exactly one target, and its whole prompt — framing AND rules — is assembled from that cell:

INTAKE    → do I know enough to start, and to start on WHAT?
SKELETON  → lay this card's children (containers only)
DEEPEN    → author this card's body and sizing

So "expand an epic" stops being an operation and becomes a WALK:

skeleton epic   → lay the story titles + edges
deepen story ×n → author every story
skeleton story₁ → lay its subtask titles          (the comet: first child only)
deepen subtask ×m

The regex disappears — not replaced by a better classifier, but by a conversation that is allowed to answer "not yet" and keep asking.

Scope BOUNDARY

• IN: the phase set and the cell keying; the framing's tiering; the walk driver and its completeness definition; the intake corpus; the retirement of the five job kinds and the regex ladder; the wire contract; the motir-meta mirror.
• OUT: the RULE corpus's content. This epic changes what SELECTS a rule and what is wrapped around it, not what any rule SAYS. A rule re-worded here is a defect, not a deliverable.
• OUT: the planning-turn CHANNEL. MOTIR-2226 already landed the assistant role, persistence, rendering, the awaiting-answer state and the reply that resumes planning. This epic consumes it; it does not rebuild it. (A stale comment in motir-ai's envelope.ts still says that channel is inert — correcting it is inside the first story.)
• OUT: the pre-plan / discovery conductor, which is a separate surface with its own loop.

Context refs

• motir-ai src/llm/treeGeneration.ts — buildGenerationSystemPrompt, SKELETON_PHASE_TOOLS / DEEPEN_PHASE_TOOLS, runGenerationPass, detectMode.
• motir-ai src/jobs/registry.ts — the five registerHandler lines that ARE the operation axis.
• motir-ai src/jobs/contextualScope.ts — classifyTurnIntent, the four-rung regex LADDER.
• motir-ai src/jobs/handlers/{generateTree,expandItem,augment,replan,revisePlan}.ts — the five situation prompts.
• motir-ai src/llm/planningRulePacks.ts — legalPlanningRuleCells, resolvePlanningRulePacks, composeSkeletonRules.
• MOTIR-3891 · MOTIR-3916 — the two stories that built the cell space this epic extends to the framing.