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 @packages/ui, 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.
/designLanding page and map of the system.
/design/themeFoundations, semantic roles, component recipes, and texture restrictions.
/design/componentsComponent primitives and their documented surface recipes.
/design/layoutsPage 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.
docs/DESIGN.mdPrinciples, token semantics, page archetypes, and texture restrictions.
docs/FRONTEND.mdPrimitive -> composite -> layout -> route rules, component admission, non-display reasons, and leaf ownership.
packages/ui/src/styles/base.cssPrimitive tokens, semantic aliases, Tailwind theme references, and CSS-backed overlay contracts.
/design/componentsVisible status, owner, source path, package export, states, accessibility, usage, examples, and non-display reasons.
/design/layoutsRoute/page skeletons showing how primitives and composites become layouts.
docs/references/design-systems-mcp.mdSouthleft MCP query policy; useful precedent, not local authority.
contribution
Start from the local inventory and route catalogue. Query the Southleft MCP for durable taxonomy or governance changes, then translate only relevant guidance into local docs.
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.