diff --git a/phase8_iteration6_close.md b/phase8_iteration6_close.md
index 2a5632d..a1ed1b5 100644
--- a/phase8_iteration6_close.md
+++ b/phase8_iteration6_close.md
@@ -51,8 +51,7 @@ Closes GREEN with a single architectural fix.
 1. **WiFi-IRQ-induced frame drops** — observed during YouTube playback on ohm; brcm/iwlwifi driver IRQ work spikes CPU usage and the compositor drops late frames. Decode pipeline is unaffected (driver produces frames on time; presentation schedule slips). Out of campaign scope but worth a separate investigation (IRQ affinity, GRO offload, driver buffer tuning).
 2. **Slot-leak on RequestSyncSurface error path** — when `media_request_reinit` or `DQBUF` fails mid-cycle, the slot stays `busy=true` and isn't returned to acquire-rotation until `RequestTerminate` runs `request_pool_destroy`. With pool=16 and rare errors this is bounded; acquire returns `-1` cleanly when exhausted. TODO: `request_pool_force_release` for error recovery.
 3. **No pixel-correctness verification post-iter5-msync-removal** — iter5 sonnet C3 carry. Probably safe (kernel does DMA sync at DQBUF level on this CMA-backed config) but a frame-hash spot check would anchor formally.
-4. **MPEG-2 path never exercised** — iter1 lock said "H.264 first; MPEG-2 next." Six iterations later, still H.264-only.
-5. **YouTube codec negotiation** — without `Enhancer for YouTube` or `enhanced-h264ify` browser extension forcing avc1, FF150 negotiates AV1 from YT and SW-decodes. v4l2_request handles only H.264 currently. Worth one line in `firefox-fourier/README.md`.
+4. **YouTube codec negotiation** — without `Enhancer for YouTube` or `enhanced-h264ify` browser extension forcing avc1, FF150 negotiates AV1 from YT and SW-decodes. v4l2_request handles only H.264 currently. Worth one line in `firefox-fourier/README.md`.
 
 ## Lessons distilled to memory
 
@@ -76,10 +75,11 @@ iter6 makes the fork structurally cleaner for upstream submission:
 
 Outstanding for upstream-readiness:
 - msync pixel-verification (carry from iter5 sonnet C3)
-- MPEG-2 path validation (iter1 backlog)
 - Slot-leak error recovery (iter6 carry)
 - Probe-pattern test harness for cap_pool race (iter5 sonnet C4 / iter6 candidate A — NOW EXERCISED organically by YT's resolution renegotiations, but a synthetic harness would anchor the claim)
 
+iter1 lock's "H.264 first; MPEG-2 next" backlog item is dropped 2026-05-06: MPEG-2 SD/HD decodes trivially in CPU on RK3568's A55 cluster (well under one core), so the campaign's user audience doesn't need MPEG-2 HW path. If an upstream reviewer asks, the answer is "H.264-only by design — CPU handles MPEG-2 fine on this hardware."
+
 Per `feedback_no_upstream.md`, no PR/MR happens without explicit operator instruction.
 
 ## Phase 1 success criterion — final