Document Phase 12 deployment + handoff note for next session

Recorded Phase 12's deployment step (Pi restart + unraid server
docker compose build/up since server/app.py's CORS removal is baked
into the image at build time - a plain restart wouldn't pick it up)
and its verification (both confirmed on real infrastructure: Pi's
/dash returns HTTP 200 with no relay text, server's /health has no
Access-Control-* headers anymore).

Added a handoff note for whoever picks this up next: Phase 17 (OBD
hardening) was the next phase in progress, but no code was written
yet - only read app_events.py/app_gps.py for context and started
(but didn't finish, due to a tool permission interruption) installing
the python-obd package locally to check its actual API surface
before writing the DTC/protocol/diagnostics code. Reset that todo
back to pending to reflect no actual progress was made. Phases 13
and 14 are equally ready to start (no blocking deps) if a different
starting point makes more sense.

Co-authored-by: Copilot <[email protected]>

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,