component

Create one CSF3 story per applicable state (default, hover, focus-visible, disabled, loading, error, empty) with the story name matching the state. Add interaction stories using play functions with userEvent and expect for each public behavior like open, submit, or keyboard navigation.

Pick one convention; if supporting both, pair value with defaultValue and onChange, using a hook like useControlledState. Avoid mixing conventions across siblings, since dual sources of truth cause synchronization bugs.

A presentational component takes props, renders deterministically, and emits events for state the parent owns. It must not fetch data, read routers or stores, import domain types, or hold business rules — those belong to the consuming application.

Grep the component file for imports like useQuery, useMutation, useRouter, useStore, fetch, axios, or API paths. Each hit should be lifted to a prop or callback the consumer supplies, or extracted into a co-located hook taking plain arguments.

Expose sub-components like Dialog.Header when consumers legitimately rearrange parts; otherwise keep a single closed surface. Sub-components are public API and cost more to evolve, so prefer composition only when rearrangement is a real need.

Raw values bypass the design-token system, causing visual drift and breaking theming. Reference named semantic tokens instead; if a needed token does not exist, propose a name as an open question rather than hardcoding the value.