Golden baselines

Golden baselines live in core/tests/golden/*.png and are ordinary PNGs (viewable in the repo / PR diffs). To regenerate them after an intended visual change:

RLX_BLESS=1 cargo test -p rlx-core --test golden
RLX_BLESS=1 cargo test -p rlx-core --test suite composite::     # the post-stage baselines
RLX_BLESS=1 cargo test -p rlx-core --test suite line_joints::   # the joined-polyline baseline
RLX_BLESS=1 cargo test -p rlx-core --test suite warp_mesh_wide:: # the 4:3 converted-chain baseline

Only the first of those owns the per-SystemKind roster. Every composite_*.png belongs to the composite test, line_joint_zigzag.png to line_joints and warp_mesh_wide.png to warp_mesh_wide; blessing by binary, and inside the suite binary by module name, is what keeps the scopes from rewriting each other. A bless of --test suite with no module filter rewrites every baseline in that binary at once. line_joints additionally refuses to bless at all while its local-minimum claim is failing, so a reopened notch cannot be baselined in. core/tests/suite/feedback.rs is deliberately absent from that list: it pins no baseline at all — see Asserting that something moved.

RLX_BLESS also takes a list of baseline names. RLX_BLESS=1 still means every baseline the run reaches. Any other value is a comma-separated list of stems — the file names under core/tests/golden/ without .png, whitespace around each ignored — and blesses exactly those, comparing every other baseline as an ordinary run would:

RLX_BLESS=waterfall,waterfall_ramp cargo test -p rlx-core --test golden

A name with no PNG under core/tests/golden/ fails the run and lists the unknown names, so a typo is an error rather than a bless of nothing. The check reads the directory, not the tests that ran, so a name is checked whatever the test filter selected. The cost is that a baseline that does not exist yet cannot be named: bless it first with RLX_BLESS=1 under a filter that reaches only it. A value that names nothing, such as an empty one, also fails. Off lavapipe any value at all is refused.

The baselines are blessed on lavapipe, Mesa’s software Vulkan rasterizer, on the Arch reference machine (ADR-0242). common::baseline_adapter is the one predicate: a comparison asserts only when the run is on Linux and its software adapter reports itself as llvmpipe, and anywhere else — DX12 WARP on Windows, a hardware adapter — it prints each fixture’s mean and max outlier, then skips with a notice naming the adapter it ran on, in ADR-0016’s shape. macOS has no software Metal adapter and skips before it captures anything. Those printed readings are kept in a passing run’s output: .config/nextest.toml names each comparison test under success-output = "immediate". So the Windows arm’s drift against the lavapipe baselines can still be read, even though nothing asserts it.

Eyeball the regenerated PNGs before committing — the first baseline is easy to enshrine wrong. The compare tolerates minor cross-GPU rasterization drift; a genuine change exceeds it.

Eyeballing the baseline is not enough on its own, and Plan 0045 is the record of why. The whole suite captures on a software adapter, and WARP is documented to hand a pipeline another live pipeline’s resources (ADR-0021 / Plan 0020, the tonemap in Phase 3, the bloom blur in Phase 4; WARP readings, unverified on lavapipe as of 2026-10-06). A mis-rendered frame at these capture sizes can look entirely plausible: Phase 4’s bloom halo was 2:1 elongated in one draft and smeared into a column of copies in another, and the 160x100 baseline looked like a reasonable glow under both. Render the same fixture on the hardware adapter at a size large enough to see it (shot uses the default adapter, so cargo run -p standalone --example shot -- --preset-file <fixture> --size 512x512 is the check) and confirm the two adapters agree before blessing. Where they disagree, the hardware one is right and the baseline is about to enshrine a driver bug.