Stress components with realistic edge cases

Break builds a visual stress-test page for one existing component. It imports the real component from the project and renders an instance for each scenario that can actually reach it. The page is the main deliverable: users can scroll through labeled scenarios and see observed breaks marked directly alongside them.

The workflow observes failure rather than issuing a design verdict. A finding must describe something visibly broken, such as text escaping a field. Each finding names the domain skill that owns diagnosis and correction. A clean run can end with Everything survived and the scenario list.

Use this skill to check how a component handles realistic worst-case content, states, containers, and environments. Isolation is intentional: it tests whether the component defends itself rather than judging its appearance in the full page.

Keep the scope to one component per run. If a request covers several, identify the candidates and ask which one to test. Reviewing code against standards belongs to interface-review or better-interface; exploring alternatives belongs to variant; working through product states individually belongs to state-machine.

Harness creation requires an authorized implementation scope. The run is deliberately bounded to building the page, looking once, and reporting. It does not expand into instrumentation, browser debugging, or repeated exploratory passes.

Start by reading the component's props, slots, states, and rendered data. Restate what it accepts, what it renders, and where it will live. The scenarios.md reference supplies possible axes and applicability cues. Keep only matching axes, list the retained scenarios before building, and explain dropped axes briefly.

The harness is a scratch route inside the application. It inherits the application's layout, fonts, global styles, and providers. It adds scenario labels, fixed container widths, and synthetic fixture props, without restyling the component or simulating a different theme. Fixtures do not import production state or connect to live data, and production code does not import the harness.

Render scenarios in a single column with labels above each instance. Where the framework separates server and client components, the harness page uses client code so fixture data reaches the rendered component. A missing fixture is a harness failure rather than evidence against the component.

Load the page once in an available browser and inspect scenarios from top to bottom. Record only visible failures, then add one-line notes under the affected labels in a single edit. If no browser is available, deliver the URL and scenario list for checking; do not create findings or page annotations from predictions.

The accompanying table contains Scenario, Observed, and Owner, with broken scenarios first. It has no verdict and does not pad a clean result with preferences. Corrections happen only when requested, using the owning skill's rules and rerendering the failing scenarios.

Leave the page available after reporting. Delete it and its fixtures only when the user requests cleanup, then search for their names and inspect the diff to ensure the harness is fully removed.

The harness uses the project's real component and application environment. Existing browser access supports the single inspection, while domain skills such as better-typography and better-writing identify ownership of observed failures. Tool availability limits what can be verified.