Essential session storage is required to sign in. Optional analytics remain off unless you allow them.
Build a production-shaped design system in a monorepo. Include: (1) a tiered token pipeline (e.g. Style Dictionary) feeding components, with multi-theme support; (2) a set of accessible, documented components (Storybook); (3) a robust CI quality gate — unit tests, accessibility tests, AND VISUAL REGRESSION testing (Chromatic/Percy/Playwright snapshots) that catches unintended visual changes across components and themes; (4) semantic-versioned releases with Changesets and a deprecation/migration story (e.g. a codemod for one breaking change); (5) a documented GOVERNANCE/contribution model (centralized/federated/hybrid, with an RFC + review + a11y bar); and (6) a token bridge concept linking design (Figma variables) to code. Explain how you'd measure adoption.
Tiered token pipeline (Style Dictionary or equivalent) feeding components; multi-theme by swapping tokens; design-to-code token bridge described.
CI gate with unit + a11y + VISUAL REGRESSION tests that catch unintended visual diffs across components/themes before publish.
Semantic-versioned releases (Changesets); a deprecation/migration (codemod) example; a documented contribution/governance model.
Storybook docs; a concrete plan to measure adoption (usage analytics / % of UI on the system).
Use this README structure to make the work reviewable.
DevPath fetches a read-only, size-capped snapshot. Submitted code is never executed.
# A governed design system with visual-regression CI ## Goal Build a production-shaped design system in a monorepo. Include: (1) a tiered token pipeline (e.g. Style Dictionary) feeding components, with multi-theme support; (2) a set of accessible, documented components (Storybook); (3) a robust CI quality gate — unit tests, accessibility tests, AND VISUAL REGRESSION testing (Chromatic/Percy/Playwright snapshots) that catches unintended visual changes across components and themes; (4) semantic-versioned releases with Changesets and a deprecation/migration story (e.g. a codemod for one breaking change); (5) a documented GOVERNANCE/contribution model (centralized/federated/hybrid, with an RFC + review + a11y bar); and (6) a token bridge concept linking design (Figma variables) to code. Explain how you'd measure adoption. ## Acceptance criteria - [ ] Tokens & theming: Tiered token pipeline (Style Dictionary or equivalent) feeding components; multi-theme by swapping tokens; design-to-code token bridge described. - [ ] Visual-regression CI: CI gate with unit + a11y + VISUAL REGRESSION tests that catch unintended visual diffs across components/themes before publish. - [ ] Versioning & governance: Semantic-versioned releases (Changesets); a deprecation/migration (codemod) example; a documented contribution/governance model. - [ ] Adoption & docs: Storybook docs; a concrete plan to measure adoption (usage analytics / % of UI on the system). ## Verification - [ ] Document installation and run commands. - [ ] Record automated checks and their exact commands. - [ ] Add representative output, screenshots, or a short demo where useful. - [ ] Confirm failure paths and known constraints. ## Decision log ### Decision title - Context: - Choice: - Alternatives considered: - Tradeoffs: ## Evidence - Link each rubric criterion to the file, test, or artifact that demonstrates it. ## Known limitations - List what is intentionally out of scope and what should be improved next.