Desaturate Status Colors on Dark
SHOULD: Give each semantic color (success, error, warning) a SEPARATE dark-theme value: hold the hue angle, raise lightness a little, and pull chroma DOWN. A swatch picked to fight a white surface has nothing to fight on near-black — it vibrates and the glyph edges shimmer. It is not a contrast failure (the ratio may pass), it is a saturation failure. On dark, also lean on borders rather than shadows, which barely read. This moves the OPPOSITE way from `design-impeccable-tinted-neutrals` (which pushes a little brand chroma INTO the neutrals); a palette should do both.
Keep the hue and drop the chroma when a semantic color moves to a dark surface, because the swatch tuned for white vibrates on near-black
Bad
Good
Why it matters
A success green and an error red are picked against white, where a high-chroma swatch has to fight a bright surface to be seen. Move the identical token to a near-black panel and the fight is over: the same chroma now sits against almost no lightness, the edges of the glyphs shimmer, and the badge buzzes rather than reads. It is not a contrast failure — the ratio may pass — it is a saturation failure, and the fix is the third sentence of the quote: same hue, less chroma.
In OKLCH that is one number: hold the hue angle, raise lightness a little so the badge stays legible, and pull chroma down until the swatch sits still. This is NOT design-impeccable-tinted-neutrals, which pushes the NEUTRALS a tiny amount of chroma TOWARD the brand hue so surfaces feel like one system. This rule moves in the opposite direction on the opposite tokens: it takes chroma AWAY from an already-saturated SEMANTIC color so it survives a dark surface.
A palette can and should do both. Express the pair as two theme values per semantic role rather than one, and let the dark token be a deliberate value, not the light one reused.