feat(tui): add Dune Dark theme and keep light Dune - #713
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
WalkthroughThe PR updates the Dune palette, adds and registers the Dune Dark theme, expands ANSI contrast validation, and updates theme documentation and release notes. ChangesDune theme
Estimated code review effort: 3 (Moderate) | ~20 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Vasanthdev2004
left a comment
Vasanthdev2004
left a comment
There was a problem hiding this comment.
Small, clean change: Dune is reassigned from the warm light-sand palette to a dark, daltonized palette with IsDark correctly flipped to true, and the wiring test is updated to match. The full tui suite passes, including the truecolor and xterm-256-quantized WCAG-AA contrast guards covering Dune's selected-row, diff-band, and status-color pairs, so the new colors hold up on 256-color terminals too. No objections — approving.
4631efa to
da6cb17
Compare
Status
Ready for human review/approval. |
2389075
jatmn
left a comment
jatmn
left a comment
There was a problem hiding this comment.
I found issues that need to be addressed before this is ready.
Findings
-
[P2] Preserve Dune's diff identity on ANSI-256 terminals
internal/tui/theme_palettes.go:455
In a 256-color terminal, the repository's ownxterm256Hexalgorithm maps bothaddBg(#0a1f14) anddelBg(#240a0e) to#121212; it likewise maps both word-span backgrounds to#303030. Added and removed diff bands therefore become identical (and the base bands blend into the panel) for Dune users, contrary to the claimed colorblind/xterm behavior. Choose backgrounds that quantize to distinct green/red entries and add Dune equivalents of the existing Neon ANSI-256 diff assertions. -
[P2] Update the public Dune description
docs/THEMES.md:12
The guide still says Dune is a warm sand-and-cream palette with charcoal ink and a soft amber accent. This change makes the same user-selectable theme near-black with white/orange and daltonized blue/red signals, and registers it as dark. Update the documentation with the new appearance so--theme dune,ZERO_THEME=dune, and the picker are described consistently.
|
Pushed a fixup addressing both open findings:
Verified go build ./..., go vet ./..., and internal/tui tests (theme-specific tests all pass; there's one unrelated pre-existing failure, TestAltScreenTranscriptScrollKeepsFooterFixed, that also fails on the unmodified branch since it needs a TTY). Checked gofmt cleanliness with git diff --check against upstream/main on the changed files, no issues. |
Dune was rendering as a light/sandy theme with a 55/55/55 grey surface, which did not match Claude Code's dark colorblind mode. Rebase the palette on a near-black surface (#0e0e10) with the brand-orange accent from openclaude's dark-daltonized theme, and move the warm grey to the user-prompt bubble only. Brighten the muted/faint/faintest gray ramp and darken selBg/addBg/delBg so all WCAG-AA and xterm-256 contrast invariants hold. Updates the stale test that still marked Dune as light. Refs Gitlawb#709
Empty commit to re-run CI. Prior Windows smoke failed on TestRunExecOptimizedSessionUnderGate (0 prewarm HEAD probes), which is unrelated to the Dune palette change.
waitFor polled QueueDepth(), which flips as soon as a slot is leased, before the worker is registered in p.active by track(). Drain() only sees stragglers in p.active, so a wide enough scheduling window let it observe an empty active set and return without killing anything. Windows CI's coarser goroutine scheduling was wide enough to hit this reliably; wait on WorkerStats() instead, which reflects p.active.
Dune's addBg/delBg (#0a1f14/#240a0e) and addBgWord/delBgWord (#1f4d33/#4d1620) each quantized to the same xterm-256 gray (#121212 and #303030), making added and removed diff lines indistinguishable on terminals without truecolor support. Rebase the four diff band colors on stronger green/red channel separation so they quantize to distinct xterm cube colors, following the pattern Neon already uses. Adds the Dune equivalent of Neon's ANSI-256 diff-band assertions in TestExtendedThemeANSI256Contrast. Also updates the Dune entry in docs/THEMES.md, which still described the old warm sand/cream/amber palette instead of the dark colorblind-safe one this PR introduced.
4efe601 to
c8ee46c
Compare
|
Rebased onto current upstream main (was 17 commits behind). Clean replay, no conflicts. Local: theme/palette-focused |
jatmn
left a comment
jatmn
left a comment
There was a problem hiding this comment.
I found issues that need to be addressed before this is ready.
Findings
- [P2] Preserve readable added diffs on ANSI-256 terminals
internal/tui/theme_palettes.go:459
buildThemerenders the changed palette as actual add-diff foreground/background pairs, but ANSI-256 quantization makes them unreadable:greenonaddBgbecomes#5f87ffon#005f00(2.43:1) for the add sign,faintestonaddBgbecomes#9e9e9eon#005f00(2.97:1) for the line-number gutter, andaddInkonaddBgWordbecomes#afffd7on#008700(4.06:1) for changed-word text. Thus--theme dunefails AA/readability for core added-diff content on 256-color terminals. The new Dune assertions check only green/red band identity, whereas the existing Neon section tests these rendered text pairs. Please choose quantization-safe Dune colors and add the equivalent Dune assertions.
The prior fix made Dune's add and del diff bands quantize to distinct xterm-256 colors, but the foreground/background pairs rendered on top of them were not checked and fail AA once quantized: green on addBg drops to 2.43:1, faintest on addBg to 2.97:1, and addInk on addBgWord to 4.06:1. Brighten green, faintest, and addInk so each pairing clears 4.5:1 after xterm-256 quantization, matching the bar Neon already holds. Add the equivalent Dune assertions to TestExtendedThemeANSI256Contrast, mirroring the existing Neon checks for these rendered text pairs.
|
Addressed the latest finding: the add-diff bands were distinct after xterm-256 quantization, but the text rendered on top of them wasn't checked and failed AA. Changed in Dune:
faintest and green both needed a hue shift, not just a brightness bump: at the same brightness a neutral gray/blue can't clear 4.5:1 against xterm's quantized green background (the math works out the same way Neon's own faintest is tinted green rather than staying pure gray). Del-side pairs (red/faintest/delInk on delBg) were already fine and are untouched. Added the equivalent Dune assertions to
|
There was a problem hiding this comment.
I found issues that need to be addressed before this is ready.
Findings
-
[P2] Keep the selected row visibly distinct after ANSI-256 quantization
internal/tui/theme_palettes.go:464
On an ANSI-256 terminal, the repository'sxterm256Hexmapping turns the new Dune panel (#0e0e10) into#121212andselBg(#191c1f) into#1c1c1c. Their contrast is only 1.099:1, just below the 1.10 selected-row visibility threshold enforced byTestSelectedRowBandIsVisibleAndReadable.onSeluses this background for the selected permission choice and every selectable list, so the active row remains effectively indistinguishable in the terminal mode this PR explicitly claims to support. Choose a selection color that quantizes farther from the panel and add the panel-vs-selection ANSI-256 assertion. -
[P2] Split the unrelated daemon test repair out of this palette PR
internal/daemon/pool_test.go:227
This is a separate current scope-policy blocker, not a claim that the test repair is incorrect: it repairs a Windows scheduling race inTestPoolDrainKillsStraggler, but the PR description, its Dune-theme claim, and its cited reference contain no approved daemon scope. The repository policy requires each community PR to stay focused on its approved issue. Move this change to its own approved daemon issue/PR (with its race validation) so the Dune palette review remains auditable.
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
internal/tui/theme_select_test.go (1)
449-455: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winCheck hue identity after quantization.
greenishandreddishinspect the original hex values, while the test claims to validate xterm-256 output. A future palette could quantize to a neutral or wrong-hue color and still pass these assertions.Proposed fix
- if q(dune.addBg) == q(dune.delBg) || !greenish(q(dune.addBg)) || !reddish(q(dune.delBg)) { + if q(dune.addBg) == q(dune.delBg) || !greenish(q(dune.addBg)) || !reddish(q(dune.delBg)) { ... - if q(dune.addBgWord) == q(dune.delBgWord) || !greenish(q(dune.addBgWord)) || !reddish(q(dune.delBgWord)) { + if q(dune.addBgWord) == q(dune.delBgWord) || !greenish(q(dune.addBgWord)) || !reddish(q(dune.delBgWord)) {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@internal/tui/theme_select_test.go` around lines 449 - 455, Update the quantized palette assertions in the dune checks to evaluate hue identity on the quantized xterm-256 values, not the original hex colors. Ensure both add/del row bands and word-span bands remain distinct and green/red respectively after quantization, using the existing q, greenish, and reddish helpers.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@internal/tui/theme_select_test.go`:
- Around line 449-455: Update the quantized palette assertions in the dune
checks to evaluate hue identity on the quantized xterm-256 values, not the
original hex colors. Ensure both add/del row bands and word-span bands remain
distinct and green/red respectively after quantization, using the existing q,
greenish, and reddish helpers.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 917ede12-fa90-44e0-ae81-b4fd02cec874
📒 Files selected for processing (2)
internal/tui/theme_palettes.gointernal/tui/theme_select_test.go
🚧 Files skipped from review as they are similar to previous changes (1)
- internal/tui/theme_palettes.go
|
Addressed both open findings from @jatmn's latest review:
All theme & palette tests pass (go test ./internal/tui/ -run 'Theme|Palette|Dune|Contrast|ANSI'). Ready for re-review! |
Vasanthdev2004
left a comment
Vasanthdev2004
left a comment
There was a problem hiding this comment.
Approving, same as my earlier pass before it was dismissed by the push.
The coverage question I wanted answered is answered: this is not just an IsDark == true flip. The registry-wide suites pick the new palette up automatically and the numbers are healthy (ink 16.35, muted 12.06, accent 8.86 on panel, ink-on-selBg 12.83, selBg-vs-panel 1.27, plus the quantized xterm-256 pairs). I also confirmed the unrelated internal/daemon/pool_test.go change from the earlier revision is NOT in this head, only the three intended files.
Two colour nits, neither blocking:
faintest(#55c6cd) ended up close enough togreen(#5eccfa) that the two are hard to tell apart, and they render side by side in diff line numbers. Worth nudging one of them.gitAdd(#7db87a) andgitDel(#b87a7a) are carried over byte-identical from the Lime dark palette, so the one green/red pair that daltonization exists to fix is the pair that did not get daltonized. Given the palette is described as colorblind-safe, that is the pair I would most want adjusted.
Verification note: the go toolchain is blocked on my machine by Smart App Control right now, so this is a source review; CI is green.
LGTM.
|
@kevincodex1 merge pls big bro |
jatmn
left a comment
jatmn
left a comment
There was a problem hiding this comment.
miss marked my last review
Updated
LGTM
gnanam1990
left a comment
gnanam1990
left a comment
There was a problem hiding this comment.
Verdict
Changes requested — on the process gate and on scope, not on the engineering. The contrast work in here is real, I reproduced the defect it fixes, and the new assertions are the most valuable part of the patch. The problem is that a measured accessibility bug and an unapproved re-theming are riding in the same change.
Reviewed at a57cf8a, base a50574f (origin/main at 097c265).
What I verified
-
The underlying defect is genuine, and I measured it. Checking out the base
internal/tui/theme_palettes.gounder this PR's tests reproduces it exactly:--- FAIL: TestExtendedThemeANSI256Contrast dune: add/del row bands lose their green/red identity after quantization: addBg #dcecd0 -> #dadada, delBg #f5dbd5 -> #ffd7d7Dune's added-line band quantizes to a neutral grey on 256-colour terminals, so added and removed lines stop reading as green and red. That is a legitimate accessibility bug and it is worth fixing.
-
The new assertions are load-bearing, which is the check I care most about. Reverting only
theme_palettes.goand keeping the tests fails bothTestExtendedThemeANSI256ContrastandTestNewThemePresetsWired— they are testing the palette, not describing it. -
go test ./internal/tui/ -run 'Theme|Contrast|Wired' -count=1passes on the branch. Ran on darwin/arm64 from a non-/tmpcheckout.
Blocking
-
No parent issue carrying
issue-approved. — PR descriptionThe description says
Refs #709. #709 is not an issue; it is a merged pull request (fix(tui): fix rendering corruption over multipass + Windows Terminal) —gh api repos/Gitlawb/zero/issues/709returns apull_requestfield. I searched the tracker for an issue covering the Dune palette and found none; the closest, #633, is about adding new theme presets, is unlabelled, and does not cover changing an existing one.CONTRIBUTING.mdmakes the label the gate for community PRs, ahead of code quality, so this needs an issue before it can be judged on merit. I would rather say that now than have it closed later on process after the work is already done. This is a paperwork outcome, not a comment on the contribution. -
The patch is substantially larger than the defect it demonstrates. —
internal/tui/theme_palettes.goWhat the reproduction above shows is that
addBg/delBg(and the word-span bands) do not survive xterm-256 quantization. Fixing that needs those bands adjusted. What this PR does instead is rebase the entire theme onto a near-black surface, invertIsDark, and rewrite Dune's description indocs/THEMES.mdfrom "a warm sand-and-cream palette" to "a dark, colorblind-safe palette".Two consequences that need a maintainer's decision rather than a reviewer's:
- Dune is a shipped theme with a published identity. Users who selected it chose a light warm theme; after this they get a near-black one under the same name. That is a product change, and
CONTRIBUTING.mdputs unapproved feature work outside what a PR may carry. - It reduces light-theme coverage from three to two. After the change
themeRegistry(internal/tui/theme_palettes.go:488-501) holds twelve dark entries and two light ones —lightandsolarized-light— and Dune was the only warm light option. Whether the catalogue should keep a warm light theme is exactly the kind of call that belongs in an issue.
The clean split, if the maintainers agree the dark variant is wanted: fix Dune's diff bands in place so it stays light and passes the new quantization assertions, and add the daltonized dark palette as a new registry entry under its own name. That keeps both audiences, keeps every assertion in this PR, and needs no product decision to be reversed later.
- Dune is a shipped theme with a published identity. Users who selected it chose a light warm theme; after this they get a near-black one under the same name. That is a product change, and
Non-blocking
internal/tui/theme_select_test.go:422-483is the part of this PR I would most want kept regardless of how the theme question is settled. It promotes checks that previously guarded only Neon — band distinctness after quantization,addBgWorddistinguishable fromaddBg,faintestlegible on both bands,addInk/delInkon their word spans — into invariants Dune must also satisfy. Those assertions are the durable value here, and they apply to whatever palette Dune ends up with.internal/tui/theme_select_test.go:278-280flipsTestNewThemePresetsWiredfrom asserting Dune is light to asserting it is dark. That is correct given the change, but it is worth naming explicitly: an existing test was rewritten to match new behaviour rather than a new one added, so the light-theme guarantee it used to hold is simply gone rather than relocated. If a light Dune is retained, this line reverts.- The
greenish/reddishhelpers were moved above theduneblock so both palettes can use them (theme_select_test.go:422-429). Sensible, no issue.
Not covered by this PR
- The quantization assertions now cover Dune and Neon. The other twelve registry entries have no equivalent guard, so a palette with the same latent defect would ship unnoticed. Worth a separate issue proposing the check be applied across the whole registry rather than per-theme — that is the class, and it is a better use of this work than either theme alone.
Not verified
- Rendering by eye on a real 256-colour terminal. The PR describes a manual
/theme dunecheck, which I did not repeat; my verification is the contrast suite only. - Any platform other than darwin/arm64.
To be clear about the order of things: the engineering is not what is holding this up. Open an issue for the Dune change, get it labelled, and the technical content here is close to ready.
Keep Dune as a warm sand-and-cream light theme with quantization-safe diff bands (#d0f0c0 / #fcd8d4) for 256-color terminals, and register dune-dark as a dark colorblind-friendly theme. Refs Gitlawb#841 Refs Gitlawb#713
jatmn
left a comment
jatmn
left a comment
There was a problem hiding this comment.
I found issues that need to be addressed before this is ready.
Findings
-
[P2] Preserve readable Dune Dark diffs on 16-color terminals
internal/tui/theme_palettes.go:483
Zero leaves normal terminal profile detection enabled, andTERM=xterm-style terminals use the 16-color ANSI profile rather than the 256-color approximation asserted here. With that profile,faintestbecomes bright cyan on the green add band (4.10:1),greenbecomes bright blue on it (1.67:1), andredbecomes bright red on the maroon delete band (2.74:1). Diff gutters and signs are therefore unreadable for a supported terminal profile despite the palette's accessibility claim. Choose ANSI-safe pairs and add assertions using the actual ANSI conversion path. -
[P3] Keep the public theme inventories in sync with the new option
internal/tui/theme_palettes.go:531
Registeringdune-darkmakes it valid forZERO_THEME,--theme, and/theme, but the option lists inREADME.md:345andREADME_ZH.md:237still stop atdune; the Unreleased announcement inCHANGELOG.md:238likewise says there are twelve color themes and lists the old set. The theme guide does document the new option, so this is not a release blocker, but these public inventories and release notes will be inconsistent. Adddune-darkto each list and update the count. -
[P2] Correct the PR's advertised theme contract
PR title and description
The current head preservesduneas the light sand palette and registers a separate darkdune-darkoption, but the title/body still say Dune itself was reassigned to dark and direct users to/theme dunefor the near-black palette. That leaves reviewers and users with the opposite of the shipped behavior. Retitle and rewrite the summary, change list, manual verification note, and issue reference to describe the light-Dune fix plus the newdune-darkpreset.
Pick ANSI-safe add/delete pairs, assert the real 16-color conversion path, and list dune-dark in public theme inventories and changelog.
euxaristia
changed the title
|
Addressed @jatmn findings in
Please re-review when you can. |
|
All three findings from the latest CHANGES_REQUESTED are on tip ( Ready for re-review. |
jatmn
left a comment
jatmn
left a comment
There was a problem hiding this comment.
I found issues that need to be addressed before this is ready.
Findings
- [P3] Align Dune Dark’s ANSI-16 gutter with the claimed AA audit
internal/tui/theme_select_test.go:576
buildThemerenders added-line numbers asfaintestonaddBg; under the real ANSI conversion these become bright cyan on green, only about 4.10:1. The new test knowingly permits 4.0 instead of the 4.5 AA threshold, even though the changelog says Dune Dark is ANSI-16 contrast-audited and the palette comment acknowledges that this pair is short of AA. Either choose an ANSI-safe pair and retain a 4.5 assertion, or narrow the accessibility claim.
Raise the Dune Dark gray ramp so faintest maps to a light ANSI/xterm gray that clears WCAG AA on the green add band, and require 4.5:1 in the 16-color audit instead of a 4.0 floor.
|
Addressed the new P3: ANSI-16 add gutter AA. |
jatmn
left a comment
jatmn
left a comment
There was a problem hiding this comment.
I found issues that need to be addressed before this is ready.
Findings
-
[P1] Restore Go formatting before this can be merged
internal/tui/theme_palettes.go:482
The current required Ubuntu Smoke job reportsgofmt needed on: internal/tui/theme_palettes.goduringCheck formatting; because that step runs first, vet, tests, build, and smoke are all skipped. This is a PR-owned file, so the change has not passed the repository's required validation gate. Format the complete changed Go file with the repository-declared Go toolchain, commit the resulting mechanical changes, and rerun the full CI job rather than treatinggit diff --checkas a substitute: whitespace checking does not enforce Go's canonical formatting. -
[P2] Keep the selected-row band distinct after ANSI-16 conversion
internal/tui/theme_palettes.go:507
On the supportedTERM=xtermprofile, the pinnedcolorprofile.ANSI.Convertpath maps bothpanel(#0e0e10) andselBg(#262626) to ANSI black.onSelpaints the selected picker row and permission choice with that background, so the intended full-row highlight disappears and focus is conveyed only by the small marker. The new ANSI-16 test verifies foreground-on-selection contrast but omits the background-separation invariant that the 256-color test already enforces. Select aselBgthat converts to an ANSI slot distinct from the panel while preserving foreground contrast, then add a regression assertion against the actual ANSI conversion path (not a hand-rolled approximation) that verifies the selected background differs from the panel by the established visibility threshold.
Format theme_palettes.go for the required CI gate. Map selection to a deep indigo (navy under 16-color) and warm the accent toward sand-gold so the full-row highlight and foreground tokens clear AA on TERM=xterm.
|
Addressed the latest review:
|
jatmn
left a comment
jatmn
left a comment
There was a problem hiding this comment.
I found issues that need to be addressed before this is ready.
Findings
-
[P2] Complete the Dune Dark status-border audit across every supported color profile
internal/tui/theme_palettes.go:516
Dune Dark setscardRunto#3399ff. Through the same production conversion path used by the new test—colorprofile.ANSI.Convert(lipgloss.Color(...))—that becomes ANSI bright blue (#0000ff), whilepanel(#0e0e10) becomes ANSI black (#000000). The rendered pair is therefore only 2.44:1. This is below the repository's established 3:1 requirement for non-text card borders (the NeoncardErrassertions inTestExtendedThemeANSI256Contrastalready document and enforce that threshold).This is a status-token-family gap rather than an isolated literal.
cardRunis used for in-flight tool-call borders (internal/tui/rendering.go:1429) and running-specialist left rules (internal/tui/specialist_card.go:362). Its sibling tokens are also production state indicators:cardErrborders failed tool cards, error note boxes, and failed specialist cards (internal/tui/rendering.go:994,internal/tui/rendering.go:1446, andinternal/tui/specialist_card.go:364), whilecardPermbecomespermBorderand frames both filled and unfilled permission surfaces (internal/tui/rendering.go:1152andinternal/tui/rendering.go:1192). The PR claims truecolor, xterm-256, and real ANSI-16 auditing, but the current tests exercise none of these Dune Dark border/surface pairings; they only contain a one-off NeoncardErrcheck in truecolor and xterm-256. That omission is why the current suite stays green.Please treat the following as the acceptance contract for one complete fix; changing only the
cardRunhex or adding only one ANSI-16 assertion would leave the same blind spot in place:- Choose a Dune Dark
cardRunvalue whose converted output remains at least 3.0:1 against the converted panel in truecolor, xterm-256, and ANSI-16. One known-safe direction is#cceeff, already used by this palette'sbluetoken and documented here as mapping to ANSI bright cyan; a different cool running color is fine if the real conversions prove it passes. - Audit the complete semantic status-border family—
cardRun,cardErr, andcardPerm—rather than assuming the untouched siblings are safe. Assert all three againstpanel; becausecardPermalso borders the filled permission card, assert it againstpermBgas well. - Exercise every advertised profile using the repository's existing helpers: raw hex pairs in
TestExtendedThemeContrastInvariants,xterm256Hexpairs inTestExtendedThemeANSI256Contrast, and the actualansi16Hex/colorprofile.ANSI.Convertpath inTestDuneDarkANSI16Contrast. Every status-border pairing above must use the 3.0 non-text threshold; do not lower the threshold to make a palette value pass. - Preserve the intended state identities after conversion: running, error, and permission borders should not collapse to the same converted ANSI color. The current cool/red/yellow roles should remain distinguishable in both xterm-256 and ANSI-16 even when their exact source hex values change.
- Keep the change scoped to Dune Dark's semantic status borders and their regression coverage. This finding does not require retuning decorative rules, prompt fills, unrelated themes, or weakening the PR's accessibility claims.
A focused verification command is
go test ./internal/tui/ -run 'TestExtendedThemeContrastInvariants|TestExtendedThemeANSI256Contrast|TestDuneDarkANSI16Contrast' -count=1, followed bygofmt/make fmt-checkand the existing repository CI gates. The review should be considered addressed only when the full matrix passes, not merely when the original 2.44:1cardRunpair changes. - Choose a Dune Dark
Swap cardRun to #cceeff (was 2.44:1 on panel under ANSI-16 conversion, below the 3:1 WCAG 1.4.11 non-text threshold) and cardPerm to #fff200 (was collapsing to the same ANSI red as cardErr, losing the permission-state identity under 16-color). Add regression coverage for cardRun/cardErr/cardPerm against panel (and cardPerm against permBg) in truecolor, xterm-256, and real ANSI-16 conversion, plus collapse checks so running/error/permission stay three distinct states after quantization.
|
Pushed a fix for jatmn's latest finding: cardRun swapped to #cceeff (was 2.44:1 against panel under ANSI-16 conversion, below the 3:1 WCAG 1.4.11 non-text threshold) and cardPerm to #fff200 (was collapsing to the same ANSI red as cardErr under 16-color). Added coverage for cardRun/cardErr/cardPerm against panel and permBg across truecolor, xterm-256, and real ANSI-16 conversion, plus collapse checks. Verified with Note: gnanam1990's earlier process/scope finding (no approved issue for changing Dune's identity from light to dark, and the daemon test fix riding along in an earlier revision) is not addressed by this push — that's a product decision for a maintainer, not something I'm resolving here. |
4 participants
Summary
Adds
dune-darkas a separate near-black, colorblind-friendly theme inspired by Claude Code's daltonized dark palette, while keeping lightduneas the warm sand-and-cream theme. Users who want the dark canvas use/theme dune-dark(orZERO_THEME=dune-dark/--theme dune-dark);/theme dunestays light.Diff and selection colors are audited for WCAG AA in truecolor, after xterm-256 downsampling, and (for Dune Dark) after the real 16-color ANSI conversion path used on
TERM=xterm.Changes
internal/tui/theme_palettes.godune(sand/cream) and registersdune-darkas its own dark preset.colorprofile.ANSIconversion.internal/tui/theme_select_test.goduneanddune-dark.TestDuneDarkANSI16Contrastasserts diff and selected-row pairs viacolorprofile.ANSI.Convert.docs/THEMES.mdREADME.md,README_ZH.md,CHANGELOG.mddune-dark(thirteen color themes alongsidedark/light).Test plan
go test ./internal/tui/ -run 'Theme|Palette|Dune|Contrast|ANSI|Diff|Hierarchy|Wired' -count=1git diff HEAD --check/theme duneis warm light sand;/theme dune-darkis near-black with orange accent and cool/warm diffsTERM=xtermsmoke for readable add/del signs on Dune DarkRefs #841
Summary by CodeRabbit
New Features
Documentation