Motir

Type · planning defect (a record; no repository deliverable, which is why no targetRepo is pinned) Parent · MOTIR-1465, the planner-bug home Discovered in · motir run MOTIR-3068, 2026-08-19 — the run claimed the card, verified it, and could not build it.

What happened

MOTIR-3068 was filed by MOTIR-3054's run and sealed at storyPoints: 13, estimateMinutes: 600. Both are over the estimation gate (plan-rules/kind-leaf-deepen.md): 13+ is the gate's literal SPLIT signal, and a coding_agent leaf's agent run must be ≤ 60 minutes — 600 is ten times it. The card was nevertheless todo, ready: true, validate_work_item valid: true, and claimable.

The remedy was not missing. It was written, twice, in prose the plan cannot read:

"Expect this to SPLIT — 13 points says so. 13 is the estimation gate's 'should be split' signal, and it is meant literally. Split by AREA … so each child is one PR of a reviewable size." — its description "Sized at 13 to say plainly that this must be split by area before it is run, not to claim it can be done in one sitting." — its explanation

motir run MOTIR-3068 therefore did not build it. It ran THE REPLAN ACTION and split the card by area into six sweeps plus a terminal guard flip (28 points / 400 minutes), which now sit under MOTIR-3068 as MOTIR-3113–MOTIR-3119.

The correction was written DIRECTLY into the tree, at Yue's instruction, after the proposal door failed. The run first submitted it as plan cmt00eze103s8i2phg6eqf9as per MOTIR-3047; Yue could not accept it because the plan review surface has a defect of its own (MOTIR-3070), and directed the run to write the cards. That plan is superseded and should be declined rather than approved. Worth recording as a second-order finding: the propose-then-approve contract has a single point of failure in the review UI, and when it fails there is no degraded mode — only a human overriding the door by hand.

Root cause — and this is the FOURTH occurrence, so the shape is the finding

plan-rules/core.md gate 9's repeat-defect trigger says two is a coincidence and three is evidence about the design. The prior instances, all done:

• MOTIR-1452 — "MOTIR-1450 was sealed into the active sprint over the 1h estimation ceiling (8 SP/90 min) with a 'decompose before run' note instead of being split at plan time." Byte for byte the same defect, one year-quarter earlier.
• MOTIR-1229 — 8.8.24 over-scope, split into a scaffold plus three slices after the fact.
• MOTIR-1180 — a trusted 8 pt / 70 min that was honestly ~13 pt / 330 min, split into three.

Four instances share one root shape, so gate 9's limb (a) — "three independent root causes" — does not apply and limb (b) does: the estimation gate's SPLIT limb is the only gate on the per-card checklist that nothing executes. It is prose in kind-leaf-deepen.md, and every surface that could fire it declines to:

• validate_work_item returns valid: true on a 13 SP / 600 min coding_agent leaf, with no blocker and no advisory. Verified on MOTIR-3068 at 2026-08-19T11:2x — the one advisory it returned was an unrelated subsumption / likely-already-shipped against MOTIR-3054's PR #2133.
• log-bug.md step 3's seal names gates 1, 14 and 16 and the advisory disposition — grepped at motir-meta 9b04fd6: grep -n "storyPoints\|estimat\|13\|split\|SPLIT" prompts/log-bug.md returns nothing. So a run filing a bug is told to pin the repo, check the AC axes and write both bodies, and is never told that a size it is about to write is itself a seal failure.
• create_work_item defaults both sizes to null, so the filer who does the right thing and sizes the card honestly is the only one who can hit the gate — and there is no instruction attached to hitting it.

And the writing-it-down is not a workaround, it is the whole failure mode. A card that says "do not run me as one card" and a card that says nothing are the same card to claim_next_ready, to validate_work_item and to the board — the same family as plan-rules/kind-leaf.md's a card that declares its own split in prose has not split, which is stated there for the REPO axis and has now fired four times on the SIZE axis without being stated for it.

The re-shape (gate 9 limb b)

Filed as MOTIR-3110: a likely-over-gate-sizing shape advisory on validate_work_item, alongside likely-ordering-violation and likely-repo-straddle in the same kind: 'shape' family. Its input is two integer columns and the executor — no prose parsing, no judgement — which is exactly the tier plan-rules reserves for code. This card is NOT blocked_by it: the correction it records has already landed, so there is nothing here to hold.

One thing this bug does not claim. It was not wrong to FILE a 13-point card. Under MOTIR-3047 a run may create exactly one kind of work item directly — a bug — so MOTIR-3054's run could not have proposed a six-card subtree. What it could have done, and what the gate asked for, is file six sibling bugs; nothing limits a run to one.

Acceptance criteria

• This card records the four occurrences, the root shape and the re-shape card, so the author of a fifth can audit the reasoning rather than re-derive it (gate 9: the discharge goes IN THE CARD).
• notes.html carries the matching lesson entry — mistake #323, motir-meta PR #257 — which holds the LESSON where this holds the CARD. (AMENDED 2026-08-20 by this card's close-out. As authored this line read #322, the number free when the PR was opened; #257 merged 2026-08-19T16:44:51Z as #323, the slot having renumbered under it. Today's #322 is an unrelated lesson about a card's "what must NOT change" clause, so following the citation as written lands on a stranger's entry. Evidence below.)
• The correction itself is recorded as landed, not pending: MOTIR-3113–MOTIR-3119 exist under MOTIR-3068, and plan cmt00eze103s8i2phg6eqf9as is superseded.

Close-out verification — motir run MOTIR-3108, 2026-08-20

Every citation on this card re-executed against origin/main, plus the two things a close-out owes that the filing session could not know: the FIFTH occurrence, and whether the correction this card commissioned does what it claims.

The three acceptance criteria

Citations re-executed

• notes.html #322 → #323. git show origin/main:notes.html | grep -n 'mistake-num">32[0-9]<' puts this lesson at 323; #322 is the "what must NOT change" lesson (MOTIR-3092). PR #257's own body says so — "Adds notes.html mistake #323". The sequence is gapless and uniq -d over the numbers is empty, so this is the ordinary reserved-slot renumber, not a duplicate collision. The entry's content re-verified clause by clause and is EXACT — the quoted description and explanation, the MOTIR-1452 quote, the kind-leaf.md repo-axis rule at line 30, and the MOTIR-3047 one-bug constraint all read as quoted. Nothing is owed to the merged entry.
• The log-bug.md negative claim, at both refs. grep -n "storyPoints\|estimat\|13\|split\|SPLIT" prompts/log-bug.md returns nothing at 9b04fd6 — the claim was exact — and still returns nothing on origin/main today. It is nonetheless DISCHARGED rather than open: step 3's seal mandates validate_work_item and the disposal of every advisory (MOTIR-2899), so once MOTIR-3110 shipped, the filer meets the gate through the advisory channel instead of through prose. That is the mechanization working the way this card argued it should.
• The re-shape SHIPPED, and is deployed rather than merely merged. likely-over-gate-sizing is on motir-core origin/main (9aca2850) in lib/dto/workItems.ts, lib/workItems/proseVsGraph.ts, lib/services/proseGraphAdvisoryService.ts, lib/mcp/tools/validateWorkItem.ts and lib/api/v1/workLoop/schema.ts, with unit, dispatch-route and plan-validity tests — motir-core#2170, merged 2026-08-19T22:10:28Z. The live MCP's own tool description names it, and a live validate_work_item call returns it (below), so the merged ≠ deployed gap is closed by observation and not by the merge.

The FIFTH occurrence, promoted from the comment thread

MOTIR-3154 — a childless bug leaf at 8 SP / 240 min with seven criteria spanning a design amendment, four code seams, an i18n floor and two test pins — was sealed todo, ready: true, valid: true, carrying its own gate-9 disposition in prose ("the re-shape is acceptance criterion 1 … and it is this card's first child", on a card with no children). Both numbers are over the gate: 8 is already the split signal, and 240 is the pack's verbatim human-estimate tell. Yue's comment of 2026-08-19T20:41:17Z on this card has the full account; it is summarised into the body because a record card's body is the record and its comments are not.

It is not a post-mechanization failure. MOTIR-3158, filed from that run, was created 2026-08-19T20:38:38Z — 1h32m before #2170 merged. So the family stands at five occurrences and zero after the check shipped.

⚠️ What the close-out found: the correction's MINUTES arm tests the wrong quantity

The check this card commissioned is right in kind and wrong in one of its two inputs. Measured, not reasoned:

• The gate's minutes ceiling is on AGENT-RUN TIME, EXCLUDING CI. plan-rules/kind-leaf-deepen.md: "coding-agent run time (EXCLUDING CI) must be ≤ 1h … The ceiling is on the agent-run component alone … NOT the PR's CI pipeline."
• estimateMinutes is the SUM of both. Same pack: "estimate (estimateMinutes) = coding-agent run time + CI-pipeline time summed into one number", with CI "typically the LARGER half of the total for a right-sized card."
• So the pack's own calibration table puts a right-sized 5-pointer at ~50–70 min total — and ESTIMATION_GATE_ESTIMATE_MINUTES = 60 is tested against that same total, strictly greater. The check flags the upper half of a band the gate endorses.

Live control (2026-08-20): validate_work_item MOTIR-3239 — a childless coding_agent subtask at 5 SP / 65 min — returns {"kind":"shape","severity":"likely-over-gate-sizing","threshold":"estimate_minutes","storyPoints":5,"estimateMinutes":65}. Project-wide the points arm has 5 candidates (storyPoints >= 13) against 320 for the minutes arm at storyPoints <= 5, only 30 of which pass 100 minutes. Those counts are an upper bound — the filter grammar cannot express the predicate's coding_agent and childless exemptions — and the control is the fixture that needs no count.

MOTIR-3110's own DTO comment asserts the opposite in as many words: "The other two checks have false-positive classes a card can legitimately be in; this one has none." The correction reproduced this card's defect one tier down — the points axis was discharged exactly, and the claim written adjacently, in the same comment, about the minutes axis was never measured. Filed as MOTIR-3271 against motir-core.

Verdict on the promote question: no SIZE-axis rule sharpening is owed, and one WIDENING is

This card settled lesson-vs-rule in its own explanation — "the fix cannot be a sharper sentence" — and the mechanization shipped, so a fifth restatement of "13 means split" is refused here explicitly, so nobody re-derives it from the fifth occurrence.

The residue is elsewhere, and it is a trigger gap rather than a diligence one. prompts/ names three of the shape family's four members (likely-repo-straddle, likely-ordering-violation, likely-self-blocking-design) and likely-over-gate-sizing zero times, against that populated control. Worse, the standing disposition sentence — "a shape entry is a criterion to CUT at the 1-based index it returns", at log-bug.md:182 and run.md:1017 / :1096 / :1164 — is false for it: it carries no criterion index at all, and its remedy is to SPLIT the card. motir-core's own DTO says as much of the fourth member ("The other criterion members report ONE number because their remedy is a cut … This one's remedy is a LIFT"), so the code distinguishes three remedies where the corpus names one. Folded as W10b into MOTIR-3013 rather than filed fresh, because that card already holds prompts/run.md and two cards on one file is two conflicting pull requests.

Context refs

• motir-meta/prompts/plan-rules/kind-leaf-deepen.md — THE ESTIMATION GATE: the 13+ split signal and the ≤ 60 min run-time ceiling.
• motir-meta/prompts/log-bug.md step 3 — the seal that names gates 1 / 14 / 16 and not this one.
• motir-meta/prompts/plan-rules/kind-leaf.md — a card that declares its own split in prose has not split, stated for the repo axis.
• MOTIR-2899 — the other gap in the same seal (the validate post-condition), for the second instance of log-bug.md's seal omits a check the plan-pass path has. Two, so a coincidence for now.
• MOTIR-3070 — the plan-review defect that forced this correction onto the direct door.
• MOTIR-3271 — added 2026-08-20 by the close-out. The product bug in this card's own remedy: the minutes arm tests estimateMinutes against a ceiling the gate places on agent time alone. relates_to; this card consumes nothing it produces and is not held by it.
• MOTIR-3013 — added 2026-08-20 by the close-out. Carries W10b, the corpus limb naming the fourth shape member and its non-CUT remedy.
• MOTIR-3154 — the FIFTH occurrence, 2026-08-19, 1h32m before the check shipped.