Planning bug: a mechanism-withdrawal amendment swept four of five dependents — the one it missed was the one whose SCOPE had not moved

A mechanism-change amendment swept four of its five dependents and left the fifth describing the withdrawn mechanism. Found by motir run MOTIR-3440 on 2026-08-26, reaching MOTIR-3443 after its blocker landed. Nothing was built; the correction is on plan cmt9uqb2n0094i2n8fxh6i32h.

What happened

MOTIR-3492 established that a route-level loading.tsx flushes the response head before the page function runs, destroying the 404 on every route beneath it that decides existence. Its amendment to MOTIR-3440 withdrew the group-boundary mechanism story-wide and carried a "Per-child, the clauses that change" table naming MOTIR-3443, MOTIR-3444, MOTIR-3449 and MOTIR-3450.

MOTIR-3448 is not in that table, and it describes the withdrawn mechanism in four places:

• "The boundary they arrive on is shipped by the project-settings card — app/(authed)/settings/loading.tsx covers every route under settings/, these four included — which is why this card waits on it and adds no boundary of its own."
• Boundary: "It adds no loading.tsx (the family boundary is the sibling card's)."
• AC: "Arriving at each of the four by typed URL shows the settings frame the sibling card shipped — no page-level boundary is added here."
• Context refs: "ships app/(authed)/settings/loading.tsx, which these four inherit."

Its own settings/organization/billing is one of the eleven existence-deciding routes — the very route the A/B was run on. So the card was blocked-shaped, structurally valid, and premised on a file that may not exist.

Evidence

Swept all five children of MOTIR-3440, descriptionMd + explanationMd, with the pattern loading\.tsx · inherit · group's frame · family boundary · covers every route · the boundary they · no boundary of its own:

MOTIR-3440  loading.tsx=7  inherit=1                                        (the amendment itself)
MOTIR-3443  loading.tsx=13 inherit=1  the-boundary-they=1                   (amended; re-scoped by the plan)
MOTIR-3448  loading.tsx=4  inherit=1  family-boundary=1  covers-every-route=1
                           the-boundary-they=1  no-boundary-of-its-own=1    ← UNSWEPT
MOTIR-3449  loading.tsx=4                                                   clean — asserts the /items ABSENCE
MOTIR-3450  loading.tsx=2                                                   clean — same

⚠️ The pattern is a sample of the claim's WORDING, not a verdict on the surface. It matched because MOTIR-3448 happened to name the file; a dependent that had expressed the same inheritance in its own words would not have been found by it. That is why the fix below is not a better pattern.

Why the sweep felt complete

plan-rules/op-replan.md already carries the rule, twice over:

• (a) "A decision's own list of affected cards is the sweep's INPUT, never its evidence" — and "a better-written decision makes this MORE likely, not less, because the more completely it enumerates its dependents the more finished the enumeration feels." The amendment's table is a good table. It is four-fifths of the answer.
• (c) "a pass that edits every card whose SCOPE moved and skips the one whose MECHANISM moved, because its scope did not move." MOTIR-3448's scope never moved — it is the same four pages it always was. Only the world underneath it changed.

So this is a recurrence of a rule already in the corpus, not a missing rule — the same class as MOTIR-3494, "the referrer sweep was done by memory, not by grep." MOTIR-3494's remedy was to grep instead of remember; this instance shows that is not sufficient, because the grep's pattern is itself authored from memory of the wording.

The still-open decision this does NOT settle

What makes a mechanism-change sweep verifiable rather than diligent. The proposal worth weighing: a sweep's evidence is the container's CHILD SET, enumerated from the tree — a set that is complete by construction and that get_work_item already returns with each child's dependency edges in one call — with a per-child disposition recorded, including "read, unaffected, because …". That converts "I looked" into "here are N children and what each one was", and it is checkable by a reader who was not there. An amendment's own enumeration would then be its input, which is what the rule already says it is.

Whether that belongs in op-replan.md as a sixth corollary, or is mechanised as an advisory (the reference family already computes something adjacent), is not decided here.

What this bug does NOT hold up

Nothing. The correction is already submitted as plan cmt9uqb2n0094i2n8fxh6i32h, which re-scopes MOTIR-3448 and MOTIR-3443 and adds the frame-module card. This card is telemetry about the planner.