The Design Token That Never Became a Rule

Most design-system checks compare two known things: this component against that token, this component against that code implementation. But there's a quieter failure mode that those comparisons can't see at all — a value that was never captured as anything in the first place. A hex color typed directly into a fill. A spacing value nudged by four pixels and never turned into a token. It isn't a mismatch, because there's nothing on the other side to mismatch it against. It's just invisible.

We closed that gap this week, along with a related one in mode coverage — and in the process, changed how DesignGuard scores severity for both. The old assumption was that a value's severity tracked how often it showed up. That assumption was backwards.

The literal that was never promoted

DesignGuard's token mapping has always compared nodes that were already promoted to a Figma style, variable, or code token. That's a reasonable design — but it means a raw literal that never got promoted doesn't enter the comparison at all. It's not flagged as a mismatch. It's just absent, sitting quietly inside a component, waiting for someone to notice by accident.

DesignGuard now scans for exactly this: literal color, typography, spacing, and radius values that never resolved to an approved token or rule. Each one becomes its own finding, tracing back through the component graph to every screen it actually appears on.

Why frequency is the wrong way to prioritize it

The obvious instinct is to prioritize by how often a value repeats — forty occurrences feels more urgent than one. It's the opposite. A value repeated forty times is the cheap kind of problem: it's easy to find, easy to batch-fix, and someone eventually notices it just by working in that part of the file. A value that appears exactly once is the dangerous kind — it forms no pattern, collides with nothing, and survives every visual review specifically because nothing about it looks wrong.

So DesignGuard now scores severity by reach instead: how many distinct product-flow screens a literal's occurrence actually traces back to, walked through the component graph. A literal used once inside a component that's instanced across a dozen screens scores as high severity. The same literal hardcoded forty times inside one isolated, self-contained flow scores lower. Frequency is still shown on the finding — it's a genuinely useful signal for how much effort a fix will take — but it no longer decides how urgent the finding is.

The token that only breaks when someone asks for dark mode

The second gap was mode coverage. A token role can exist perfectly well in light mode with no dark-mode counterpart at all, and nothing about it looks broken — until someone actually asks for the other mode, at which point it's suddenly missing, and nobody can say when that happened.

The first version of this check inferred mode from the token's name — anything with "light" or "dark" in it. That works, but only for tokens that were already named consistently. A badly named role passes the check in silence, which is exactly the case it exists to catch.

Reading modes from the source of truth

So DesignGuard now reads mode coverage directly from Figma's own Variables API where it's available. A variable collection declares its modes as real, structural data — Light, Dark, whatever a team has set up — and each variable either has a value for a given mode or it doesn't. That's a binary check, not a visual one, so it fires as a hard finding rather than sitting in a confidence-scored review queue. Nothing rides on what anyone happened to type.

Where a workspace hasn't synced variable-collection data yet, the naming-based check still runs as a fallback — and every finding says plainly which method caught it, structural or naming-based, so nobody mistakes an approximation for a guarantee.

Both checks show up as regular findings in your dashboard now, same list, same workflow you already use to acknowledge, resolve, or dismiss anything else DesignGuard surfaces. Nothing new to learn — just two more blind spots closed.