docs/scenario-mesh-receiver-patch.md

@@ -1,8 +1,9 @@
 # ESP-NOW scenario receiver — patch to report onto PLIP + puzzles
 
 Status: **box3_voice done**; **puzzle nodes done** (defensive demux in the
-shared `espnow_slave.c`, see "Resolution" below); **PLIP out of scope by
-design** (Wi-Fi/HTTP-only client, no ESP-NOW stack — see "PLIP" below).
+shared `espnow_slave.c`, see "Resolution" below); **PLIP done** (brought back
+into scope on 2026-06-10 — dedicated receiver `src/scenario_now.{h,cpp}` in
+`PLIP_FIRMWARE`, see "PLIP" below).
 
 Spec: `docs/specs/2026-05-24-firmware-scenario-hotload.md`, task 6
 ("Receiver side on each peer").
@@ -108,18 +109,29 @@ SRC entry already present in every puzzle `main/CMakeLists.txt`).
    no-op for it. Confirm per node before adding storage: `p7_coffre` (the
    final-code lock) is the most likely to actually consume a scenario.
 
-## PLIP (`PLIP_FIRMWARE`) — out of scope by design
+## PLIP (`PLIP_FIRMWARE`) — done (re-scoped 2026-06-10)
 
-Resolved 2026-06-09: **PLIP needs no ESP-NOW scenario receiver.** It is its own
-Arduino/PlatformIO tree (`/PLIP_FIRMWARE`, C++), connects to the master purely
-over **Wi-Fi + HTTP** (`network_task.cpp` → `WiFi.begin` / mDNS, `zacus_hook_client`
-REST), and registers **no** `esp_now_register_recv_cb` at all. The ESP-NOW relay
-exists only as a fallback for boards that run with Wi-Fi disabled (battery / RF
-noise); PLIP is mains-powered and always on Wi-Fi.
+Originally resolved out of scope on 2026-06-09 (Wi-Fi/HTTP-only client, no
+ESP-NOW stack). Re-scoped in on 2026-06-10 by explicit request: PLIP now has a
+dedicated receiver, `PLIP_FIRMWARE/src/scenario_now.{h,cpp}` (Arduino C++,
+matching the `zacus_hook_client` worker-task pattern).
 
-If PLIP ever needs hot scenario push, the correct path is the master/box3 HTTP
-one — `POST /game/scenario` over its existing Wi-Fi link — **not** ESP-NOW. No
-code change made.
+- Same wire format as `scenario_mesh` / the shared `espnow_slave.c`:
+  4-byte header `{ seq:u16 LE, total:u16 LE }`, <=236 payload bytes, bounded
+  heap reassembly (<=64 KiB), 5 s sender-silence timeout.
+- PLIP registers no other `esp_now_register_recv_cb`, so the module owns the
+  single callback — no MSG_* demux needed (unlike the puzzle nodes).
+- A completed scenario is persisted to LittleFS at `/scenario.json`
+  (temp-then-rename); an optional `scenario_now_register_callback()` hook lets
+  a future Runtime 3 engine consume it. With no consumer registered the
+  scenario is stored and logged.
+- `network_task.cpp` calls `scenario_now_init()` once the station is up
+  (ESP-NOW rides the AP's channel); the call is idempotent and repeated on
+  reconnect.
+
+The HTTP path (`POST /game/scenario` on PLIP's future REST server) remains the
+recommended push channel once that server lands; the ESP-NOW receiver covers
+the relay/fallback case in the meantime.
 
 ## Shared-protocol drift risk