Design Tokens as Canonical Truth

Between Phases 37 and 40, four consecutive waves of work converted the visual layer from a patchwork of hardcoded values into a system governed by CSS custom properties. Navigation spacing, the SiteHeader component, line-height harmonization, and a final compliance sweep each targeted a different layer of the same problem: values that happened to be correct but carried no relationship to each other.

The distinction matters. A hardcoded padding: 0.75rem is a coincidence — it works in this context but knows nothing about the spacing scale. A token reference var(--space-1h) is a commitment — it participates in a defined system, and if that system evolves, every reference evolves with it.

Phase 37: Navigation Spacing Tokens

Commit fd05b84 introduced spacing tokens into the top navigation and created the SiteHeader component for secondary pages. Before this phase, each page assembled its own header from inline styles and Tailwind utilities. The spacing between logo, navigation links, and action buttons varied page to page — not because of design intent, but because each page was authored independently.

The SiteHeader component unified this. Navigation gaps reference var(--space-2) and var(--space-3). Logo padding uses var(--space-1). The component enforces consistency by construction: you cannot use it incorrectly because the spacing decisions are internal to the component, not exposed as props to misconfigure.

Phase 38: SiteHeader Across Pages

Phase 38 (e77c7ba) deployed the SiteHeader to all secondary pages — FAQ, refund policy, success, cancel, transparency, subscribe, log. Each page had its own header implementation with its own spacing assumptions. The migration was mechanical but revealing: seven files, seven slightly different header layouts, seven sets of spacing values that almost-but-not-quite matched.

Active link indication arrived in the same phase. The SiteHeader now highlights the current page in the navigation using usePathname(), applying a bottom border via var(--color-primary). This is not decoration — it is wayfinding. In a project where every page says variations of "this is nothing," knowing which nothing you are currently viewing is genuinely important.

Phase 39: Line-Height Harmonization

Commit 9e9547a addressed line-height inconsistencies across the navigation and responsive FAQ layout. The FAQ accordion items had been using bare Tailwind leading-snug and leading-normal values, which resolve to different absolute sizes depending on the font-size context. A new token --line-height-snug was added to globals.css, giving line-height a named identity within the design system.

Line-height is the invisible architecture of typography. Readers do not notice consistent line-height. They notice inconsistent line-height as a vague sense that something is wrong. For a project that relies on typographic clarity to convey philosophical content about nothing, "vaguely wrong" is not acceptable.

Phase 40: The Compliance Sweep

The final phase (513f2d3) was a systematic sweep across the component tree. Forty-plus bare Tailwind values — hardcoded spacing, colors, transitions, opacities — were converted to design token references. The sweep covered eight components: ConfirmDialog, CookieConsent, TransparencyDial, SystemStatusPanel, AnnotationMarker, InboxView, FailedView, and RejectedView.

A new --overlay token was added for semi-transparent backdrop colors, replacing three separate hardcoded rgba() values. Six aria-label attributes were added to content-ops action buttons that previously had no accessible name. The compliance sweep was not exciting work. It was custodial — finding every remaining hardcoded value and replacing it with its token equivalent.

After Phase 40, the component tree achieved approximately 99% design token compliance. The remaining 1% consists of intentional exceptions: Tailwind responsive breakpoints, which are framework-level concerns, and a handful of animation keyframe values that exist outside the token scale by design.

Why Tokens Matter for Nothing

A reasonable question: why does a project selling nothing need a rigorous design token system? The answer is the same one that justified TypeScript strict mode, comprehensive tests, and a full CI pipeline. The experiment requires credibility. If the visual layer looks inconsistent, the visitor attributes the inconsistency to incompetence rather than to the deliberate absurdity of the premise.

Design tokens are not about aesthetics. They are about maintainability and trust. When every spacing value participates in a named scale, the design system becomes auditable. A new contributor can verify compliance with a grep command. A design change propagates through a single variable update rather than a search-and-replace across fifty files. The tokens do not make the project beautiful — they make the project honest about its visual commitments, which is the same transparency principle that governs everything else in Project Nothing.