Reviews & QA
How a change gets checked before and after it ships
For repository work, an agent can deliver a pull request and a configured preview. This page describes that code-review and delivery workflow. Tasks that produce research or use connected business tools can have other reviewable results.
The automated pass
A single reviewer runs one pass over the change. It either approves, or requests changes and hands the card to a human. It deliberately doesn't loop — an agent arguing with a reviewer burns budget without converging.
This replaced an earlier split between a QA pass and a code-review pass. One pass with a clear hand-off beat two passes that disagreed.
The preview
When the project provides preview deployments, a pull request brings up a preview — the change running, at a URL you can open and share. The card lists the exact pages that changed, so you're not guessing what to check.
Review the preview before the diff. The preview is the outcome; the diff is the method.
Post-deploy validation
Shipping isn't the end of the task. The post-deploy validation column makes the last step explicit: someone confirms the change did what it was supposed to do, in production.
The delivery lanes — approved, merged, post-deploy validation — are behind an org flag. Without it, the board ends at in review and validation goes back to being informal.
What still needs a human
Automatic fixes are not automatically merged. Auto-merge is off by default, and automated correction has a real error rate, so most changes wait for a person to approve them. That's a deliberate setting, not a missing feature: the cost of a wrong merge on a live storefront is much higher than the cost of a click.
As the reviewer's track record on your repository builds, that balance is worth revisiting with your team.