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
144
planned
1,365
shipped

Motir · Roadmap

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

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:

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.

Discussion

No comments yet.

Adding to this discussion signs you in on app.motir.co and brings you back to this request.

Add a comment