The base palette's `done` status dot is 2.93:1 on the card it sits on — the second ink under 1.4.11's 3:1, and the one that rides a Tier-0 semantic three other families spend
Opened by Zhu Yue ·
Found by MOTIR-3954's widening, not by it. That card taught tests/theme/statusHueSeparation.test.ts to measure the BASE palette, which had been exempt from the 3:1 bar by construction; the sweep then returned two sub-bar status inks rather than the one the card was filed about. implemented is fixed there. This is the other one, carved out under a named reason (KNOWN_SUB_BAR) and filed rather than absorbed.
The measurement
Resolved through tests/theme/paletteCascade.ts off packages/design-system/theme.css at origin/main (commit 0068da2f4), base palette motir, no data-palette set — what a default install renders:
| ink | resolved | on --el-card | on --el-surface | on --el-page-bg |
|---|---|---|---|---|
--el-status-done (light) | #1aae39 | 2.93:1 ✗ | 2.69:1 ✗ | 2.93:1 ✗ |
--el-status-done (dark) | #1aae39 | 6.53:1 ✓ | 5.93:1 ✓ | 6.53:1 ✓ |
Light only, and it misses by ~2%. Every one of the nine other palettes clears the bar for this token.
Why it is not MOTIR-3954's one-token step
--el-status-implemented rode --color-accent, a decorative Tier-0 hue no other semantic surface spends, so it could take a step toward the ink in the Tier-3 base block and move nothing else. --el-status-done rides --color-success (#1aae39), which is not free: the same source paints --el-success-surface's companion ink, the success toast/notice family and the chart-success step, and every one of those has its own bar (AA text on a tint is a different floor from 3:1 for a graphical object, and they pull in opposite directions). Moving --color-success is a ten-palette decision with a documented per-palette write-up each (docs/palettes/*.md), which is why it is its own card.
Two remedies, both real, and choosing between them IS the work:
- Give the status ramp its own step, as MOTIR-2073 / MOTIR-2075 did for five palettes and MOTIR-3954 did for
implemented:--el-status-done: color-mix(in srgb, var(--color-success) N%, var(--color-charcoal))in the Tier-3 base block. Cheapest, theme-adaptive (--color-charcoalflips), and leaves--color-successuntouched — but it changes the base recipe for every palette that rides it, so the ΔE2000 ≥ 10 floor has to be re-measured across all twenty palette × theme pairs. - Re-tune
--color-successitself in the base Tier-0 layer to a darker green step. Fixes the ink everywhere at once and is the honest answer if the other success surfaces are also marginal — measure them first, because that turns this into a bigger card.
Read docs/palettes/motir.md before choosing: the base palette is the one whose reasoning every other palette's document refers back to.
Acceptance criteria
--el-status-doneclears 3:1 against--el-card,--el-surfaceand--el-page-bgin the base palette's light theme, and stays clear in dark.- The ΔE2000 ≥ 10 separation floor still holds for the whole status ramp in all ten palettes × both themes —
statusHueSeparation.test.ts's existing sweep, withKNOWN_TOO_CLOSEstill[]. - Whichever remedy is taken, every OTHER consumer of the moved token is re-measured and the result stated: if
--color-successmoves, that is--el-success-surfaceand the success notice/toast inks at their own AA bar; if only the status step moves, it is the four palettes that ride the base value for this token. tests/theme/statusHueSeparation.test.ts'sKNOWN_SUB_BARloses its--el-status-doneentry for the base palette's light theme, and the suite is red until it does — the map is asserted in both directions, so the carve-out cannot outlive the defect. This is the criterion that closes the loop MOTIR-3954 opened.- The per-palette reasoning is recorded in
docs/palettes/motir.mdbeside the existing status-ramp notes, in the house shape those files use.
Boundary
motir-core, packages/design-system/theme.css, tests/theme/ and docs/palettes/motir.md. It does not touch --el-status-todo (--color-stone, the documented decorative step that the suite exempts by design in every palette), it does not re-open MOTIR-3954's implemented step, and it does not publish the @motir/design-system package.
Advisory dispositions (at filing)
likely-repo-straddleon criterion 4,path: "motir/light",reason: "contradiction"— FALSE POSITIVE, and the criterion has been reworded so it no longer fires.motir/lightwas an allowlist KEY (palette / theme), not a repository path; the detector read the slash as<repo>/<path>and reported a straddle againsttargetRepo: motir-core. The criterion now names the palette and theme in prose. Nothing about the card's scope changed — it is one repository,motir-core, in every criterion.blockers: [MOTIR-3954, in_progress]— CORRECT, and deliberate. Criterion 4 readsKNOWN_SUB_BAR, which exists only on MOTIR-3954's unmerged branch. The card is not startable until that merges, and the edge is what says so.
Discussion
No comments yet.
Adding to this discussion signs you in on app.motir.co and brings you back to this request.