Pixel-proof: nothing ships on code review alone.
Render the actual experience. Judge it with evidence. Then ship.
Code review answers one question: is the code right? It cannot answer the question your user actually asks: does the thing look and feel right? A gradient that blows out to white on a light background passes every lint rule. A landing animation that plays once and never again is perfectly valid JavaScript. The diff looks fine. The experience is broken.
The rule
No user-facing artifact goes out on code-vetting alone. Render the real experience, judge it with your eyes, and keep the evidence — screenshots or it didn't happen.
In practice that means every visual change we ship carries its proof: the render on the actual background it lives on, at the worst moment we can find — the hottest frame of a hue cycle, the longest string in a layout, the smallest viewport that matters. Before-and-after side by side, so the judgment is checkable by anyone, including the person who asked for the change.
Find the ugliest moment
Animated and generative things fail intermittently, which is why they survive review — nobody happens to be looking at second 34. So we hunt the worst case deliberately: scan the cycle, score each frame for the failure you're worried about, and screenshot the argmax. If the fix holds at the ugliest moment, it holds.
Why it compounds
The evidence outlives the moment. When someone asks "why does the light mode look like this," the answer is a side-by-side from the day it shipped, not archaeology. And because the proof is cheap — headless render, a handful of frames — there is no excuse to skip it, even on a Tuesday-night one-liner. Especially on a Tuesday-night one-liner.
This page is itself downstream of the rule: the craft log next door documents a fix that only exists because a rendered side-by-side showed the first attempt had drained the life out of our mark.