frontend-componentlisted

# Add or change a UI component Build a component that follows the repo's existing composition, styling, and state conventions, with the behaviour proven by tests and the markup kept accessible. ## Steps 1. **Read the lore first.** Call `search_lore` (Memory MCP) for the repo's component conventions: framework idioms, styling system (CSS modules, tokens, utility classes), state management, and file organisation. Honour any ADRs. 2. **Find a sibling component** and copy its shape — props/typing, file layout, styling approach, and how it is exported and consumed. 3. **Keep it presentational where possible.** Push data loading and side effects to a container/hook; let the component render from props so it stays pure and testable. 4. **Use semantic HTML and design tokens.** Prefer real elements (`button`, `nav`, `header`) over generic `div` stacks, and reference the repo's spacing/colour/type tokens instead of hardcoded values. 5. **Design the states.** Cover hover/focus/active, loading, empty, and error states the ticket implies — not just the happy path. 6. **Test the behaviour** with the repo's component test tooling (e.g. Testing Library): render, assert on roles/labels and interaction, not on brittle markup. 7. **Verify + evidence.** Run the repo's tests and lint, then use the `record-evidence` skill to record `test_output` against the AC and submit for review. ## Rules - Match the existing framework and styling system — never add a competing o