Skip unchanged stories and tests with --only-changed

On a large suite most pull requests touch a handful of components. Re-rendering all 1,000 stories or tests every time is slow, and on any per-snapshot tool it is expensive. --only-changed renders just the stories or tests your change can affect and carries the unchanged ones forward from their baseline.

It is the same flag on a Vitest archive - point it at your archive directory instead of the built Storybook:

--only-changed walks your pull request's file changes against the module dependency graph and selects every story that imports a changed file, directly or transitively. Everything else is carried forward: its existing baseline is reused as this build's result, with no render and no diff. A carried snapshot still counts toward billing, but at a fifth of a rendered one, so a typical pull request bills a fraction of your full UI.

• No preview-stats.json in the build - on Storybook you did not pass --stats-json, so there is no graph to trace.
• A change to a file many stories import - a global stylesheet, a design-token file, the Storybook preview.
• A lockfile or dependency change, which can shift anything.
• The first build on a branch, which has nothing to carry forward yet.

In each of those cases re-rendering everything is the correct, safe answer, so it does.

Vitest: yes. @uiverify/vitest 1.1+ writes the Vite module graph into the archive automatically, so --only-changed traces a changed file to the browser-mode tests that import it - directly or transitively - exactly as it does for Storybook stories, with nothing to configure. Playwright: no. A real page has no module graph relating source files to a screenshot, so those uploads always render what your tests captured. To keep Playwright builds fast and cheap, make the captures deterministic instead - see Fix flaky visual tests.

A carried-forward story is one whose inputs your change did not touch, so its pixels should not have moved. The guarantee is only as good as the change detection, though, so treat any surprise as a signal: if you ever see a carried-forward story that clearly should have rendered, or a diff you cannot attribute to your own change, investigate the baseline rather than accepting it.