design-system-reviewlisted

# Design System Review Review the system as a product and an operating model, not a screenshot library. A healthy system creates shared decisions, accessible defaults, predictable behavior, and a credible path from design to production. ## 1. Define the system boundary Establish: - products, platforms, brands, themes, locales, and teams served; - available evidence: token files, component code, Storybook, Figma libraries, documentation, usage analytics, product screenshots, issue logs; - source of truth for tokens, components, content, and release status; - expected consumers and valid extension points; - maturity stage: inventory, emerging library, adopted system, or multi-brand platform. Do not equate visual inconsistency with system failure until intent and ownership are known. ## 2. Build an evidence inventory Sample real product usage, not only pristine documentation. Create: `Pattern | Instances | Intended source | Observed variants | State gaps | Accessibility risk | Adoption signal | Owner` Trace representative components from semantic token to design asset to code to product. Record drift at the layer where it originates. ## 3. Review four layers ### Foundations and tokens Read [references/tokens-and-theming.md](references/tokens-and-theming.md). Inspect semantic naming, primitive separation, modes, themes, aliases, units, typography, motion, elevation, density, breakpoints, deprecation, and distribution. ### Components and patterns Read [references/com