MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-3494

Planning bug: a falsified-premise card named TWO of the ten cards its finding invalidated — the referrer sweep was done by memory, not by grep

Done
Description

Telemetry about the planner. The correction is already applied — this card holds the record, and blocks nothing.

What happened

MOTIR-3492 recorded a finding that falsified a premise: a loading.tsx at a route-group root destroys the 404 on every route beneath it that decides existence, so the "group frame" every card in MOTIR-3440's subtree was written against cannot exist.

Its own step 3 named the cards that needed restating: "Restate MOTIR-3440 and MOTIR-3442." Two.

Running it found ten:

cardthe clause the finding falsified
MOTIR-3440its TITLE — "settings gets a frame of its own" — named in the card
MOTIR-3442its TITLE — "instead of the group's" — named in the card
MOTIR-3443its TITLE and deliverable 1 name app/(authed)/settings/loading.tsx — the exact file the finding forbids. Not named
MOTIR-3441the shared settings boundary its shape was drawn for. Not named
MOTIR-3444/items/[key]/edit is a decider. Not named
MOTIR-3445/plans/[id] is a decider. Not named
MOTIR-3447/sprints/[id]/report is a decider. Not named
MOTIR-3446the group frame it falls back to. Not named
MOTIR-3449the boundary its seams and ratchet are written over. Not named
MOTIR-3450"watch the frame land before the content" — a different moment now. Not named

The most expensive omission is MOTIR-3443, whose title and first deliverable name the forbidden file outright. Dispatched as written it would have built app/(authed)/settings/loading.tsx above the five existence-deciding routes under settings/ — re-creating the defect MOTIR-3492 exists to prevent — and been caught only by tests/navigation/loading-boundary-guard.test.ts after the work was done.

Why it happened

The sweep was performed from the two cards the reporting run had read while doing its own work, rather than from a search of the tree for the premise's own words. The finding was precise; the enumeration of what it reached was not. Both survivors it did name were cards the run had opened; every card it missed was one it had not.

The graph could not have supplied the answer either. MOTIR-3440 is blocked_by MOTIR-3492 at the STORY level, so its children read as held — correctly — while their TEXT went on asserting a premise nobody had re-read. A readiness edge holds a card; it does not correct it.

The correction, already applied

  • MOTIR-3440, MOTIR-3442, MOTIR-3443 — title and body amended, each with a dated ⚠️ AMENDMENT block; MOTIR-3440's carries the per-child table.
  • MOTIR-3441, MOTIR-3444, MOTIR-3445, MOTIR-3446, MOTIR-3447, MOTIR-3449, MOTIR-3450 — commented with the clause that moves for each.

The takeaway

A finding that falsifies a PREMISE owes a grep for that premise's own words across the tree, not a list of the cards the finding's author happened to have open. The two are indistinguishable in the written card — both read as "and these cards need restating" — and only one of them is complete. Where the premise has a literal carrier (a filename, a phrase, a mechanism name), that literal IS the search; where it does not, the search is over the subtree the falsified card gates.

Recorded as a lesson as well as here.