Make dark-mode token coverage deliberate. Most "dark looks off" reports trace to the phantom tokens fixed in WORK-340 (a phantom can't have a dark value); this item closes the genuine remaining gaps and records the intentional shared-token decisions.
Tracking started Jun 5 — check back for trends.
--rf-color-line-highlight, --rf-color-line-highlight-rail, --rf-color-line-number. Verify line highlighting + numbering read correctly on a dark code block.base.css either has a dark override in dark.css or is explicitly annotated as intentionally shared.--rf-color-primary-50…950 ramp is no longer a parity concern (removed by WORK-340); confirm nothing dark-mode-relevant still depends on it.Diff the base vs dark token sets (comm -23). For each unmatched token, add a dark value or annotate it shared. The code-block tokens are the only confirmed visual gap; the rest is a deliberate-decision pass once WORK-340's phantoms are resolved.
packages/lumina/tokens/base.css, dark.csspackages/lumina/styles/runes/codegroup.css + code/syntax stylingCompleted: 2026-06-05
Branch: claude/v0.19-lumina-polish
Investigation showed the dark-parity gap was smaller than feared — and mostly already fixed by WORK-340. After the phantom-token + ramp cleanup, only four base tokens lack a dark.css override, and all four are derived from mode-aware tokens:
line-highlight = color-mix(text 6%, transparent)line-highlight-rail = var(--rf-color-primary, …)line-number = var(--rf-color-muted)primary-bg = color-mix(primary 10%, transparent)Because text / primary / muted all flip in dark mode, these track dark automatically; pinning fixed dark values would break the derivation. So they are intentionally shared — annotated as such in base.css (WORK-341 note). Every absolute token already has a dark override (verified).