Build, verify, ship
Verification
Define acceptance criteria and read how an independent judge checks the work before a build finishes.
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.
A team member can export only the invoices they can access.
The CSV preserves currency and timezone information.
An empty result shows a useful message.
A failed request leaves the export button usable for retry.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
| Check | Useful evidence |
|---|---|
| Types and lint | Actual commands, exit results, and relevant failures |
| Tests | Which behavior and regression cases were exercised |
| Browser flows | The user action and its observed result in the same flow |
| Screenshots | Captured state, viewport, and the feature being reviewed |
| Design review | Specific layout, accessibility, or component-state findings |
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.