Motir

Discovered 2026-08-19, by Yue looking at the plan-review canvas of the plan that had just materialized MOTIR-3154's five children: every card read Out of date, and the rail read "5 items may be out of date · New sibling items since planned".

What happened

MOTIR-3154 was re-planned the same day into five children, and that re-plan was well executed by every gate it ran. Its diagnosis names three root causes, every one of them verified against origin/main 835352cb line by line; the split discharged the estimation gate, the design gate and the repeat-defect gate; the allocation table accounts for all seven of the original criteria. Nothing in it is false.

It nonetheless missed a fourth root cause of the same reported symptom — one that keeps the surface broken after all five children ship. computePlanStaleness counts the items a plan itself materialized as new siblings that appeared since it was planned (planStalenessService.ts:82-91 + workItemRepository.ts:877-894), and getPlanReview calls it unconditionally.

Where it sat: the re-plan quoted lib/services/planReviewService.ts:139 — the nodeId rule — which is inside getPlanReview, and the computePlanStaleness call is line 127 of the same function, twelve lines above the line that was quoted and read. The card opened the file, opened the function, and read one expression out of it.

Why the existing gates could not fire

• Gate 2 (preconditions verified) audits the claims a card MAKES. Every claim this card made was true.
• The asserted-ABSENCE limb fires on a card whose deliverable is an edit — "add X to Y" hides "X is not in Y". This card asserted no absence about staleness; it simply never mentioned it.
• likely-missing-edge / the advisory tier scan a card's own description for references to not-done work. A defect the description never names is invisible to them by construction.
• The repeat-defect gate fired correctly and produced the right disposition — a design-first split. A design that draws the decided surface's node treatments still does not draw "and it stops warning".

Every mechanism the corpus has reads what a card SAYS. Nothing reads the surface the card is about and asks which of its inputs the card left unexamined.

The rule this is missing

When a card's diagnosis QUOTES a line inside a function, it owes a reading of what that function CALLS. A rendered surface is an ASSEMBLY, and a symptom you reproduced identifies one contributor to it, not the set. The discharge is cheap and mechanical, and it is an ENUMERATION rather than a judgement:

List every field of the DTO the broken surface renders, name the producer that fills each one, and mark the ones this card read. The unmarked rows are the unchecked ones — say so on the card, in this card's scope or as a named sibling, and there is no third option.

On MOTIR-3154 that enumeration is four rows long: getPlan (the proposals), computePlanStaleness (the warnings), workItemRepository.findByIdsInWorkspace (the live targets), userRepository.findById (the decider). The card read one and a half of them.

The aggravating detail, and the reason this is worth a rule rather than a note: the fix's rule was already written in the codebase, twice — app/(authed)/plans/planRowView.ts:33-45 and lib/services/autoPlanCadenceService.ts:111-119 both short-circuit with the comment "Only a planned plan can be stale." The miss was not knowledge and not diligence. It was REACH: a diagnosis that starts from a symptom stops at the first line that explains it.

Acceptance criteria

• The rule above is written into motir-meta/prompts/plan-rules/ — the pack the selector actually loads for the pass that would have caught it (phase-deepen.md's precondition family, or kind-bug.md if it is bug-specific; state which and why), as a limb of the precondition-verification rule and NOT as a new top-level gate.
• It is stated as an enumeration with a discharge, in the shape the corpus already uses for the counted-set and migration-caller limbs: what to list, what marks a row checked, and the two dispositions for an unchecked row (this card's scope, or a named sibling).
• It carries its warrant line in the corpus format, citing this card and MOTIR-3154 with the date and the ×1 count.
• A rule has TWO homes: the same limb is mirrored into motir-ai's SHARED_PLANNING_RULES, or the card records why the mirror does not apply. A rule that lands in one home only is half-shipped.
• The motir-meta change lands via a branch + PR the user merges — never a direct commit to main.
• notes.html carries the matching .mistake entry with its count bumped (logged in the same pass that filed this card; this criterion is satisfied by that entry existing, not by re-writing it).

Context refs

• MOTIR-3154 — the re-planned card, and the plan-review surface itself · the amendment plan filed 2026-08-19 21:07 UTC adds the missing child and the two modifys.
• MOTIR-3155 — the planning bug from the SAME re-plan. Related but distinct: 3155 is about a surface planned state by state, this one is about the diagnostic METHOD that reads one line of an assembly. Both fired on the same card, which is itself worth noting in the corpus.
• motir-core lib/services/planReviewService.ts:127 (the computePlanStaleness call) and :152 (the nodeId rule the card quoted) — both on origin/main 8da86da; the card cited :139 against 835352cb.
• motir-core lib/services/planStalenessService.ts:82-91 · lib/repositories/workItemRepository.ts:877-894 — the defect.
• motir-core app/(authed)/plans/planRowView.ts:33-45 · lib/services/autoPlanCadenceService.ts:111-119 — the rule, already written twice, that the diagnosis never reached.
• motir-meta/prompts/plan-rules/phase-deepen.md (the precondition-verification family) · MANIFEST.md (which pass loads which pack) · CORPUS-MAINTENANCE.md (RULES vs LESSONS, and the mechanization tiers).