Audit Token Coverage Across the Codebase

Use this play to find hardcoded values in the codebase that should be consuming design tokens. Run it periodically — especially after rapid development phases — to catch drift before it compounds. **Step 1 — Read the living brief:** Read `LIVING_BRIEF.md`. Note the token naming convention and the list of implemented components. This tells you what the correct token names are and what components should be covered. **Step 2 — Read the references:** Read the following from the Sistema knowledge base: - Token architecture synthesis: `{{sistema_url}}/raw/principles/tokens/architecture` Pay attention to the "no raw values in components" rule and the coverage requirements. **Step 3 — Scan for drift:** Search the codebase for hardcoded values that should be tokens. Look for: - Hex color values (`#`) in component files - `rgb(`, `rgba(`, `hsl(` in component styles - Raw pixel values for spacing that should use spacing tokens - Raw pixel values for border-radius that should use shape tokens - Font size or weight values that should use type tokens - Box-shadow values that should use elevation tokens Exclude: - Token definition files (the values legitimately appear there) - Third-party library styles - Test fixtures **Step 4 — Produce the audit report:** For each violation found: - File path and line number - The hardcoded value - The correct token it should use - Severity: **blocking** (color or interactive state — affects consistency and accessibility), **recommended** (spacing or shape — affects consistency), **minor** (one-off value with minimal systemic impact) Output: 1. Summary: total violations by severity 2. Prioritized list of violations (blocking first) 3. Recommended fix order (group by component or file for efficiency) ---