Audit the code, not the documentation. Reconstruct what is declared (tokens in every theme, components), read everything that is used, and compare the two. A useful audit separates deterministic findings (a raw value identical to a token) from inferences (a value close to a token), cites the files for each, and says plainly what it could not determine.
The areas to cover
- Colour: tokens per theme and mode, exact drift, near-matches, dead and conflicting declarations.
- Typography: the type scale in use, raw sizes on and off the scale.
- Foundations: spacing, sizing, radius, shadows, z-index, breakpoints, borders, opacity, motion.
- Components: inventory, duplicates, variant sprawl, overrides, unused components.
- Accessibility: contrast of real text and background pairs in each theme, focus styles, target sizes, reduced motion.
What makes an audit trustworthy
Determinism (the same code gives the same findings), evidence (every finding names its files), and honesty about uncertainty (an unresolved value is reported as unresolved, never guessed). Without these, an audit becomes a list of opinions that teams argue about instead of fixing.
Running one with Saer
cd your-project
saer scan
# report: .saer/report.html
# data: .saer/system.jsonSaer reads only; it writes its report into .saer/ and changes nothing else. See getting started.
What Saer does about this
- Colour: in the beta.
- Typography, foundations, components, accessibility checks and website audits: in the beta.
- The unified audit report across every area, with traceable scores: planned.
Every capability and its state: what Saer checks.
See it on your own codebase.
Request early access