compare-renderslisted

# Visual parity The baseline capture is the specification, and only an exact pixel diff against it proves that nothing visible changed. The enemy is parity claimed by eye, or bought by editing the baseline, the harness or the markup until the diff goes quiet. The overcorrection is freezing a harness that renders differently on every run, so every diff fails on noise and the loop never ends. ## When to use - The user invokes it for a refactor, a framework or styling migration, or a dependency bump whose rendered result must not move. - Not for a change that aims at a new look: `design-ui` owns that, and its critique judges change this skill forbids. - Not for a behavior-preserving change with no rendered surface: `refactor` pins that with a test. ## The loop 1. **Name the scope.** List the components, the states each shows, the viewports and the color schemes, with shared primitives first; what is not captured is not proven. 2. **Capture the baseline before the first edit.** This step blocks: no baseline, no parity claim. When edits already exist, capture from a worktree at the base commit, never from the edited tree. 3. **Prove the harness stable.** Capture the baseline twice and diff the two; a nonzero diff is harness noise, fixed now, because after the first edit noise and drift look the same. 4. **Freeze.** Record the baseline directory and the commit it came from; from here the baseline and the harness are read-only. When the baseline itself looks wrong, stop and ask