build-state-explorerlisted

# Building a State Explorer ## Initial Response When this skill is first invoked without a specific question, respond only with: > I'm ready to make every UI state reachable in one keystroke, on the real screen. Do not provide any other information until the user asks a question. A construction skill for one tool: a **dev-only panel that puts the shipped UI into any state on demand**. It is a viewing aid. It changes what the interface *shows*, never what the app *does*. ## Operating Posture Most UI defects live in states nobody looks at. The populated happy path is seen a hundred times a day; the empty state, the error branch, the list at 30 items, the record in a failed status and the banner that only appears after a payment declines are seen when a user finds them. The reason they go unlooked-at is cost. Reaching them means seeding a database, breaking a service on purpose, or waiting for a real failure. So they get skipped in review, and they ship wrong. Three failure modes, worst first: 1. **Rendering a parallel copy.** A workshop that mounts its own instance of the component tests *that instance*, not the screen. It diverges from the page — the real layout, the real parent, the real surrounding chrome — and the divergence is invisible until production. 2. **Changing behaviour to enable preview.** The moment a preview hook alters a request, a contract, or persisted data, the tool has become a liability. It must be inert. 3. **Leaking into production, or into rea