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:

1. Commitments from the command's parse step -- the promises made about what the deliverable would contain
2. Compose outputs -- the finished artifact(s) and their metadata

Composition is optional: raw desktop screenshots/state and the driver's evidence handoff can be the deliverable. Verify the task's postcondition, not merely the action's exit status or effect field.

Status vocabulary

Every step, check, and postcondition gets exactly one of these; commands and driver atoms use the same words.

BLOCKED is never rolled into PASS or FAIL. A deliverable with BLOCKED steps is incomplete unless the user accepts the partial evidence. /verify's claim verdict (CONFIRMED / REFUTED / INCONCLUSIVE) is about evidence sufficiency, not step status: any BLOCKED step that the claim depends on makes the verdict INCONCLUSIVE, but INCONCLUSIVE also covers steps that all ran and still did not decide the claim.

Video deliverables

Technical checks

Run ffprobe on the final .mp4, then a full decode:

ffprobe -v quiet -print_format json -show_format -show_streams <video>
ffmpeg -v error -xerror -i <video> -f null -   # -xerror: exit non-zero on the first decode error

Commitment checks

Walk through each commitment from the parse step:

Content checks

Metadata cannot show what is on screen. For every proof point, extract the frame and look at it:

ffmpeg -v error -y -ss <t> -i <video> -frames:v 1 "${RUN_DIR}/proof-<t>.png"   # then Read the PNG

• Every claim from the "what to prove" analysis has visible evidence in the video, confirmed in an extracted frame at the timestamp you report
• Both states (before/after, input/result) appear on screen
• The final state: clips play from t = 4.0s to t = 4.0s + longest_clip / speed, fully visible; after that the last frame is held under the outro crossfade. Extract the final proof frame just before the clips end (e.g. t = 4.0 + longest_clip / speed - 0.1), not from the crossfade
• In a side-by-side, a shorter clip holds its final frame; confirm the held panel shows the intended final state, not an unfinished step
• No dead time longer than 3 seconds without visible activity

Screenshot/snapshot deliverables

For proofs

For QA reports

Failure handling

If any check fails:

1. Identify which stage produced the problem (capture or compose)
2. Report the specific failure: "Side-by-side layout was committed but the output is a single panel"
3. Go back to the failed stage and fix it
4. Re-verify after the fix

Do not report a deliverable as complete until every commitment is met.

Output

## Verification

### Technical
- Decode: ffmpeg -xerror exit 0 ✓
- Resolution: 2560x1440 (inspect, side-by-side) ✓
- Duration: 52.5s = 4 + 45 + 3.5 ✓
- Size: 3.2 MB ✓
- Format: yuv420p / bt709 ✓

### 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 (frame at 0:18 read: new session id in header)
- [x] History diverges after fork (frame at 0:32 read: differing last messages)

All commitments met. Deliverable ready.