Check visual changes mid-edit with uiverify check

uiverify check is the interactive preview build: the edit-loop counterpart to the CI uiverify upload. You have changed a component and want to know now whether it changed anything visually, and whether that change is intended, without opening a pull request or waiting for CI.

It renders on the same fleet and diffs against the same resolved CI baseline a real build would, so the answer is authoritative rather than a local screenshot that will not match Linux. But it is walled off from CI: it posts no GitHub check, so it is invisible on the pull request, and it never advances a CI baseline. Accepting a preview build writes a branch-scoped preview baseline, so your own accepted change stops re-flagging on the next check while CI's baseline stays untouched.

This is the whole point, and it is the opposite of CI. CI computes the transitive affected set from the dependency graph, and editing one primitive can mark a third of the suite affected. That is correct for CI, which writes the baseline and cannot under-render, but it is the wrong default for an edit loop: slow, expensive, and it drowns the signal you want.

So you choose what to render: the stories for the component you are editing, plus the specific places it matters, not everything the graph lights up. Under-scoping is safe here because a preview build is never a baseline, so the worst case is you did not preview a story you did not ask about, and the exhaustive CI build catches it later on your pull request.

Storybook builds the whole suite (there is no single-story build), so --target is required: you name what to render. The build is monolithic; only the named stories actually render on the fleet. Pass --target per id, each an exact story id or an anchored glob.

Run only the tests you care about to produce the capture archive, then check it. The archive already contains just those captures, so the uploaded artifact is the render set and no --target is needed. You can still pass --target to narrow further; it matches the capture ids the SDK emitted.

Upload exactly the PNGs you produced (native, mobile, React Native, or any surface we do not render). The upload is inherently scoped to the screens you took, so --target is optional.

check prints the changed-story list and an MCP handoff. When it comes back changed, review the actual pixels over the UI Verify MCP rather than eyeballing the diff numbers: bucket real regressions from cosmetic reflow and noise, and accept the baselines you mean to keep. Accepting establishes the branch-scoped preview baseline, so a re-run comes back clean for the change you approved while a fresh change still flags. See Triage visual changes from your coding agent.