flake-triage

# Is it a regression, or is the preview unstable? A changed preview whose source the PR does not touch — clocks, timestamps, randomness, animation frames, network-loaded images — is instability to triage, not a regression to rubber-stamp and not a fix to write blind. The distinction is decidable in a few minutes, at **one commit**, with no reference to the base branch. ## The oracle Render the same preview N times at the *same* commit and compare the bytes. If two renders of one commit differ, nothing about the PR's diff is evidence of anything. ``` for i in 1 2 3; do ./gradlew :samples:android:composePreviewRender --rerun \ -PcomposePreview.filter=<PreviewFunctionName> cp <module>/build/compose-previews/renders/<Preview>.png run-$i.png done md5sum run-*.png ``` `--rerun` is load-bearing: a render task goes `UP-TO-DATE` off its own outputs (including `.error.json` sidecars from a failed run), so a plain re-invocation compares a file against itself and always "passes". **A harness capture has the same oracle, and it is cheaper.** The captures the visual-diff bot compares are Playwright shots of committed static fixtures, so N runs cost seconds and need no JVM. **The `serve` captures (serve-*, viewer-*) are not triaged here any more.** That harness moved with the server to yschimke/compose-preview-server, where it runs as the `visual-harness` CI job; triage them in that repository, against its `preview-harness/`. What stays here is the fixture tree those captures...