docs: record Phase 7 resilience state and re-scope

docs/PHASES.md

@@ -82,16 +82,24 @@ discovered addresses in reachability order (private IPv4 first).
 
 ## Phase 7 — Resilience and Polish
 
-**Goal**: loss recovery, hardware acceleration, and packaging.
+**Goal**: loss recovery, hardware acceleration, and polish.
 
-- NACK / PLI feedback loop.
-- Jitter buffer on the receiver.
-- VAAPI/NVENC hardware encode probes and fallback.
-- Optional GUI target behind `meson -Dgui=true`.
-- `.desktop` file, icon, packaging notes.
+- [x] PLI keyframe feedback over signaling (receiver asks, sender
+      re-encodes a keyframe; validated end-to-end with an induced loss).
+- [x] Jitter/reorder window on the receiver (16 packets / 60 ms).
+- [x] Hardware H.264 decode probe with software fallback (h264_v4l2m2m —
+      the Pi's VideoCore path; --swdecode opts out).
+- [ ] GTK4 sender GUI behind `meson -Dgui=true` + a waybar widget
+      (requested; plan approved scope: sender panel, state file,
+      `screencast waybar` subcommand).
+- [ ] VAAPI hardware encode probe on the sender (deferred: software
+      encode is not the bottleneck).
+- Deferred: .desktop file, packaging.
 
 **Validation**: sustained streaming under packet loss; hardware accel smoke
-where available.
+where available. PLI + jitter validated on the desktop (induced-loss probe);
+hardware decode validated as clean-fallback on the desktop, hardware path
+pending a run on the Pi.
 
 ## Current phase
 

docs/RUNBOOK.md

@@ -134,6 +134,23 @@ A window manager only comes with the desktop-session alternative, where
 the receiver runs inside it (uncomment the `Environment=` lines in the
 service file as described above).
 
+## Under the hood: resilience (Phase 7)
+
+The receiver absorbs loss in two stages and recovers actively:
+
+1. **Jitter window**: RTP packets are re-ordered by sequence number in a
+   small buffer (16 packets / 60 ms), so Wi-Fi reordering is not misread as
+   loss. In-order streams release immediately (zero added latency).
+2. **PLI feedback**: when a frame arrives genuinely damaged, the receiver
+   drops it and asks the sender for a keyframe over the signaling channel
+   (rate-limited to one request per 500 ms). The sender re-encodes a
+   keyframe immediately — recovery takes one frame time instead of
+   waiting out the rest of the GOP.
+
+**Hardware decode**: the receiver probes `h264_v4l2m2m` (the VideoCore
+path on Raspberry Pi) and falls back to software automatically; the
+journal says which path is active. `--swdecode` forces software.
+
 ## Sender / receiver loopback (Phase 5, manual)
 
 Two terminals on the same desktop session: