Record Verification

Make the changed user path inspectable by a human. The video is evidence of what happened in the running app, not a substitute for assertions and not a release film. The reviewer decides whether the behavior, appearance, and direction are right.

1. Define the proof

Identify the changed user-visible behavior, its entry point, expected result, and any persisted or cross-surface effect. Read the repository's applicable agent guides, verification skill, feature map, recipe, and test harness before driving the app. Discover local CLIs and their current help rather than assuming a universal launch or login command. If no user-visible path exists, explain that and offer the relevant non-video evidence instead of staging a fake walkthrough.

Choose a small number of scenarios that cover the changed risk. Sketch the few action → result beats the reviewer must see and estimate the viewing time from those beats, not from the agent's execution time. Favor the shortest cut that remains understandable at 1×; a simple flow may be brief, while a complex or cross-surface flow may need longer or separate focused clips. Preserve essential evidence rather than forcing a fixed duration. Name what the selected path cannot prove. Use a task-owned or explicitly approved environment and non-sensitive fixture; respect shared instance, account, device, and data ownership rules. Do not reset, seed, or mutate a shared environment merely to make footage attractive.

2. Prove and rehearse

Run the owning readiness check and relevant automated verification. Exercise the real user controls and assert the resulting state, not just successful clicks or a loading shell. Inspect applicable console, network, logs, or persistence evidence when the behavior depends on them. A passing video cannot override a failed check, and a passing test cannot replace seeing the UI.

Rehearse navigation, authentication, test data, and state-based waits before the take. Plan how to drive the recorded path without leaving model reasoning or slow tool-call gaps on screen: use an existing deterministic UI drive when appropriate, or capture short continuous sections and assemble a review copy. Keep credentials, setup shortcuts, and test-only controls out of the visible user path; disclose any setup that affects interpretation. If the flow fails, diagnose or report the failure. A reproducible failure can be recorded as failure evidence; do not present a later take as if the failure never occurred.

3. Select capture

Use the repository's owning browser or native driver for interaction. Select the recorder that actually covers the review surface: