diff --git a/phase0_findings.md b/phase0_findings.md
index cc31baf..d57d793 100644
--- a/phase0_findings.md
+++ b/phase0_findings.md
@@ -54,6 +54,10 @@ mpv --hwdec=v4l2request --vo=gpu fourier-test/bbb_1080p30_h264.mp4
 
 Correct picture, slow due to GPU shader path on Mali-G52. Documented as the campaign's interim recommended path.
 
+**Locked acceptance criterion for iter1 (2026-05-08):**
+
+Per operator decision, the iter1 fix is considered shipped only when the before/after screenshot pair in `screenshots/` reconciles. The current broken state is `screenshots/frame10_dmabuf_green.png` (uniform dark green). The target post-fix state is `screenshots/frame10_expected.png` (correct bbb frame 10, captured via the working `--vo=gpu` path on the same hardware/session). Verification protocol in `screenshots/README.md` — SSIM > 0.95 on the central frame area + valid `.add()` semantics in WAYLAND_DEBUG capture + no regression on `--vo=gpu` or `--vo=wlshm`.
+
 ---
 
 ## Locked research question (original — superseded by Phase 0 conclusion above)
diff --git a/screenshots/README.md b/screenshots/README.md
index 64a4d72..d31e7fd 100644
--- a/screenshots/README.md
+++ b/screenshots/README.md
@@ -1,11 +1,27 @@
-# Screenshots
+# Screenshots — iter1 acceptance criterion anchor
 
-Reference captures of the user-visible bug. Filed alongside `phase0_findings.md` so future readers see the symptom directly without reproducing it.
+These two screenshots are the **locked acceptance criterion** for the iter1 fix per operator decision 2026-05-08. The fix in `mpv vo_dmabuf_wayland.c` (or wherever the plane-semantics mismatch turns out to live) is considered shipped only when frame 10 of the bbb fixture under `--vo=dmabuf-wayland` matches the expected reference.
 
-## frame10_dmabuf_green.png
+## Before fix (current broken state) — `frame10_dmabuf_green.png`
 
 `mpv --hwdec=v4l2request --vo=dmabuf-wayland --pause --start=00:00:00.42 --fullscreen fourier-test/bbb_1080p30_h264.mp4` on ohm, frame ~10 of `bbb_1080p30_h264.mp4` (24 fps), captured via `spectacle -b -f -n` 2026-05-08.
 
-Shows uniform dark green fill where the bbb test pattern should be. Black bars top/bottom are letterboxing from fullscreen presentation on PineTab2's 1280×800 display vs the 1920×1080 / 16:9 source — they're not part of the bug.
+Uniform dark green fill ≈ RGB(0, 75, 0). Matches the predicted output of an all-zero NV12 buffer (Y=0, U=0, V=0) through BT.601/709 → RGB conversion. Confirms the [marfrit/dmabuf-modifier-triage#1](https://git.reauktion.de/marfrit/dmabuf-modifier-triage/issues/1) diagnosis: KWin reads UV plane past-EOF on its `fd 42`, gets zeros, renders dark green.
 
-The dark green color is approximately RGB(0, 75, 0), which matches the predicted output of an all-zero NV12 buffer (Y=0, U=0, V=0) through BT.601/709 → RGB conversion. Confirms the [marfrit/dmabuf-modifier-triage#1](https://git.reauktion.de/marfrit/dmabuf-modifier-triage/issues/1) diagnosis: KWin reads UV plane past-EOF on its `fd 42`, gets zeros, renders dark green.
+Black bars top/bottom are letterboxing (PineTab2 1280×800 display vs 1920×1080/16:9 source) — not part of the bug.
+
+## After fix (expected target) — `frame10_expected.png`
+
+Same command but `--vo=gpu` (the working VO that bypasses the wl_dmabuf protocol path). Same frame, same fixture, same display.
+
+Bbb's intro fades in from black, so frame 10 of the source is genuinely dark — the dim grass/silhouette on the right edge is real content. (For a more visually distinct anchor, frame 100+ would show the butterfly scene; frame 10 stays per operator spec.)
+
+## Verification protocol
+
+The iter1 fix has shipped when:
+
+1. With the fix applied, running the `--vo=dmabuf-wayland` reproduction command at frame 10 produces a screenshot that **structurally matches** `frame10_expected.png`. Pixel-level identity is not required (compositor scaling / ditherering may differ); structural similarity (SSIM > 0.95 for the central frame area, ignoring letterbox bars) is the threshold.
+2. The `WAYLAND_DEBUG=1` capture of the same run shows the `.add()` calls in either of the two valid forms documented in [marfrit/dmabuf-modifier-triage#1](https://git.reauktion.de/marfrit/dmabuf-modifier-triage/issues/1):
+   - same fd repeated for both planes with non-zero offset for plane 1 (single-allocation form), or
+   - different fds for each plane with offset=0 for both (per-plane form)
+3. The fix doesn't regress the `--vo=gpu` working path or `--vo=wlshm` working path on the same fixture.
diff --git a/screenshots/frame10_expected.png b/screenshots/frame10_expected.png
new file mode 100644
index 0000000..63433c3
Binary files /dev/null and b/screenshots/frame10_expected.png differ