Reproduce and attribute a selected Check's defect

Use this procedure when a selected Check exposes an error, regression, intermittent failure or expensive resource. The operating contract owns evidence requirements; use the existing Check record and Issue format, not a separate bug report or severity system.

1. Reduce the observation to the shortest reproducible action sequence. Record frequency and the exact preconditions that change the result, such as variant availability, cart surface, consent, market, app embed or theme settings.
2. Inspect the relevant DOM/accessibility state, console error, failed request, response, initiator or performance trace. Compare a working adjacent state when useful.
3. Trace the failing action to its active handler, state transition, Liquid emitter, configuration or third-party boundary. For resources, start with the rendered element and selected request; search a distinctive selector, data attribute or asset name in the available repository using the repository discovery procedure.
4. Verify that the matching source is on the active render path. Source assets, generated bundles and app-injected markup may have different owners; matching a filename alone is insufficient.
5. Challenge one falsifiable cause at a time without changing code, flags, apps or settings. Retest the unchanged reproduction when more evidence is needed.
6. Hand off the smallest supported change and exact regression/retest condition through the owning Check's Issue. When source is unavailable, name only the ownership supported by browser evidence.

If the original environment cannot be reached, label any preview difference. Third-party correlation alone is not proof: a proposed app-isolation step belongs in the handoff and does not authorize disabling it during the audit.