Skip to content

moooon

Motir

Vibe your whole project. Bring an idea — Motir's three AI layers plan it, track it, and ship it, end to end. You're looking at Motir, built in Motir.

  • Vibe Project
  • Open Source
  • AI Agent
  • AI Loop
1
requests
0
upvotes
145
planned
1,361
shipped

Motir · Work items

MOTIR-3991Done

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

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:

inkresolvedon --el-cardon --el-surfaceon --el-page-bg
--el-status-done (light)#1aae392.93:12.69:12.93:1
--el-status-done (dark)#1aae396.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:

  1. 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-charcoal flips), and leaves --color-success untouched — 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.
  2. Re-tune --color-success itself 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-done clears 3:1 against --el-card, --el-surface and --el-page-bg in 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 themesstatusHueSeparation.test.ts's existing sweep, with KNOWN_TOO_CLOSE still [].
  • Whichever remedy is taken, every OTHER consumer of the moved token is re-measured and the result stated: if --color-success moves, that is --el-success-surface and 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's KNOWN_SUB_BAR loses its --el-status-done entry 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.md beside 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-straddle on criterion 4, path: "motir/light", reason: "contradiction"FALSE POSITIVE, and the criterion has been reworded so it no longer fires. motir/light was an allowlist KEY (palette / theme), not a repository path; the detector read the slash as <repo>/<path> and reported a straddle against targetRepo: 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 reads KNOWN_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.