Component token audit
This audit moves repeated visual decisions into tokens before component work makes them harder to change consistently. It is a migration record, not permission to tokenize every local measurement.
Completed migrations#
| Repeated decision | Semantic token or role | Consumers |
|---|---|---|
| Surface, text, and divider colours | color.paper, color.ink, color.line, neutral scale | Header, navigation, pagination, code and keyboard controls |
| Status treatment | status.note, status.success, status.important, status.warning, status.danger, status.archived | Markdown callouts and version badges |
| Corner treatment | radius.*, diagram.radius | Code, callouts, keyboard controls, image and diagram surfaces |
| Elevation | shadow.panel, shadow.overlay, diagram.shadow | Previews, submenus, pagination, code, keyboard controls, mindmap cards |
| Motion | duration.fast, duration.standard, easing.standard | Mindmap preview transitions and future interactive components |
| Component geometry | component.theme-toggle.* | Shared theme toggle in both site headers |
Audit rule#
Move a value into a token when it names a reusable role, appears in more than one component, or must stay aligned across sites and exported diagrams. Keep local geometry in CSS when it only explains one layout relationship.
The token checker rejects raw colour literals and ungoverned Tailwind palette utilities in assets/css/site.css. Template migrations should prefer an existing semantic utility or a named component class; they must not introduce a new literal only to avoid changing the token source.