Planning bug: a design that merges AFTER the card it gates re-opens that card's SIZING, and MOTIR-1136 reached dispatch at 5 pts / 65 min for a ten-card feature

Filed by motir run MOTIR-1136 (2026-08-27), which halted at the estimation gate and submitted plan cmtbiqj6l00hlhvn8xin3fg47 splitting the card into ten slices.

What happened

MOTIR-1136 was authored 2026-06-19 at 5 points / 65 minutes, with a body that said "No new design asset — surfaced in existing account/privacy settings … using existing settings primitives." On 2026-08-27 14:34 its design blocker MOTIR-3680 merged (PR #2356, 90ac50e04) and specified: a fourth account-settings rail group and route, two distinct backend capabilities, a 30-day scheduled erasure sweep feeding the code-graph offboarding queue, a background export build with a blob upload and a 7-day retention, a notification email, an authenticated download route, an app-wide banner on every page, and ~40 i18n keys needing zh twins. The re-plan sized that at 34 points / ~535 minutes across ten cards.

The card's own estimate was never revisited. It reached dispatch reading ready: true, valid: true, advisories: [], openBlockers: [] — every signal green, because every signal was measuring something else.

The defect, stated precisely

run.md's a done design blocker that merged AFTER the card rule already exists and already fires here — the run followed it and that is what caught this. But the rule's remedy is scoped to CRITERIA: "Any clause the design contradicts is an amendment to make, not a feature to build." It says nothing about the estimate, and the estimate is the field that had actually been falsified.

So the shape is: a rule that correctly identifies the asset outranks the card and then sends the reader to diff the wrong field. A careful runner who follows it exactly amends the acceptance criteria, leaves 5 points / 65 minutes standing, and starts building.

Three things that did not catch it, all working correctly:

1. likely-over-gate-sizing fires at 13+ points or >70 estimated minutes. This card read 5 / 65 — under both, by five minutes. The advisory measures what the card SAYS, and the card's numbers were stale rather than wrong-looking.
2. The design-allocation sweep (plan-rules/type-design.md's GIVES/TAKES) asks what an asset gives and takes over an element, a structure or a premise. MOTIR-3680 ran it and named MOTIR-1136 correctly under GIVES. Nothing in that vocabulary asks "does what I am giving fit inside what that card is sized for?"
3. The handover comment on MOTIR-1136 enumerated two build obligations in detail and was written the same day — and still did not touch the sizing, because it was reasoning about correctness, not about scope.

What the fix is

The rule change, not the card. run.md's calendar-check rule gains a limb: when the design is younger than the card, re-run the estimation gate against the asset, not only the acceptance criteria — a design that answers a card's open questions routinely multiplies its scope, and the sizing is the field nobody re-reads. The design-side twin belongs in plan-rules/type-design.md's sweep-the-referrers corollary: a GIVES is a sizing claim about the receiving card, so an asset that gives more than the card is sized for owes that card a re-estimate in the same pass.

Two homes (plan-rules/core.md gate 19): the packs teach the manual planner, SHARED_PLANNING_RULES in motir-ai teaches the shipped one. Read the constant before mirroring — if the shipped planner cannot observe the trigger (it does not read merge dates), narrow deliberately and say so on the card with the grep that excluded it, rather than silently shipping one home.

Acceptance criteria

• run.md's a done design blocker that merged AFTER the card rule carries a limb requiring the estimation gate to be re-run against the asset when the design post-dates the card — naming the sizing fields, not only the criteria.
• plan-rules/type-design.md's design-allocation sweep carries the twin: a GIVES entry is a claim about the receiving card's SIZE as well as its content, and an asset that outgrows a card re-estimates it in the same pass.
• The two-homes decision is recorded on this card: either the mirrored SHARED_PLANNING_RULES change, or the narrowing plus the grep that justified it.
• The lesson recorded for this incident is cited, and this card does not restate it.

Context refs

• The halted card and its full diagnosis: MOTIR-1136 (see the run's comment).
• The design that outgrew it: MOTIR-3680 — design/settings/design-notes.md → Data & privacy, and its Build dependency (for MOTIR-1136) list.
• The corrected shape: plan cmtbiqj6l00hlhvn8xin3fg47.
• Rules to amend: motir-meta/prompts/run.md (the calendar-check rule); motir-meta/prompts/plan-rules/type-design.md (the sweep-the-referrers corollary, design limb); the estimation gate itself in plan-rules/kind-leaf-deepen.md is the rule being backstopped and does not change.
• The shipped detector that cannot reach this: validate_work_item's likely-over-gate-sizing (13+ pts / >70 min).