Motir

Type · planning bug — a defect in how a card was AUTHORED, filed into the planner-bug home. The product fix that the card asked for shipped correctly; this is telemetry about the card.

Found while running · MOTIR-3777 (motir run, 2026-08-28). PR: https://github.com/moooon-B-V/motir-core/pull/2421

What went wrong

MOTIR-3777's acceptance criterion 3 wrote the check as a command and then answered it from reading rather than from running it:

grep -rn "siblings_added\|staleSiblingsAdded" over the repo returns only lines this card deliberately keeps, and the card accounts for each of the seven homes: lib/dto/plans.ts:549 and :561, lib/services/planStalenessService.ts, components/planning/PlanItemNode.tsx:68, components/planning/PlanReviewRail.tsx:53, messages/en.json:215, messages/zh.json:215, and tests/integration/plans/planStalenessService.test.ts.

Run verbatim on origin/main (35c17cea3), that grep returns ten homes. The three it missed:

git log --diff-filter=A --format='%h %ad' --date=short -- <paths> dates all three to 2026-06-25/26 — two months before the card (2026-08-28). So the enumeration was wrong when it was written, not drifted since.

A fourth home follows consequentially once the repository method is deleted: tests/rls/tx-fallback-arm.test.ts, whose describe title ratchets a count (68 → 67).

Why this shape is worth a record rather than a shrug

The card is otherwise exemplary — a production measurement, a root cause with two composing faults, a named consequence to weigh before choosing between retiring and narrowing. That is what makes the miss expensive: a card that states its sweep as an explicit list reads as having done the sweep, and the runner's cheapest correct move (re-run the grep) is the one the card has already appeared to make. Had the run trusted the list, siblings_added would have been retired with a green Vitest lane and an E2E spec still asserting the retired badge text — the failure landing in a lane the card never mentions, hours later, attributed to the diff rather than to the enumeration.

Two conditions concentrate the risk, and both held here:

1. The card was filed out-of-band, as an aside during a plan review of a different card, where filing feels like the cheap part.
2. The claim quantifies over a population ("each of the seven homes", "returns only lines this card deliberately keeps"), which is the shape run.md's re-measure rules already govern on the RUN side — a number with a ref beside it hands the reader the wrong thing to check.

The authoring-side rule exists (plan-rules/phase-deepen.md's ENUMERATION limb: a card COUNTING a population owes the ref the count was taken on). What it does not yet say is that a card quoting a command owes that command's output, not its expected output — which is the failure here, since the ref was fine and the command was never run.

Fix direction (for whoever picks this up)

Not a code change in a product repo. Candidates, in order of weight:

1. plan-rules/phase-deepen.md, the ENUMERATION limb — add the command corollary: where a criterion QUOTES a command as its own test, the card must carry that command's actual output (or its count), taken on a named ref. A quoted command whose result is asserted from reading is an unrun check wearing a passed one.
2. A validate_work_item advisory is plausible but weaker: the tier would have to run the quoted grep, which it cannot. Prefer the authoring rule.

Acceptance criteria

1. The rule above lands in motir-meta prompts/plan-rules/phase-deepen.md under the existing ENUMERATION limb — an ADDITION, not a re-wording of what is there.
2. It states the discriminator plainly: a criterion that quotes a command owes that command's OUTPUT on a named ref; a list of homes written from reading is not a sweep.
3. It cites this bug and MOTIR-3777 as the fixture.
4. plan-rules.md's routing is unchanged — this is a limb of an existing rule, not a new pack.
5. No product-repo file changes.

Boundary

This card does NOT re-open MOTIR-3777. That card's product fix shipped complete, with all ten homes swept and the mis-enumeration amended on its record — the correction is already applied, which is what makes this telemetry rather than scheduled work. It blocks nothing and joins no sprint.