skip to content
cooper corbett

Design system

An index for the site design source of truth. Start with foundations, inspect component primitives, then compose them into route layouts.

design system sections

  • Foundations

    theme

    Foundations for colour, type, spacing, radii, shadows, semantic surfaces, and texture restrictions.

  • Library

    components

    Reusable UI primitives from apps/web, shown in their composed states with the surface component beside controls and forms.

  • Layouts

    layouts

    Canonical page shells and skeletons that show how routes compose primitives, composites, and layout leaves.

model

composition model

The route family follows the primitive, composite, and layout hierarchy used by product pages.

  • /design

    Landing page and map of the system.

  • /design/theme

    Foundations, semantic roles, component recipes, and texture restrictions.

  • /design/components

    Component primitives and their documented surface recipes.

  • /design/layouts

    Page skeletons composed from primitives and composites.

governance

source of truth and contribution

Local docs, route catalogues, package code, and MCP references each have a specific job. Keep durable design changes visible here.

visual rulesDESIGN.md

Principles, token semantics, page archetypes, and texture restrictions.

frontend compositionARCHITECTURE.md

Primitive -> composite -> layout -> route rules, component admission, non-display reasons, and leaf ownership.

token runtimeapps/web/src/styles/base.css

Primitive tokens, semantic aliases, Tailwind theme references, and CSS-backed overlay contracts.

component catalogue/design/components

Visible status, owner, source path, package export, states, accessibility, usage, examples, and non-display reasons.

layout catalogue/design/layouts

Route/page skeletons showing how primitives and composites become layouts.

external referencedocs/README.md

Current document owners and the accepted Site replacement.

contribution

Start from the local inventory and route catalogue, then update the current owner through docs/README.md.

component admission

A reusable component needs package ownership, explicit export, /design/components metadata, meaningful states, accessibility notes, usage guidance, and browser proof.

feedback

Record visual or composition defects in the active spec or plan with screenshots, route paths, affected primitive/composite level, and the shared owner to fix.

deprecation

Mark deprecated or app-only items with status, replacement guidance, and a migration note before removal. Do not silently remove exported package surfaces.

non-display

If a component cannot render directly in the catalogue, keep a visible non-display reason with owner, source path, states, accessibility, and usage guidance.