Motir

Surfaced while running MOTIR-3933. Not caused by it — reproduced against origin/main's stylesheet with that branch's changes excluded, and filed rather than absorbed.

The measurement

Headless chromium, git show origin/main:packages/design-system/theme.css, base palette (motir), no data-palette attribute set — i.e. what every default install renders:

tests/theme/statusHueSeparation.test.ts sets 3:1 for exactly these pairs — WCAG 1.4.11 for a graphical object — and names --el-card and --el-surface as "the surfaces the dot sits on". The other three status inks clear it; implemented does not, on any of the three.

The dark theme is fine, and so is every non-base palette that overrides the token. It is the DEFAULT palette in the LIGHT theme, which is what a fresh install and every screenshot in the product show.

Why no guard caught it

statusHueSeparation's sweep is deliberately over OVERRIDES, and says so in its own line:

if (!(token in block)) continue; // rides its --color-* source; not an override

motir is the base palette and historically declared no block at all, so every one of its status inks rides its --color-* source and is skipped. The guard is not wrong about what it measures — it is a guard on overrides that has never been able to see the values everything else is measured against. The bar exists, the base palette is exempt from it by construction, and nothing says so.

This is how it became visible. MOTIR-3933's first attempt gave motir a real [data-palette='motir'] block; the guard immediately read those declarations as overrides and reported these two failures. That attempt was then re-scoped to [data-appearance-scope] for unrelated and better reasons — the root cascade must stay untouched — which takes the base palette back OUT of the guard's reach. So the defect is once again unmeasured, and this card is the only record.

Acceptance criteria

• --el-status-implemented clears 3:1 against --el-card, --el-surface and --el-page-bg in the base palette's light theme, without moving the hue far enough to collide with a sibling status (statusHueSeparation's ΔE bar is the other side of that trade and must still pass).
• The guard stops exempting the base palette. Whatever the mechanism — a base row in the sweep's context list, reading the resolved value rather than the declared block, or an explicit base fixture — the four status inks are measured for motir in both themes, and the change FAILS before the ink is fixed.
• The same exemption is checked for statusPrioritySurfaceTokens and familyHueSeparation, which derive their populations from the stylesheet the same way. Any that also skip the base palette is named here with its verdict — fixed, or recorded as deliberately override-only with the reason.
• No [data-palette='motir'] block is added at :root to make the guards see it. That was the first attempt and it changes what every page renders in order to satisfy a test; the base values must be reached the way the browser reaches them.

Boundary

motir-core, packages/design-system/theme.css and tests/theme/. It does not touch StyleVignette, the scope attribute or the nested-preview work — those are MOTIR-3933, already open. It does not publish the package.