Verify
The orchestrator routed you here. This atom checks the final deliverable against the commitments made at the start of the workflow.
Inputs
You receive:
- Commitments from the command's parse step -- the promises made about what the deliverable would contain
- Compose outputs -- the finished artifact(s) and their metadata
Video deliverables
Technical checks
Run ffprobe on the final.mp4:
ffprobe -v quiet -print_format json -show_format -show_streams <video>| Check | Pass condition |
|---|---|
| Exists and plays | ffprobe exits 0, duration > 0 |
| Resolution | 1920x1080 (or target resolution) |
| Pixel format | yuv420p |
| File size | Under 5 MB for GitHub embeds (25 MB hard limit) |
| Duration | Must fall within the compose pacing table's target range for this demo type: 30-45s (single feature), 45-75s (side-by-side comparison), 60-120s (multi-phase). Below the minimum is a failure — re-compose with a lower speed factor or re-capture with more steps. |
| Filename | Includes PR number or meaningful identifier |
Commitment checks
Walk through each commitment from the parse step:
| Commitment | How to verify |
|---|---|
| Title card | Video starts with a static frame showing PR info (check first 5s) |
| Side-by-side layout | Video shows two panels with a divider |
| Showcase polish | Resolution is 1920x1080, window chrome and rounded corners visible |
| Keystroke overlay | Pill overlays appear at interaction points |
| Effects | Effects matching the committed tier are present (utilitarian: zoom/keystroke; full: spotlight, zoom, callout, keystroke) |
| Speed note | Title card mentions playback speed |
Content checks
- Every claim from the "what to prove" analysis has visible evidence in the video
- Both states (before/after, input/result) appear on screen
- No dead time longer than 3 seconds without visible activity
Screenshot/snapshot deliverables
For proofs
| Check | Pass condition |
|---|---|
| Evidence exists | Screenshots/snapshots at every claimed proof point |
| Environment stated | Driver, terminal/browser, OS identified |
| Conclusion present | Evidence explicitly supports or refutes the claim |
| Before/after paired | If comparison, both branches shown at same capture points |
For QA reports
| Check | Pass condition |
|---|---|
| Step coverage | Every defined test step has a result (PASS/FAIL) |
| Evidence attached | Screenshots/snapshots at every step |
| Failures documented | Failed steps have evidence and description |
| Report structured | Markdown report follows the QA template |
Failure handling
If any check fails:
- Identify which stage produced the problem (capture or compose)
- Report the specific failure: "Side-by-side layout was committed but the output is a single panel"
- Go back to the failed stage and fix it
- Re-verify after the fix
Do not report a deliverable as complete until every commitment is met.
Output
## Verification
### Technical
- Resolution: 1920x1080 ✓
- Duration: 42s ✓
- Size: 3.2 MB ✓
- Format: yuv420p ✓
### Commitments
- [x] Title card with PR info
- [x] Side-by-side comparison layout
- [x] Showcase hero preset applied
- [x] Keystroke overlay visible
### Content
- [x] Fork creates independent session (visible at 0:18)
- [x] History diverges after fork (visible at 0:32)
All commitments met. Deliverable ready.