PLANNING BUG — MOTIR-2306 bundled two axes of very different tractability and sized BOTH from a one-directory sample, and its AC pointed at a token that cannot hold the values it was routing

RECORD card — the correction is already applied. Logged by THE REPLAN ACTION step 5 during motir run MOTIR-2306 on 2026-08-07. No code, no PR; the lesson is notes.html #232 ("a sweep card whose routing instruction pointed at a destination that could not hold the values" — locate it by that title; the numbering shifts on append collisions, and this entry was renumbered 231 → 232 once for exactly that reason). It lands via motir-meta PR #134.

The defect

MOTIR-2306 was filed at 5 points / 150 minutes to "audit and route" every raw radius, own-padding and own-height utility in components/**, app/** and packages/design-system/src/**, and to guard the result. It was sized from a sample: seven escapes found by one grep in one directory while fixing MOTIR-2301. The card said so honestly — "One directory is not the count; it is the sample" — and then estimated as if it were.

Two things were wrong, and the second is the one that matters.

1. Mis-estimated. Measured on origin/main @ 7ffa2ba4: the radius axis is 62 sites in 34 files; the own-box padding/height axis is 447 literals in 190 files. The card also breached plan-rules gate 4 on its face — a coding_agent card's agent run must be ≤ 1h, and it was sealed at 150 minutes.

2. Internally contradictory — the AC named a destination that cannot receive the values. AC 1 required every raw own-padding utility to "name the element-semantic shape token CLAUDE.md maps its surface to". Each role has exactly ONE such token, and the code uses a scale against every one of them:

Satisfying AC 1 literally would re-pad 140 of 145 card surfaces — a full-app visual redesign, shipped under the title of a token cleanup. There was no correct way to do what the card asked.

Why it got written

The radius half and the padding half read as ONE defect because CLAUDE.md states them in one rule ("shape is radius + padding + sizing"), and the seven sampled sites happened to carry both — rounded-md px-1.5 py-1 looks like a single mistake with two halves. It is two, and only the radius half is a translation with a defined destination. Nothing in the filing pass asked whether the destination tokens could actually hold the values being routed to them; the tables were read as a mapping, and they are a mapping only for radius.

Fix applied (this pass)

1. MOTIR-2306 re-scoped IN PLACE to the RADIUS axis + the guard — 3 points / 60 minutes, with the inventory marked as a sample and the ACs written against the guard's own verdict rather than a site count.
2. MOTIR-2335 created as the story owning the own-box padding/height axis, blocked_by MOTIR-2306 (it extends that card's guard file), carrying the full measurement.
3. MOTIR-2336 created as its first subtask: DECIDE the density scale, because the sweep has nowhere to go until the token set can express the values in use.
4. notes.html #232 records the lesson (motir-meta PR #134).

Acceptance criteria

• The live tenant matches "Fix applied" above: MOTIR-2306 re-scoped to radius at 3/60, MOTIR-2335 exists blocked_by MOTIR-2306, MOTIR-2336 exists under it.
• The lesson is present on motir-meta's origin/main — git show origin/main:notes.html | grep -c 'mistake-num">232<' returns 1 and the entry is the one titled above. If a collision renumbered it again, correct the number here rather than assuming it.
• No code change and no PR carries this card — close it out by transition once the two checks above hold.

---

Close-out verification (motir run MOTIR-2337, 2026-08-07)

Every citation on this card was re-executed by CONTENT, not trusted. All of them are exact — say so plainly rather than implying drift that was looked for and not found. This is the rare record card whose numbers all survive re-derivation.

The remedy's CODE was read, not its status (MOTIR-2306 is done, which by this card's own argument proves nothing). tests/theme/shapeSwapLint.test.ts shipped in c7d1bee2 (PR #1907) and independently restates this card's finding in its own comments — "this guard is deliberately silent on [padding and height], and its silence is NOT permission", the 5-of-145 measurement, the deferral to MOTIR-2335 / MOTIR-2336 by key, and the own-box ↔ layout distinction MOTIR-2335's ACs require. The guard asserts offenders equal to an enumerated allowlist, not a count — which is exactly the re-scope this card claims was made.

Promote question: LESSON, both defects. Do not re-open.

This card poses no promote question of its own, but the verdict is recorded so the next reader does not re-litigate it.

Defect 1 (sized from a one-directory sample) — a diligence miss, not a trigger gap. plan-rules.md's THE UNIT OF A MIGRATION IS THE SET OF CALLERS, NOT THE MECHANISM already reaches this case exactly: "when the card's verb is move / migrate / replace / route through / retire, grep for every caller of the mechanism being replaced BEFORE sizing it and list them in the card … there is no third option", plus "an absolute word (entirely / all / no longer / every) about a mechanism is a claim over a SET." MOTIR-2306's title verb is "route them"; its AC 1 said "every raw radius, own-padding and own-height utility". The rule landed in both homes at 0192e05, 2026-08-05 01:24Z; MOTIR-2306 was authored 2026-08-06 16:45Z — 39h21m later, same planner, one grep away. A rule that was performable and not run is a diligence problem. (Same rule, same verdict, same day: MOTIR-2339.)

Defect 2 (the destination could not hold the values) — a real trigger gap, and still a LESSON. It is genuinely absent from both homes: plan-rules.md's CARDINALITY gate asks "how many of these can there be" about an entity the product owns for a user, which is the entity's own multiplicity; this is the inverse — a singular destination and a many-valued source set, a fan-in property of a routing instruction. The nearest notes.html neighbour, #187, is a different mechanism (an AC unsatisfiable because the substrate did not exist — an existence failure); here every existence check passes, which is this card's own point. Family by content: ONE. Three grounds for not promoting anyway:

1. Register. The check cannot be stated without the incident (one card-padding token, nine card paddings) — which is the definition of a lesson, not a rule.
2. The genre corrected itself, in code and in the plan. The shipped guard writes the finding into its own comments, and MOTIR-2335's first subtask is a DECISION about the token set precisely so no sweep is ever authored against a vocabulary that cannot receive it. A check already being performed does not need a gate.
3. Adjacent-axis precedent. MOTIR-2339, closed the same day on the neighbouring axis, resolved LESSON on the same discriminator.

It does clear the lesson store's own gate (generalizability — "a routing instruction's destination must be able to receive the value set being routed into it" states with no local names), so it is routed to MOTIR-1948, which owns the un-seeded lessons.base.ts batch. No new card is owed.

Drive-by finding (its own card, per notes.html #27)

Checking whether the CARDINALITY gate covered defect 2 surfaced something else: gate 3 is the only entry in plan-rules.md's per-card gate checklist with no presence at all in SHARED_PLANNING_RULES. Its repo-specific corollaries crossed (the mirror carries "the one-repo project is the DEGENERATE CASE of the same rule" and the boundary split), but its general trigger — "whenever a card names a THING the product will own, create, or resolve on a user's behalf, ask how many of these can there be, and what decides that?" — did not: cardinal / CARDINALIT / how many can there be / singular noun all return 0 on origin/main, while every sibling gate returns 1–18 hits. Filed as its own card; not a defect of this record.