Skip to main content
Acceptance criteria describe observable behavior that should hold when the work is complete. Include them in the task or specification so implementation and review use the same definition of success.

​
How a build is verified

Before a build that changed code finishes, the agent submits the work to an independent judge. The judge reads the recorded commands, tool results, and browser checks from the run, never the agent’s own summary, and scores every acceptance criterion. For criteria it cannot prove, a separate QA agent checks the app live. The agent then fixes what is still unproven and submits again. The Verify card in the chat reads “Verifying…” while the judge runs and then shows the verdict, for example 13/15 proven and 2 needing proof, with each unproven criterion and why. Each judge call uses credits like a turn and appears in the project’s credit breakdown as the verification judge.

​
Evidence to inspect

Browser tools can navigate, interact, assert outcomes, and capture screenshots. A screenshot establishes visible state; a passing interaction assertion establishes more about behavior. Both can be useful in review.

​
Make the checks reproducible

Provide the project’s setup commands, test accounts or role requirements, and any services needed to run the application. Ask the agent to identify skipped checks and blockers such as missing configuration or an unavailable preview. For permissions-sensitive features, verify both allowed and denied cases. For UI changes, include the relevant screen sizes and interaction states. Review test data and external side effects as part of the task scope.

​
Before shipping

Read the diff and the verification result. A passed verification covers the criteria the judge scored, not every possible behavior. Repository CI and your review process still decide whether a change is ready to merge or publish. Continue with pull requests, preview, and publish.