Testing and recordings
Ask the run to exercise its own result through the same surface a person or system will use.
The most valuable instruction you can add to a job is that the agent must test what it built before asking for review. Open the finished artifact. Run the application. Operate the browser flow. Query the system after writing to it.
This is not the same as running the test suite. A suite proves the code behaves; a walkthrough proves the thing works for the person who will use it.
What a recording proves that a test does not
| Check | What it can show | What it cannot |
|---|---|---|
| Unit and integration tests | The logic behaves as specified | Whether the flow is usable |
| Type checks and lint | The code is internally consistent | Whether the rendered result is correct |
| Screenshot | The state at one moment | Whether the path to it worked |
| Recording | The whole interaction, in order | Anything off screen |
| Read-after-write | The write actually landed | Whether the value is right |
Stack them rather than choosing. A tested pull request with a recording of the affected flow is materially easier to accept than either alone.
Documents and Office files
A source file cannot prove its own rendering. For presentations, spreadsheets, and documents, ask for the final export to be checked, not just the file to be produced.
Opulent creates native editable Office files rather than web-only approximations, and retains durable previews so a reviewer can inspect the rendered result after the workspace cools or reloads.
Nightly and scheduled testing
Browser and application tests are a natural fit for a schedule. Run them against staging each night and have failures create tickets with the evidence attached, so the morning starts with a diagnosed failure rather than a red dashboard.