component-stateslisted

# Component States An interactive control is a lifecycle, not a resting style. Map applicable states to semantics, visible treatment, and recovery. ## Decision order and evidence 1. Name role, interaction model, owner, and applicable states. 2. Give each state ARIA/DOM mapping, visible non-color treatment, trigger, and recovery. 3. Test keyboard, focus-visible, contrast, reduced motion, and async completion. Report one evidence row per state; `n/a` needs a subject-absence reason. Hand field validation to `form-ux`, emptiness to `empty-states`, and missing tokens back as gaps, never fallbacks. ## Async/destructive controls Name one semantic owner; visual states only present its lifecycle. | State / event | Guard and observable contract | |---|---| | `ready` / invoke | Click, Enter, Space, and script use one route; accepted work creates a request key. | | `confirming` | Use only for irreversible/broad/cascading work; name consequence, move focus in, restore invoker on cancel. | | `submitting` | Create key before dispatch; reject duplicates; expose disabled/busy and working label. | | matching completion | Only matching key settles work; stale results cannot clear busy, alter target, or move focus. | | success / failure | Record data first; confirm locally and choose focus, or retain context with nearby error/retry/cancel. | Test real and stale/failed completion. If success empties a region, hand it to `empty-states`. ## State matrix Account for these states where appl