fix(onboarding): use the success and warning tokens for status badges - #535
Conversation
The onboarding status rows hardcode `#38d591` and `#ff9800`. Those are not arbitrary greens and oranges — they are Midnight's own `--color-success` and `--color-warning`. Every other skin redefines those tokens, and the two light skins deliberately darken them; styles.css even annotates the warning with `/* darkened -> 4.98:1 */`. Painting the literal bypasses exactly the re-tuning that annotation is about, so on Atelier and Lagoon the badges keep Midnight's bright colours over a near-white card: skin ok badge warn badge mic check midnight 6.35:1 5.50:1 8.00:1 atelier 1.69:1 1.94:1 1.89:1 foundry 7.35:1 6.32:1 9.15:1 lagoon 1.69:1 1.94:1 1.89:1 1.69:1 is under the 3:1 floor for non-text graphics, and the tick is close to invisible against its own tint. Use `bg-success/15 text-success` and `bg-warning/15 text-warning`, the pattern the same round status pill already uses in ConnectorCard and SecretRequestCard. `/15` is the nearest step to the literal's own `0x22` alpha, so the dark skins keep the look they have: after the change the four skins measure 4.99, 4.86, 5.12 and 5.07 at worst, and all twelve pairs clear AA. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
@Maksim-Burtsev is attempting to deploy a commit to the SupaMaus Team on Vercel. A member of the Team first needs to authorize it. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 4 included reviews per hour; 3 remain after this review. 📝 WalkthroughWalkthroughThe onboarding flow replaces hardcoded status colors with semantic success and warning design tokens. No logic or control flow changes. ChangesOnboarding status colors
Estimated code review effort: 1 (Trivial) | ~3 minutes Merge Risk: ⚪ Minimal · up to This localized UI change replaces hardcoded onboarding badge colors with the existing success and warning tokens so skins render the intended accessible colors. No actionable merge-blocking risk remains after normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 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 |
What changed
The onboarding status badges in
src/components/Onboarding.tsxmove fromhardcoded hex to the
successandwarningtokens:bg-success/15 text-successand
bg-warning/15 text-warningfor the round badge inStatusRow, andtext-successfor the microphone-granted tick.Why
#38d591and#ff9800are not arbitrary colours — they are Midnight's own--color-successand--color-warning, copied into the component. Every skinredefines those tokens, and the two light skins deliberately darken them;
styles.cssannotates the Atelier warning with/* darkened → 4.98:1 */.Painting the literal bypasses exactly the re-tuning that annotation exists for,
so on Atelier and Lagoon the badges keep Midnight's bright green and orange on a
near-white card:
1.69:1 is below the 3:1 floor for non-text graphics, not just below AA — the tick
is close to invisible against its own tint, which is visible in the screenshots.
bg-success/15 text-successis the pattern this same round status pill alreadyuses at
ConnectorCard.tsx:103andSecretRequestCard.tsx:114(
LocalComputerSectionuses the/20step for its step badge)./15is thenearest Tailwind step to the literal's own
0x22alpha, so the dark skins keepthe appearance they have today — midnight and foundry are unchanged in the
screenshots below.
After the change every skin clears AA:
Scope: after this change
Onboarding.tsxhas no colour literals left, and thesethree were the last occurrences of
#38d591/#ff9800/#00c972anywhere insrc/.Worth noting for context:
electron/skin-overlay.test.mjsalready guards thenative chrome table against exactly this class of drift, but it covers the
Electron colour table rather than the components, which is why these three
survived.
How it was verified
macOS 26.6, Node 26,
pnpm dev+pnpm dev:server. The numbers are read out ofthe running app, not computed by hand: a harness mounts the badges inside a
[data-skin]wrapper (the skin blocks are written so any element can open a skincontext for its subtree), extracts the class strings from
Onboarding.tsxso itcannot drift from what ships, then composites
getComputedStylecolours over thefirst opaque ancestor and measures. Same harness before and after; only the
component changed between runs.
No test is added: every test under
src/is a pure-logic test on exportedfunctions, with no DOM or layout harness in the repo, and CONTRIBUTING asks UI
changes for screenshots instead.
Screenshots (UI changes)
The three badges in all four skins — the
okbadge, thewarnbadge, and thebare mic tick.
Before — atelier and lagoon wash out; the ticks barely separate from their
own tint:
After — the light skins pick up their darkened tokens and read clearly;
midnight and foundry are unchanged:
Screenshots live on a separate branch of my fork so they stay out of this PR's diff.
Checklist
pnpm typecheckandpnpm testpass locallydist-server/edits (it's build output)shell: true/ cmd.exe string-building — n/aSummary by CodeRabbit