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

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.

Status	Meaning	Counts as
`PASS`	The postcondition was observed	Met
`FAIL`	The postcondition was observed to be false	Not met — this is a finding
`BLOCKED`	The postcondition could not be observed: capture unavailable, permission wait unresolved, missing binary or connection, environment prevented the step	Neither. Name what blocked it and what unblocks it

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

Check	Pass condition
Exists and decodes	ffprobe exits 0 with duration > 0, and the `ffmpeg -xerror` decode exits 0 with empty stderr
Resolution	Matches the fidelity compose resolved: 1920x1080 for `compact`/`standard`, 2560x1440 for `inspect` (the default for `side-by-side`), or the explicit `width`/`height` in the props
Pixel format	`pix_fmt=yuv420p` with `color_space=bt709` (a `yuvj420p` stream means the render bypassed `render-showcase.sh`)
File size	Under 5 MB for GitHub embeds (25 MB hard limit)
Duration	Equals `4s + longest_clip / speed + 3.5s` (compose's duration checkpoint) and falls 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 matches the resolved fidelity, 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

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

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

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 status (`PASS` / `FAIL` / `BLOCKED`)
Evidence attached	Screenshots/snapshots at every step
Failures documented	`FAIL` steps have evidence and description; `BLOCKED` steps name the blocker and what unblocks it
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

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

Status vocabulary

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

Status	Meaning	Counts as
`PASS`	The postcondition was observed	Met
`FAIL`	The postcondition was observed to be false	Not met — this is a finding
`BLOCKED`	The postcondition could not be observed: capture unavailable, permission wait unresolved, missing binary or connection, environment prevented the step	Neither. Name what blocked it and what unblocks it

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

Check	Pass condition
Exists and decodes	ffprobe exits 0 with duration > 0, and the `ffmpeg -xerror` decode exits 0 with empty stderr
Resolution	Matches the fidelity compose resolved: 1920x1080 for `compact`/`standard`, 2560x1440 for `inspect` (the default for `side-by-side`), or the explicit `width`/`height` in the props
Pixel format	`pix_fmt=yuv420p` with `color_space=bt709` (a `yuvj420p` stream means the render bypassed `render-showcase.sh`)
File size	Under 5 MB for GitHub embeds (25 MB hard limit)
Duration	Equals `4s + longest_clip / speed + 3.5s` (compose's duration checkpoint) and falls 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 matches the resolved fidelity, 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

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

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

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 status (`PASS` / `FAIL` / `BLOCKED`)
Evidence attached	Screenshots/snapshots at every step
Failures documented	`FAIL` steps have evidence and description; `BLOCKED` steps name the blocker and what unblocks it
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.

verify

Documentation

Documentation

Verify

Inputs

Status vocabulary

Video deliverables

Technical checks

Commitment checks

Content checks

Screenshot/snapshot deliverables

For proofs

For QA reports

Failure handling

Output

Documentation

verify

Documentation

Verify

Inputs

Status vocabulary

Video deliverables

Technical checks

Commitment checks

Content checks

Screenshot/snapshot deliverables

For proofs

For QA reports

Failure handling

Output