Native colour alignment

Where the webview's chrome gently follows macOS — colour and shape, default palette only. Decided: one shared palette (no web/desktop fork); a single accent token #007AFF/#0A84FF — Apple's system blue, copied verbatim (the seam has to be invisible, and at button scale the eye reads even a hue-matched near-miss like #0068D6 as "not the OS blue"); one blue for buttons, links, focus, selection & tab underline; link text lands at 4.02:1 on white — accepted, a webbier link blue can split off later at low cost. Sidebar selection = #EFEFEF/#2B2B2B grey capsule with accent icon + label; nav lozenge & primary-button radii → 6px. Finding 1 keeps the full blue lab as reference; the rest render the same markup twice, diverging only on scoped tokens — alignment is a token change, not a rewrite. Full write-up in design-native-colour-alignment.md.

Appearance
Window
Tier 1 · align now · shared

1 · Accent blue — the candidates, light + dark in context

One token — --bn-colour-accent — drives links, primary buttons, the active tab underline, focus rings and selection borders. Each column is a candidate, rendered as real chrome in forced light and dark context (independent of the Appearance toggle above) with its live WCAG contrast ratio. The link pill tests the strict 4.5:1 body-text bar (blue-as-text on the background); the UI pill tests the 3:1 bar that actually governs buttons, rings, borders and underlines. Everything here clears UI 3:1 — the only value that misses link 4.5:1 is Apple's raw system blue on white, and only in light mode.

Decided — #007AFF / #0A84FF: copy Apple's system blue verbatim, single token. The north star is an invisible seam — a webview button beside an AppKit sheet button must read as the same control — and at this pixel scale the eye clocks even a hue-matched near-miss (#0068D6) as "not the OS blue". Apple is already telling us the right blue; we take it. The wrinkle — a user who sets an exotic system accent — is on them; a default modern-OS Mac shouldn't be able to tell CSS from AppKit. Link text on white lands at 4.02:1 (Apple's own tradeoff — colour isn't the sole affordance); if it bites, splitting a webbier link blue (e.g. #0071E3) is cheap given the tokens. Dynamic system-accent (match whatever accent the user actually picked) is the fuller finish, deferred.

Tier 1 · align now · shared

2 · Sidebar navigation selection

Active nav rows (.toc-link.active, .session-entry.active, .signal-entry.active) sit on a blue-tinted background today. But both Finder and the real bn.app AppKit project sidebar render the selected row as a pale grey capsule with the icon and label in accent blue — the pinned unemphasized source-list look. So the change isn't "go grey", it's: move the background from blue-wash to the native pale grey, and keep the text + icon in accent (the same system blue as the Finding 1 chrome accent). The native project sidebar and the webview's own nav are on screen in the same window, side by side — so they must read as one selection language. Boundary: this is nav selection; content selection (Finding 5) is a different treatment.

Current webview · blue text on blue wash
Onboarding friction
Trust & privacy
Pricing confusion
Feature requests
Native + webview aligned · accent text on pale grey

Native project sidebar (Finder / bn.app)

Ikea tom 1

Webview nav — matches

Onboarding friction
Trust & privacy
Pricing confusion

Capsule = NSColor.unemphasizedSelectedContentBackgroundColor. No canonical Apple hex (dynamic, and a vibrant material — so sampled values are composites); sampled #EFEFEF light / #2B2B2B dark (bn.app's own sidebar). Accent on it clears the 3:1 UI bar both modes (light #007AFF = 3.5:1; dark #0A84FF = 3.9:1). Truly canonical route = bridge the live NSColor from Swift. Radius here is the Finding-3 6px.

Tier 1 · align now · shared

3 · Selection-lozenge radius

Nav entries round at --bn-radius-sm (3px); the native pill vocabulary starts at 6pt (lens rail, icon picker). Shared change: repoint the consuming selectors from radius-sm to radius-md — achromatic and subtle, fine on web too. Don't touch --bn-radius-sm itself (badges and inputs use it correctly at 3px).

Current · 3px corners
Trust & privacy
macOS-aligned · 6px corners
Trust & privacy

Colour held at the current blue tint here to isolate the radius change.

Tier 1 · align now · shared

4 · Primary-button radius

Modal buttons (.bn-btn) round at 3px while the toolbar buttons are already 6px — an internal inconsistency. macOS push buttons sit at ≈5–6pt. Shared: move modal buttons radius-sm → radius-md, which fixes native fidelity and the internal disagreement in one edit.

Current · 3px buttons
macOS-aligned · 6px buttons

Accent held at current blue here to isolate the radius change.

Tier 3 · deliberately unchanged

5 · Content selection stays blue — but inactive-window dimming now works

macOS content selection is blue, so selected quote cards are already native-correct — don't grey them. What was broken: the inactive-window dim referenced --bn-selection-bg-inactive / --bn-selection-border-inactive, which were never defined, so var() was invalid and the dim never rendered. Those two tokens are now defined in both palettes. Toggle Window → Inactive above to see the selected card recede to grey.

Selected · window active
"I almost gave up at the sign-in step — it wasn't clear my work account would even work." p3 · Onboarding friction
Content stays blue; inactive dim fixed
"I almost gave up at the sign-in step — it wasn't clear my work account would even work." p3 · Onboarding friction

Blue when active (correct); greys via the newly-defined tokens when the window blurs.