Verification
Check eligibility, request a fresh replay, and interpret the resulting evidence.
Capture is the starting point
Local capture records an observed failure. Clean verification is a separate run that prepares captured source in a fresh environment, executes the supported command or browser scenario, and compares evidence with the captured baseline.
A sandbox opening successfully, or a static readiness check passing, does not prove that the failure reproduced.
Check readiness and eligibility
Open the reproduction's Verification panel. Read Replay readiness and any eligibility explanation before starting a run.
| Readiness | What it means |
|---|---|
ready_to_attempt | Known static inputs are present; runtime behavior is still unproven |
needs_input | Read the report for missing known inputs |
blocked | Correct the reported blocker or deliberately capture evidence only |
The server checks current access, quotas, source revision, and execution eligibility. Readiness does not reserve compute. Some captures lack a complete failure baseline or use an unsupported replay mode; their evidence can remain useful even when verification is unavailable.
Prepare the environment
For command capture, record dependency installation and preparation with
--setup-install and --prepare where needed. For authored browser scenarios, include
a complete setupPlan and matching failureTarget. Local scenario capture skips that
setup plan, so local success does not prove it will work in a fresh environment.
Make required environment values and supported fixture services available through the product's setup controls when applicable. Never place credentials in source examples or assume the sandbox can access your local or external services. Install lifecycle scripts require explicit permission.
Request a run
When eligible, choose Run verification. The panel shows the current state while work is running. If the button is unavailable, read its nearby explanation. Starting a live terminal is not the same action.
After the run finishes, open View full report. Inspect the outcome, setup details, output, and available comparison evidence. Reports can include exit code, exception, stack trace, and output comparisons, or browser scenario evidence.
Interpret the report
A similarity score, when present, describes the comparison made by that run. It does not certify the application or establish that every behavior matches.
A matching replay supports the captured failure baseline. A drifted result means relevant evidence differs. Setup errors, timeouts, provider failures, and unavailable comparisons require investigation; they are not proof that a fix works. Some unsuccessful runs have no score.
If the workspace says a result is stale after source changes, request verification again for the current revision. Read the new report rather than relying on an earlier score.
Check a candidate fix
Use the fix checking action only when it is offered for this reproduction and a suitable baseline exists. Read which source and comparison it will use before running it. A changed or missing failure is evidence to inspect, not an unconditional promise of correctness. Run your own relevant tests too.
If replay is unavailable or fails before comparison, use verification recovery.