diff --git a/phase0_findings.md b/phase0_findings.md
index d57d793..9dd22b3 100644
--- a/phase0_findings.md
+++ b/phase0_findings.md
@@ -40,11 +40,9 @@ create_immed(wl_buffer#56, 1920, 1080, NV12, flags=0)
 - mpv's `vo=dmabuf-wayland` is the unique broken path because it constructs the wl_dmabuf protocol message itself, mishandling the producer's plane semantics.
 - mpv's `vo=wlshm` is fine because it goes through CPU memcpy, bypassing the dmabuf protocol entirely.
 
-**Deferred verifier (gates iter1's actual fix):**
+**iter1 is unblocked.** The wl_dmabuf message in the WAYLAND_DEBUG trace is internally inconsistent on its own — combining per-plane fds with a single-allocation offset for plane 1 is something no valid producer can claim simultaneously. mpv's translation layer produces this regardless of which producer feeds it. The fix can be written from the ffmpeg-side data alone.
 
-Re-run the WAYLAND_DEBUG capture with `--hwdec=vaapi` (libva path) once `libva-v4l2-request-fourier#1` is fixed and the cap_pool/REQBUFS cascade stops blocking libva playback. If both paths produce the same wrong `.add()` pattern → bug is purely in mpv VO. If only one does → that path's producer (libva or ffmpeg V4L2 hwaccel respectively) is the bug.
-
-This means iter1's fix work cannot start until libva-multiplanar iter9 lands. dmabuf-modifier-triage iter1 is **blocked-on**: libva-multiplanar/iter9.
+**Follow-up validation (not a prerequisite):** once `libva-v4l2-request-fourier#1` is fixed and the cap_pool/REQBUFS cascade stops blocking libva playback, re-run the WAYLAND_DEBUG capture with `--hwdec=vaapi` to confirm the same fix also handles the libva path. If both paths produce the same wrong `.add()` pattern → fix is correct. If only one does → expand the fix to handle both producer shapes (the AVDRMFrameDescriptor and VADRMPRIMESurfaceDescriptor mappings to wl_dmabuf may need separate logic).
 
 **Working ohm HW-decode workflow until fix lands:**