How visual regression testing works

UI Verify runs as a single step in your CI. You hand it an archive from your Vitest or Playwright tests, or a built Storybook; it does the rest in the cloud and reports back on the pull request. For a Storybook build it also runs each story's interaction testing play function before capturing, so the snapshot is of the settled, interacted state. Here is what happens between the upload and the check.

1. Your CI runs uiverify upload with your Vitest or Playwright archive, or your built Storybook.
2. UI Verify ingests the build and resolves the baseline for each story from its branch history.
3. A fleet of workers renders every story in a real browser and diffs it against its baseline.
4. An AI judge labels each changed story a likely regression or a likely intended change, with a reason.
5. A check and a comment land on your PR, with the changes grouped and pre-sorted for review.

When someone accepts it: a person reviewing the build, an agent you authorized over MCP, or a CI run you told to accept with --auto-accept-changes (an option on default-branch pushes). Baselines are per branch, a change stays a change until it is accepted, and accepting is what sets the new baseline. On a build's page you can accept every pending change at once, or, when the build has both, accept only the new stories or only the changed ones from the same control. No verdict promotes a change by itself, which is what keeps a green build trustworthy. See Baselines and branches.

Everything after the upload happens in the cloud. There are no browsers to install in CI, no snapshot images committed to your repo, and no local render farm to babysit. Your pipeline stays one step.