thrumeBefore you record.
Use synthetic or approved data, select the debug sources and check their connection. Note the build/environment you are testing. Start just before the relevant steps.
Include the essentials.
Use the description for a simple handoff. These are writing conventions, not automatically collected test fields.
- Scenario and tested build/environment.
- Expected result and actual result.
- Steps taken and whether the issue repeats.
- Timestamp of the failure and relevant captured evidence.
- What is still unknown or needs checking.
Share the evidence.
Give the developer authorized access to the recording and relevant logs. They can inspect it directly or retrieve evidence through MCP. A visible failure and a nearby error can guide investigation without proving causation.
Check the summary against the evidence.
Summaries can use selected or shortened transcript and log excerpts, particularly for long recordings. They may miss details between those excerpts. Use the full transcript, video and captured logs to verify decisions, reproduction steps and possible causes before acting on a report. Screenshot citations use the recording timeline, not a clock shown inside the image.
Record the retest.
After the fix, record the same scenario, label the new build and link the earlier report. State what you checked and whether it met the expected result. Keep the acceptance decision human and explicit.