Build a Reusable UI Component to Spec

You are a senior front-end engineer building a production-quality, reusable interface component to a written spec.

<context>
[THE COMPONENT — what it is and does — e.g. "a booking-slot picker: shows a week of time slots, disables full ones, emits the chosen slot"]
[STACK — e.g. "React 18 + TypeScript + Tailwind", "Vue 3", "plain JS web component"]
[API AND DATA SHAPE — the props/inputs and events/outputs you expect, plus sample data — paste real JSON if you have it]
[DESIGN CONSTRAINTS — e.g. "brand blue #1A4FD8, mobile-first, no external UI libraries"]
[STATES THAT MATTER — e.g. "loading, empty week, all slots taken, network error"]
</context>

Before coding, define the component's contract: props and inputs with types and defaults, emitted events or callbacks with payloads, and every visual state from my list plus the ones I forgot (hover, focus, disabled). A component IS its contract; the markup just renders it.

<task>
1. Implement the component for my stack: typed, self-contained, no dependencies beyond what I named, sample data wired so it renders immediately.
2. Cover every state in [STATES THAT MATTER] plus loading, empty and error defaults — implemented, not TODOs.
3. Build accessibility in as table stakes: keyboard operability for every interaction, correct roles and labels for this pattern, visible focus, and colour contrast meeting WCAG AA against my stated colours — call out if my brand colour fails and give the nearest passing shade.
4. Make reuse real: no hard-coded business strings (content via props or slots), styling isolated or namespaced per my stack's norm, and defaults that render something sensible bare.
5. Provide usage examples: minimal use, fully configured use, and an error-state simulation — as copy-paste snippets.
6. End with the test list: the 5-8 behaviours a suite should pin, as test names in my stack's runner, flagging the one most likely to regress.
</task>

<output_format>
Contract table (props — events — states), the complete component code, the usage snippets, then the test list. Code runnable as pasted; one-line captions only between blocks.
</output_format>

Rules:
- No invented design tokens or endpoints: where the spec is silent, choose a default and list it under "Assumptions" (maximum 5) at the top.
- If my data shape and described behaviour conflict, stop and ask rather than reconciling silently.
- Component code complete — no elided sections.

Copy the block above straight into Claude — anything in [BRACKETS] is yours to fill in.