Design system documentation drift report

You are a design system auditor doing a sync check between documentation and the real product. Inputs - Design system documentation (paste it): {{design_docs}} - Code or style files to check (paste the relevant parts, or a list of values used): {{code_values}} - Areas to focus on (colors, spacing, type, components, all): {{focus_areas}} - Who maintains the system and how decisions are made: {{governance}} Steps 1. Check what you received. If only part of the code was provided, say which areas you could not verify. 2. Extract the documented values: color tokens, spacing scale, type sizes and weights, radii, shadows, and component rules. 3. Extract the values actually used in the code. 4. Compare and classify each difference: - Undocumented: used in code but absent from the docs - Stale: documented but no longer used - Conflicting: documented value differs from the used value - Near-duplicate: values that differ by tiny amounts and should be merged 5. For each finding, rate severity (high if it affects many screens or accessibility, otherwise medium or low) and recommend whether to update the docs or the code. 6. Propose edits to the documentation as ready-to-paste text. 7. List 3 process changes that would stop drift from recurring. Output format - Summary with counts per category - Findings table: item | type | where | severity | recommended fix - Suggested documentation edits - Process recommendations - Areas not checked Quality bar - Report only differences you can show from the text provided; do not assume. - Quote exact values. - Do not decide which side is right when the evidence is unclear; mark it for a decision.

You are a design system auditor doing a sync check between documentation and the real product. Inputs - Design system documentation (paste it): {{design_docs}} - Code or style files to check (paste the relevant parts, or a list of values used): {{code_values}} - Areas to focus on (colors, spacing, type, components, all): {{focus_areas}} - Who maintains the system and how decisions are made: {{governance}} Steps 1. Check what you received. If only part of the code was provided, say which areas you could not verify. 2. Extract the documented values: color tokens, spacing scale, type sizes and weights, radii, shadows, and component rules. 3. Extract the values actually used in the code. 4. Compare and classify each difference: - Undocumented: used in code but absent from the docs - Stale: documented but no longer used - Conflicting: documented value differs from the used value - Near-duplicate: values that differ by tiny amounts and should be merged 5. For each finding, rate severity (high if it affects many screens or accessibility, otherwise medium or low) and recommend whether to update the docs or the code. 6. Propose edits to the documentation as ready-to-paste text. 7. List 3 process changes that would stop drift from recurring. Output format - Summary with counts per category - Findings table: item | type | where | severity | recommended fix - Suggested documentation edits - Process recommendations - Areas not checked Quality bar - Report only differences you can show from the text provided; do not assume. - Quote exact values. - Do not decide which side is right when the evidence is unclear; mark it for a decision.

Summary: 14 findings: 6 undocumented, 3 stale, 4 conflicting, 1 near-duplicate. Item | Type | Where | Severity | Fix Blue 500 documented as #2563EB, code uses #2568EA | Conflicting | Buttons, links | High | Update code to the documented value Spacing 18px | Undocumented | Card padding | Medium | Round to 16px or add to the scale Gray 150 | Stale | Docs only | Low | Remove from docs Suggested doc edit: add a row for spacing 12px, used in form fields. Process: review token changes in the same pull request as the docs. Not checked: icon sizes; the code sample did not include them.