Inspect components across product states

State Machine creates a temporary in-app workbench for one existing component. Synthetic data drives each state the component can already reach, while a switcher keeps one state visible and the others available by link or keypress.

The real component is imported unchanged, preserving its production layout context, fonts, global styles, and providers. The workbench stays available while the user works on visuals and is removed when requested. It is a development surface rather than a review verdict.

Use it when a component's loading, empty, error, account, permission, or feature states need to be viewed individually during authorized interface work. Scope one component at a time and describe what it shows, where it renders, and where its production data originates.

The workflow discovers states from existing component and data-hook branches. A design state absent from the code is listed as missing rather than implemented just to populate the workbench. Combinations are included only when the code branches on that combination, avoiding an invented cross-product of every possible condition.

Use break for stacked hostile scenarios inspected in one pass, variant for design alternatives, and interface-review for finished-work review. Creating this workbench does not include unsolicited visual changes.

Read the component and its data hooks to enumerate reachable states. Data examples can include loading, no results, one item, typical volume, scrolling or pagination, partial requests, and stale-data refetching. Account and feature branches can include plan, role, permission, trial, limits, and locked features.

Name each state in product language and group it by what changes, such as Data, Account, Connection, or Access. Record dropped state kinds and the reason before building.

Place the page, fixtures, and switcher together in a scratch-route folder so cleanup is localized. Render one component instance at its production width. The page supplies the container and fixtures without changing the component's visual theme. In frameworks with a server/client split, the harness uses client code:

"use client"

Feed synthetic data at the component's real boundary. Prefer direct props; otherwise use the application's query cache, mock provider, or existing request mocks. Do not thread fixture-only props through unrelated layers. If a new seam would require changing the component, request that scope before adding it.

Fixtures use realistic product-shaped names, timestamps, amounts, and row counts. Pending states remain pending until the switcher changes, rather than resolving on a timer. This makes the visual state stable for inspection.

The grouped switcher updates the __state query parameter, making each state independently linkable. It sits beside the component as a scrollable list, or above it as a grouped select when space is limited. The control remains visibly separate from the design under inspection.

Before handoff, load every state in an available browser and confirm the intended mock data actually appears. Blank regions, live-data substitution, refetching over seeded data, or lost fixtures require plumbing fixes. Without browser access, disclose that limitation and provide the URL for checking.

Hand over the URL, state inventory, and switcher keys. Recheck every state after visual changes. On requested removal, delete the page folder and approved seams, then search route and fixture names and inspect the diff for leftovers.

The workbench uses existing project components and supported data seams. The switcher.md reference defines its control behavior. Browser availability determines whether rendered state confirmation can be completed.