Essential session storage is required to sign in. Optional analytics remain off unless you allow them.
Build the foundation of a small design system. Define DESIGN TOKENS in tiers — primitive/global (raw values), semantic/alias (intent, e.g. color-action), and a couple of component tokens — as JSON and/or CSS custom properties. Then build 2-3 coded components (e.g. Button, Input) that consume ONLY semantic tokens (no hardcoded values), and prove theming works by adding a dark theme that switches purely by swapping token values (no component code changes). Document each component briefly with usage do/don'ts.
Correct tiers (primitive -> semantic -> component); components consume semantic tokens, not raw/hardcoded values.
Light/dark (or multi-brand) achieved by swapping token values via CSS custom properties — no component code changed.
2-3 clean, reusable components with sensible APIs; consistent use of the foundations.
Brief usage guidance / do-don'ts per component.
Use this README structure to make the work reviewable.
DevPath fetches a read-only, size-capped snapshot. Submitted code is never executed.
# A token system with themed components ## Goal Build the foundation of a small design system. Define DESIGN TOKENS in tiers — primitive/global (raw values), semantic/alias (intent, e.g. color-action), and a couple of component tokens — as JSON and/or CSS custom properties. Then build 2-3 coded components (e.g. Button, Input) that consume ONLY semantic tokens (no hardcoded values), and prove theming works by adding a dark theme that switches purely by swapping token values (no component code changes). Document each component briefly with usage do/don'ts. ## Acceptance criteria - [ ] Token tiers: Correct tiers (primitive -> semantic -> component); components consume semantic tokens, not raw/hardcoded values. - [ ] Theming: Light/dark (or multi-brand) achieved by swapping token values via CSS custom properties — no component code changed. - [ ] Components: 2-3 clean, reusable components with sensible APIs; consistent use of the foundations. - [ ] Docs: Brief usage guidance / do-don'ts per component. ## 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.