MOTIR-4276 · Planning bug: MOTIR-4201 was sealed at 13 points carrying its own split instruction — three signals agreed at authoring time and the gate fired a day later, at dispatch

MOTIR-4276To Do

Planning bug: MOTIR-4201 was sealed at 13 points carrying its own split instruction — three signals agreed at authoring time and the gate fired a day later, at dispatch

Telemetry about the planner, filed by motir run MOTIR-4201 on 2026-09-03. The correction is already applied — the split was submitted as a plan and MOTIR-4201 is Blocked. This work item holds nothing up and joins no sprint.

Finding 1 — a work item sealed carrying its own remedy, with THREE signals already agreeing

MOTIR-4201 was authored 2026-09-02T20:58:47Z (planningSource: mcp, planningHarness: Claude Code, planningModel: claude-opus-5[1m]) and sealed with all three of these true at once:

storyPoints: 13 — the estimation gate's own literal split threshold (13+ ⇒ split), in a structured field.
estimateMinutes: 240 — over the 70-minute proxy, so likely-over-gate-sizing fires with threshold: "both".
Its own body, under a heading reading "⚠️ It is over the estimation gate and owes a SPLIT", ending: "A run may not perform that split — a run proposes and stops — so the split is a motir plan pass on this card. Do not dispatch it as one card."

Every gate that governs this had already been written, and two of them name this exact shape almost word for word — plan-rules/core.md gate 21 ("an advisory a card records as REAL and does not act on is UNDISCHARGED, and the card is NOT SEALABLE") and gate 1's self-declared-split limb ("do not dispatch this as one card… PERFORM it before sealing"), which even prescribes grepping your own draft for that phrase. The work item was sealed anyway, stayed todo and ready: true for a day, and was handed to a run.

What the run did: run.md guard #4's advisory-disposition block caught it before any worktree existed, and it routed to THE REPLAN ACTION. So the corpus worked — at DISPATCH. The defect is that the same corpus, one day earlier, did not fire at AUTHORING, which is where every one of those rules is addressed.

The candidate that is not yet anywhere in the rules: every limb of gate 1 is LEXICAL — grep the body for "do not dispatch", "decomposes into", "two PRs". storyPoints: 13 is the same instruction in STRUCTURED DATA, and no limb reads it that way. A number is not prose, so no phrase list matches it; and unlike a sentence it is already machine-readable, already validated at the boundary, and already the gate's own stated threshold. A work item cannot carry 13 and be sealable — that is not a sizing to record, it is a split to perform.

Finding 2 — a measurement whose command enumerated a different set than the claim quantified over

The work item's Measured table asserts 769 occurrences in SHARED_PLANNING_RULES. Re-measured on origin/main 2026-09-03:

735 inside the segment template literals CORPUS_ORDER composes — what the shipped planner is taught, which is what the claim is about.
801 over the whole file region before CORPUS_ORDER — which includes source comments and /** lines N–M of the pre-split constant */ annotations that reach no model.

Neither matches 769, and the gap between 735 and 801 is the point rather than the drift: it is plan-rules/phase-deepen.md's ENUMERATION limb — the claim quantifies over X, the command enumerates Y — and the ref cannot show it, because both sets are measured at the same ref. The work item also carried no command beside its numbers, so a reader could check the ref and not the set.

Same shape in motir-meta: the work item's ~1 060 composed / ~290 maintenance re-measured at 978 / 616.

The fix direction

Both halves are RULE changes, not product code, so this work item's fix lands in the two corpus homes:

A limb on the estimation gate (plan-rules/kind-leaf-deepen.md) and/or gate 1: a storyPoints value at or above the scale's split threshold IS a split declaration in data, and is not sealable — perform the split rather than writing the number. Mirror it into motir-ai's SHARED_PLANNING_RULES per gate 19's two-homes rule.
Consider whether the shipped likely-over-gate-sizing advisory should be promoted from advisory to a seal-time refusal for the 13+ arm specifically, since that arm is the gate's own literal threshold rather than a proxy. That is a product decision and is named here, not decided.

Sizing is for the RULE change; if the promotion in (2) is taken up it is its own work item.

Acceptance criteria

A limb exists, in both corpus homes, stating that a storyPoints value at or above the split threshold is itself the split instruction and blocks sealing.
That limb is asserted on the composed rule text, not only on the motir-meta file, so the shipped planner receives it.
The PR body records whether (2) was taken up, and if not, names the work item that will decide it.

Context refs

MOTIR-4201 — the work item this is about; its plan-time fields and body are the evidence.
motir-meta prompts/plan-rules/core.md — gate 1's self-declared-split limb, gate 21, gate 20.
motir-meta prompts/plan-rules/kind-leaf-deepen.md — THE ESTIMATION GATE and its 13+ ⇒ split threshold.
motir-meta prompts/plan-rules/phase-deepen.md — the ENUMERATION limb behind finding 2.
motir-core validate_work_item — the likely-over-gate-sizing advisory and its threshold: "both" arm.