Extract a checked-in WCAG contrast-check utility (scripts/check-contrast.mjs) so token-palette changes are auditable and repeatable
task-checked-in-contrast-utility
Extract a checked-in WCAG contrast-check utility
The Recalibrate the Dossier brand identity — demote color, promote type + restraint + craft — then build the showcase landing session validated the clay ramp, on-accent colors, and hue-spread by writing WCAG 2.1 relative-luminance + contrast-ratio arithmetic to /tmp four-to-five separate times — re-deriving the same function rather than reusing one. Dumb-fast trace capture + off-hot-path distill/prune's Review explicitly surfaced this as a forward-looking improvement ("extract a shared scripts/check-contrast.mjs — the WCAG helper was rewritten throwaway ~4×"), and no canonical utility exists yet (confirmed: no scripts/check-contrast.mjs).
Why it matters
Establish the design system and the UX-engineering function makes the typed token tree the single source of truth and styles/dossier.css a drift-tested generated cache. A contrast checker is the missing peer of that discipline: the AA floor Recalibrate the Dossier brand identity — demote color, promote type + restraint + craft — then build the showcase landing adopted should be an auditable, repeatable gate, not arithmetic re-typed into /tmp each palette change. Owned by Principal UX Engineer (the design-language function, DEC-0010).
Notes
Board globbed before filing — no existing task covers a contrast/WCAG utility (the design-adjacent task-prune-dead-per-page-chrome-css is CSS dead-code, unrelated). Provenance: surfaced by the log-auditor via trace distillation; confidence: inferred (agent-judged real, not human-curated).