Guard user colour overrides against unreadable renders master
theme.colors reached the page as inline custom properties on .site, and inline declarations outrank every stylesheet rule — so the theme's own prefers-color-scheme block could never fire for an overridden token. A site declaring only a background kept that background in dark mode while --ink still flipped to #e9e3d6: near-white on near-white, ~1.06:1, around a near-black --paper-sunk panel. The record carries one colors object and no scheme variants, so take it at its word: any override declares a single palette and pins the site to one scheme, read from the background's luminance (or, with only a foreground given, its inverse). render/palette.ts builds the whole eight-token palette from whatever subset was declared, mixing --muted, --rule and --paper-sunk from the declared paper and ink rather than leaving them at the other scheme's values, and holds every text-bearing pairing to WCAG AA. Colours that miss the floor are walked toward black or white until they clear, keeping their hue — most plausible brand colours fail AA on the near-white paper, so dropping them would have made "I set my accent and nothing happened" the common case. color-scheme is pinned alongside the palette so controls and scrollbars stop following the OS against a pinned page. Sites with no override emit no tokens and keep both schemes unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>