fix(cli-registry): correct accent colours, and a real gemini/antigravity/omp rendering bug - #463
Open
opticon454 wants to merge 1 commit into
Open
opticon454 wants to merge 1 commit into
opticon454 wants to merge 1 commit into
Conversation
…ity/omp rendering bug
Two related fixes, found while re-measuring stock.ts's `accent` field
against the actual rendered UI (docs/cli-registry.md flags this field as
"transcribed, not authoritative — re-measure before wiring one up"):
1. A real, user-visible 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
rendered as plain claude-blue on every skin except `og` — including
`daylight-blue`, which is the actual DEFAULT skin for a fresh install
(index.html's pre-paint script), not an edge case. Added the three
missing rules, sourced from each CLI's own already-designed og-skin
colours (no new colours invented), mirroring the exact pattern
pi/grok/deepseek already use. Also corrected the stale comment on the
pi rule, which claimed this was still broken for gemini/antigravity.
2. `stock.ts`'s `accent` field was simply wrong for most CLIs — e.g. 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. 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 gradient resolves
around) and corrected all 9 non-shell entries to match. `accent` has no
reader yet (confirmed via the DECLARED_FOR_LATER guard test), so this
changes no rendered output — it's a data-accuracy fix, matching the
registry's own "transcribed, not authoritative" warning taken literally.
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 variable exists anywhere in the codebase.
Full gate: 406 files / 7721 tests / 0 failures, typecheck/lint/format:check/
check:public-assets/check:frontend-syntax all clean.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GuHtuPiHXdykq9T6rKQJ9n
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
While reviewing #458, I compared
stock.ts'saccentfield (declared but not yet read, perdocs/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-antigravityand.mode-omphad no override rule inside thehtml:not([data-skin="og"])block — unlike codex/pi/grok/deepseek, which do. The generic.btn-toolbar.btn-runrule 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 exceptog— includingdaylight-blue, whichindex.html's pre-paint script sets as the actual default for a fresh install with nolocalStorageyet. 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.
accentitself was wrong for most CLIsMeasured each CLI's real
border-colorfrom 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.accenthas no reader yet (confirmed via theDECLARED_FOR_LATERguard test intest/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 grepconfirms 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