Browser Recording, video/GIF evidence for UI flows

A still frame cannot prove motion or sequence correctness. When a UI change involves animation, transitions, or a multi-step flow (wizard steps, a modal opening, drag interactions), record it. This skill is the how for the evidence rule in the frontend-design-workflow skill's Phase 3.

Recording evidence for GUI PRs (provenance)

frontend-design-workflow Phase 3 owns which evidence a GUI change needs: a still screenshot for a static layout or styling change, a recording for motion, a transition, or a multi-step flow a still frame cannot prove. This section does not widen that rule, do not record a change a screenshot already covers, it adds the one thing Phase 3 leaves open: how to make a recording reproducible and honest about how it was produced.

When a change does need a recording, it must come from the real server and model flow: the actual dev/preview server running the branch, driven through a real interaction, never a fixture, a mock, or a hand-faked event stream. A recording of a stubbed surface proves nothing about the code under review.

Embed the recording with a provenance line beside it disclosing how it was produced:

recorded from <full-SHA> · <tree/origin> · mode: <flags> · real server + model, no fixtures

State the commit SHA, the tree or origin it came from, any mode flags that change behaviour, and an explicit real-vs-fixture disclosure. The line is written by the same agent that made the recording, so it discloses provenance rather than proving it, the real check is the SHA-pinned embed a reviewer can open and a re-record from that SHA. A recording with no provenance line leaves how it was produced unstated.

What it does

scripts/record_browser.py drives a headless Chromium through the target project's own Playwright install, records the session as webm, and, when ffmpeg is available, converts it to mp4 and a palette-optimized GIF.