A bypass isn't necessarily wrong: the colour on screen may be exactly the approved one. The problem is that it no longer follows the system. When the token changes, the bypass stays behind.
Typical bypasses
- A hex colour, such as
#2563eb, wherebg.accentexists. - A pixel value, such as
padding: 12px, where a spacing token exists. - A button rebuilt from a
divand a few styles instead of the system'sButton. - A primitive token used where a semantic one belongs, so a dark theme misses it.
How to find them
Search code for literals that should be tokens: hex, rgb(), hsl() and pixel values in styles. A lint rule catches new ones at review time. Atlassian ships ESLint rules such as ensure-design-token-usage that flag values which should be tokens (Atlassian Design System).
Exclude generated code before counting. When we first measured a demo repository with FISYCO, the product we build, the icons its own sync had exported counted as about 590 hard-coded colours. The code was fine; the count wasn't.
Why count them
Bypasses show whether the system is actually used. Track them as a share of tracked usages, not as a raw count, because a growing codebase raises the raw number anyway. A falling share means teams reach for tokens and components first; a rising one usually means the system is missing something people need, or is too hard to use.