Motir

Found while running MOTIR-3693 (shipped as motir-core#2366).

The defect

MOTIR-3693's whole subject is "a guard that models a set by enumerating NAMES, over a set that is actually defined by VALUE". Its own population was enumerated the same way — by reading design/settings/ and listing the six assets in it:

Six assets in design/settings/ carry it, all descended from the same shell: account-settings · profile · two-factor · passkeys · appearance · token-scopes

Measured by running the widened guard over the tree instead:

git log --diff-filter=A on the thirteen extra assets: twelve predate the card (oldest design/ready/ready.mock.html, 2026-06-07; card filed 2026-08-27T11:33). So the enumeration was wrong when it was written — not drift.

⚠️ Provenance of every figure above. They are the guard's output on branch subtask/MOTIR-3693-sidebar-bg-tinted-surface at bca7fb1b1 (base origin/main 783280a6b), where TINTED_SURFACE_TOKENS is total. They are not reproducible on origin/main until motir-core#2366 merges — on main the same command reports 0, which is the defect. To re-measure after the merge: vitest run --config vitest.design.config.ts plus tests/theme/inkContrastLint.test.ts, with '--el-sidebar-bg' deleted from TINTED_SURFACE_TOKENS to reproduce the before-state. The --diff-filter=A dates are properties of history and hold on any ref.

Two consequences the wrong count actually had

1. The card's storyPoints: 2 / estimateMinutes: 45 were sized against 6 files. The delivered sweep is 41 files including 17 re-exported PNGs. A card sized off a hand-count is a card whose estimate is a hand-count.
2. The card's "Not this bug" section asserted a NEGATIVE from the same un-run guard. It excluded design/settings/account-data.mock.html as "already uses --el-text-secondary and measures 0 AA failures in both themes". That asset carries 24 pairs — the exclusion was written from a sweep performed with the very blind spot the card was reporting. A negative measured with the broken instrument reads exactly like a negative.

What would have prevented it

The card had, at authoring time, everything needed to count correctly: the guard source, the alias, and a one-line patch. Adding the token to TINTED_SURFACE_TOKENS and running vitest --config vitest.design.config.ts — the card's own step 3 — produces the true population in seconds. The count was taken by ls over one folder instead.

This is the ENUMERATION limb of plan-rules/phase-deepen.md (a card COUNTING a population owes the ref the count was taken on) applied one turn earlier than it usually fires: the population here is not defined by a ref but by a predicate the card itself is about to make computable. A card whose fix WIDENS a guard should state its population as the guard's output after the widening, not as a hand-read of the folder the reporter happened to be standing in.

Fix direction

plan-rules/phase-deepen.md's ENUMERATION limb currently asks for the REF a count was taken on. Add its corollary: where the card's own fix makes the population mechanically computable, the count is owed from that mechanism, and the card says which command produced it. A hand-count is then visibly not the instrument, rather than indistinguishable from one.

Related shape: the same card's fix direction step 1 asserted a code dependency in the wrong direction ("inkContrastScan.ts imports SAFE_SURFACE_TOKENS from the same place" — the import runs the other way), which is the precondition-verification rule, already written. That half needs no new rule; this half does.

Not this bug

The AA defect itself, the guard widening and the 247-pair sweep are MOTIR-3693 and shipped. This card is about how the population was counted.