diff --git a/PLAN.md b/PLAN.md
index 4b13f68..5637d4f 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -729,6 +729,54 @@ all in `modules/app_obd.py` / `modules/app_events.py`:
 - **Add a small connect-time diagnostic log** (ELM327 firmware version + negotiated protocol,
   both available from `python-obd`'s connection object) written once per successful connect -
   useful evidence to sanity-check against Toyota's expected protocol on the very first real test.
+- **Expand the data pulled from the car beyond speed/RPM**, to feed the richer dashboard planned
+  in Phase 17: coolant temperature, fuel level, throttle position, and DTC/MIL status (check-
+  engine light on/off + stored trouble codes, reusing/wiring up the already-scaffolded but
+  currently-empty `/dtc` page and `GET_DTC` command). **Odometer/mileage is not guaranteed** -
+  the standard OBD-II mode 1 PID for total odometer (0xA6) was only added to the SAE J1979 spec
+  in later revisions and is inconsistently supported across manufacturers/years; whether the
+  2013 Yaris's ECU exposes it at all can only be confirmed once tested against the real car
+  (falls under "code hardening only" for now - add the query with graceful "unsupported" handling
+  rather than assuming it will work).
+
+### Phase 16: Complete web UI redesign — PLANNED
+The current `templates/`/`static/` UI is an old, mostly-unmodified admin dashboard template
+(SB Admin 2-style Bootstrap theme) with leftover placeholder cruft never replaced with real
+content - e.g. `index.html`'s "Placeholder button", dropdown menus full of "Action" / "Another
+action" / "Something else here" stub links, and a `/dtc` page that's just an empty "Output" card
+with nothing wired up to it at all. Given how much is changing anyway (phone-relay removal,
+new dashcam/video browsers, richer OBD data), do a proper pass over the whole UI rather than
+keep bolting new cards onto the old template:
+- Replace/remove all placeholder buttons, dropdown menus, and stub links that don't do anything.
+- Real design pass for the new features rather than reusing the generic admin-template card style
+  as-is: the dashcam/video file browsers (Phases 13-14) and the expanded OBD data (Phase 15) all
+  need list/table and status-display patterns that don't really exist in the current template.
+- Wire up the actually-empty `/dtc` page to show real DTC/MIL data once Phase 15 exposes it.
+- Not yet scoped: whether to keep Bootstrap 5 + the current theme framework and just clean it up,
+  or replace the frontend stack entirely. To be decided once the functional phases above land, so
+  the redesign is done once against the final feature set rather than repeatedly against a moving
+  target.
+
+### Phase 17: Native Android companion app — PLANNED (low priority, do last)
+Revives the phone-relay goal (Phase 11/12) properly this time, using a real native app instead of
+a web page - the only way to actually hold a WiFi connection to the Pi's hotspot and a cellular
+connection to the internet open simultaneously (`ConnectivityManager.bindProcessToNetwork()`,
+unavailable to browser JS - see the Phase 11 update). Explicitly **not urgent** - deprioritized to
+the end of the roadmap, after all web-side work (Phases 12-16) is done. Scope, at a high level
+(not yet designed in detail):
+- **Dashcam file transfer**: browse/select/delete dashcam clips already imported to the Pi (same
+  data as the Phase 14 local video browser, just a native client instead of/alongside the web UI),
+  download them to the phone, and upload to the remote server over cellular while the phone stays
+  on the Pi's hotspot for the download leg - the true simultaneous dual-network relay the web
+  version could never deliver.
+- **Trip/location info**: surface live GPS position, speed, and trip history pulled from the Pi
+  while connected to its hotspot (reusing the existing `/api/gps`-style data feeds), so the app is
+  useful as a real "check on the car" companion, not just a file-transfer tool.
+- Not yet scoped: distribution (sideload vs Play Store), whether it talks to the Pi directly over
+  the hotspot only or also to the remote server directly for trip history when away from the car,
+  and how much of the existing REST API surface can be reused as-is vs needs new
+  mobile-friendly endpoints. To be designed once Phases 12-16 (web-side cleanup + hardening +
+  redesign) are done.
 
 ## Working Notes / Environment Gotchas