T4.3: MediaCodec H.264 encoder/decoder stub (Android)

docs/PRD/reports/T4.2-report.md

@@ -1,10 +1,10 @@
 # T4.2 — VideoToolbox H.264 encoder + decoder (macOS)
 
-**Status:** Pending Review
+**Status:** Approved (scoped down — original PRD acceptance moved to T4.2.1)
 **Agent:** Kimi Code CLI
 **Started:** 2026-05-11T16:29Z
-**Completed:** 2026-05-11T16:29Z
-**Commit:** (see git log)
+**Completed:** 2026-05-12T05:10Z
+**Commit:** 3356ba9
 **PRD:** ../PRD-video-v1.md
 
 ## What I changed
@@ -80,8 +80,27 @@ Total: 618 passed; 0 failed
 
 ## Reviewer checklist (filled in by reviewer)
 
-- [ ] Code matches PRD intent
-- [ ] Verification output is real (re-run if suspicious)
-- [ ] No backward-incompat surprises
-- [ ] Tests cover the new behavior
-- [ ] Approved
+- [~] Code matches PRD intent — **partial.** API surface and `is_keyframe` are real; encode/decode are stubs. Original PRD acceptance ("Unidirectional H.264 720p30 call macOS↔macOS, CPU < 5 % on M1") is NOT met.
+- [x] Verification output is real — re-ran `cargo test -p wzp-video --lib videotoolbox` (4 pass); confirmed `TODO(T4.2-MVP)` markers at videotoolbox.rs:34 and :72.
+- [x] No backward-incompat surprises — new module, additive
+- [x] Tests cover the new behavior — for what's actually implemented (instantiation, keyframe detection)
+- [x] Approved (scoped)
+
+### Reviewer notes (2026-05-12) — Approved with scope reset
+
+**What's actually delivered:** `VideoEncoder` / `VideoDecoder` traits + `VideoError` + `VideoFrame`, `VideoToolboxEncoder` / `VideoToolboxDecoder` that instantiate, `is_keyframe()` working (NAL type 5 = IDR), `request_keyframe()` setting a flag, 4 unit tests.
+
+**What's NOT delivered:** Real VTCompressionSession / VTDecompressionSession wiring. `encode()` returns empty `Vec<u8>`. `decode()` returns `Ok(None)`. The PRD acceptance criterion of a working 720p30 call on M1 < 5 % CPU is unmet.
+
+**Why I'm approving anyway:**
+
+- The trait surface is genuinely load-bearing for T4.4 (NACK), T4.5 (I-frame FEC boost), T4.6 (keyframe cache), T4.7 (PLI suppression). They can write code against the trait and unit-test their own logic.
+- `is_keyframe()` is real load-bearing work used by T4.5 and T4.6.
+- VTCompressionSession wiring (CoreMedia / CoreVideo pixel buffer management, callback threading, CMSampleBuffer construction) is genuinely a multi-day task. Bundling it with "create traits" was the wrong scope; splitting is right.
+- Agent disclosed stub status honestly under both "Why these choices" and "Deviations".
+
+**Process violation noted (not blocking):** The agent **unilaterally redefined "MVP"** from PRD-video-v1's "working call" to "API surface compiles". That is a scope-change decision that belongs to the reviewer. Going-forward rule: when a PRD acceptance criterion is significantly out of reach in the task's effort budget, **file a `Blocked` report** asking the reviewer whether to split / defer / extend. Don't quietly ship the easy part and rename the hard part to a "follow-up". This is exactly what the "When to stop and ask" section of TASKS.md covers.
+
+**T4.2.1 spawned** to capture the actual PRD work (real VT session wiring + macOS↔macOS round-trip test, original 720p30 acceptance).
+
+**Downstream impact warning for T4.4–T4.7:** these tasks can write code against the trait surface but **cannot** validate end-to-end until T4.2.1 lands. Their reports should explicitly note that the encoder is a stub and any "end-to-end" claims are constrained to what the framer/depacketizer can round-trip in isolation.