diff --git a/PLAN.md b/PLAN.md
index 893d6e3..2a484ed 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -669,8 +669,30 @@ tested by actually importing `app.py` in a scratch venv and hitting it with Flas
 app imports cleanly (GPS/OBD/SQL/upload startup all log their normal "no hardware" messages, no
 crash), `app.url_map` confirms every relay route is gone while `/`, `/dash`, `/dtc`, and the
 remaining dashcam/upload API routes are still registered, and both `/` and `/dash` render with
-HTTP 200 (`/dash`'s HTML contains zero occurrences of "relay").
+HTTP 200 (`/dash`'s HTML contains zero occurrences of "relay"). Deployed to both the Pi
+(`git pull --ff-only` + `systemctl restart yaris-obd.service`, confirmed `active` and `/dash`
+returns HTTP 200 with no "relay" text over the real network) and the remote server (needed a full
+`docker compose build api && docker compose up -d api` on unraid, not just a restart, since the
+CORS-hook removal is baked into the image at build time - confirmed `/health` still returns
+`{"status":"ok"}` and the response no longer carries any `Access-Control-*` header).
 
+**Handoff note for next session (2026-08-09, end of session)**: Phase 12 is fully done/deployed/
+verified as described above - nothing left to do there. Work had just started on **Phase 17 (OBD
+hardening)** next - picked because it's pure Python with zero risk to the Pi's live filesystem,
+in contrast to Phase 13's overlay-FS work which is riskier and deserves its own careful pass.
+**No code was written for Phase 17 yet** - only read `modules/app_events.py` (confirms
+`app_obd.obd_connection()` is only called from the Socket.IO `connect` handler, exactly as
+previously noted) and `modules/app_gps.py` (to use its `_poll_loop()`/`start_gps()` background-
+thread pattern as the template for OBD's new reconnect loop - lock+while-True+`time.sleep`,
+daemon thread, idempotent `start_*()` guard against double-starting). A `pip install obd` on the
+dev machine to inspect `python-obd`'s actual API (for DTC codes, ELM327 version/protocol
+attributes, exception types) was attempted but interrupted by a tool permission prompt before
+producing any output - **this still needs to be done** (or just read the `python-obd` source
+directly, e.g. via `pip download`/GitHub) before writing the DTC/diagnostics/protocol-override
+parts of Phase 17, to get exact attribute/method names right (e.g. `connection.protocol_name()`,
+`obd.commands.GET_DTC`, whatever `python-obd`'s actual exception class is called) rather than
+guessing. Phases 13 and 14 (UI foundation) are also fully ready to start (no blocking deps) if
+picking a different phase first makes more sense than continuing Phase 17.
 
 ### Phase 13: Power-loss resilience & watchdog — 🚧 PLANNED
 **New phase, not code-dependent on anything else — OS/hardware-level, can be done anytime,