fix(cli-registry): correct accent colours, and a real gemini/antigravity/omp rendering bug

[opticon454]

Context

While reviewing #458, I compared stock.ts's accent field (declared but not yet read, per docs/cli-registry.md's own "transcribed, not authoritative — re-measure before wiring one up" warning) against the actual rendered .btn-toolbar.btn-run.mode-<id> CSS, and found two separate things worth fixing.

1. A real, user-visible rendering bug

.btn-toolbar.btn-run.mode-gemini, .mode-antigravity and .mode-omp had no override rule inside the html:not([data-skin="og"]) block — unlike codex/pi/grok/deepseek, which do. The generic .btn-toolbar.btn-run rule in that block resolves at higher specificity than the base sheet's per-mode pair, so all three CLIs rendered as plain claude-blue on every skin except og — including daylight-blue, which index.html's pre-paint script sets as the actual default for a fresh install with no localStorage yet. Not a corner case; the out-of-the-box experience for gemini/antigravity/omp buttons.

Fixed by adding the three missing rules, sourced from each CLI's own already-designed og-skin colours (no new colours invented) — same pattern pi/grok/deepseek already use. Also corrected a stale comment on the pi rule that claimed this was still broken for gemini/antigravity (it predated omp joining the registry and was already half wrong).

2. accent itself was wrong for most CLIs

Measured each CLI's real border-color from its own .mode-<id> rule on the og skin (the cleanest single representative hex each entry's multi-stop gradient resolves around) and corrected all 9 non-shell entries. Examples: claude was registered as Anthropic's brand orange (#d97757) while its button renders blue; antigravity was registered purple while it renders cyan; pi was registered green while it renders pink.

accent has no reader yet (confirmed via the DECLARED_FOR_LATER guard test in test/cli-registry-no-id-branching.test.ts), so this changes no rendered output on its own — pure data-accuracy.

Also fixed a false claim in types.ts's doc comment for the field ("CSS derives every per-CLI gradient from it via --cli-accent") — no such CSS custom property exists anywhere in the codebase; git grep confirms it.

Verification

Full CI gate, typecheck, lint, format:check, check:public-assets and check:frontend-syntax all run against a fresh clone of current master (not an incremental branch) on a tmux-capable VM: 414 files, 7828 tests, 0 failures.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01GuHtuPiHXdykq9T6rKQJ9n

[Ark0N]

Merged, thanks @opticon454! This ships in 1.32.1.

Good catch, and a real one: Gemini, Antigravity and OMP were rendering in Claude blue on every skin except OG, which means that was the out-of-the-box look for three of the ten run modes. I reproduced it against the merge base before reading the diff.

I applied a few things at merge instead of sending it back:

• On phones the gear half of the Gemini/Antigravity split button still lost to the nested skin rule, so the button went two-tone. Added the !important pair in mobile.css like pi/grok/deepseek have.
• Added a guard in test/skin-themes.test.ts that derives every .mode-<id> run rule from styles.css and fails if its counterpart inside the html:not([data-skin="og"]) block is missing. This trap had been patched by hand four times, so it seemed worth pinning.
• Grok's accent comment now names zinc-300, the "(below)" in types.ts points up, and docs/cli-registry.md plus CLAUDE.md now say accent is measured rather than transcribed.
• Gemini's accent is #8ab4f8, matching its tab badge and run-mode dot, since that is the one hex that names the CLI everywhere else.