Refresh docs and reorder roadmap

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

readme.md

@@ -59,8 +59,8 @@ Dashboard — mobile (390 px) and desktop (1280 px):
   trip history with OSM/CARTO live map and route replay, dashcam archive browsing with inline
   video player and Range-request seeking, overview stats dashboard, delete buttons for trips and
   clips, and a device-settings page for editing the synced owner/car/avatar values that the Pi
-  pulls from the server. The portal can register multiple devices, reveal a one-time API key at
-  creation/rotation time, and request a sync for a selected device. When the Pi has
+  pulls from the server. The portal can register/delete multiple devices, reveal a one-time API
+  key at creation/rotation time, and request a sync for a selected device. When the Pi has
   **Sync with server** enabled, those identity changes hot-reload into the running local UI on the
   next successful sync instead of waiting for a manual restart. Shared `history.js` code runs on
   both the Pi and the server — tile source and zoom limits are configured per-deployment via HTML
@@ -71,8 +71,9 @@ Dashboard — mobile (390 px) and desktop (1280 px):
   diagnostics, plus quick actions for server test, sync-now, uplink reconnect, and app restart
 - 🗄️ **Motion-aware local-first SQLite logging** — five-second motion checks without five-second
   parked writes, plus retry-safe remote sync and automatic backoff
-- 🌡️ **Pi health monitoring** — dashboard temperature, RAM, disk space, uptime, and explicit
-  undervoltage/throttling warnings from the Raspberry Pi firmware
+- 🌡️ **Pi health + diagnostics** — a dedicated local Status page shows temperature, RAM, disk,
+  uptime, undervoltage/throttling warnings, service state, uplink/server reachability, GPS state,
+  OBD presence, and safe quick actions
 - 🔔 **Offline-first alerts** — a notification bell on every page reports check-engine state,
   storage pressure, upload backlog, temperature/power faults, and GPS loss while moving. Optional
   ntfy delivery is available but remains disabled until configured
@@ -122,7 +123,14 @@ For the remote server (receives trip logs + dashcam uploads), see [server/README
 
 ## Customizing device identity
 
-The Pi displays a username, car model, and avatar image. All customizable values are stored in `config/device.json` (no code edits needed).
+The Pi displays an owner name, car model, device name, and avatar. You can manage those values in
+two ways:
+
+- **Locally on the Pi** through the Settings page
+- **From the server portal** when **Sync with server** is enabled on the Pi
+
+The local fallback/default source remains [config/device.json](./config/device.json), so the car
+still boots with sensible identity values even when fully offline.
 
 ### Edit device configuration
 
@@ -141,10 +149,10 @@ Edit [config/device.json](./config/device.json):
 |-------|----------|---------|
 | `owner_name` | Top-right of app topbar | Your name/username |
 | `car_model` | Left sidebar (next to car icon) | Vehicle model/year |
-| `device_name` | (Reserved) | Future server-side use in Phase 25.5 |
+| `device_name` | Local settings / remote portal | Device identity used by server sync/provisioning |
 | `avatar_path` | Top-right avatar circle | Profile picture (relative to `static/`) |
 
-After editing, restart the app:
+If you edit the JSON file directly, restart the app:
 
 ```bash
 # If running as a systemd service:
@@ -187,15 +195,26 @@ rm db/sql/quoije_Yaris2013.db
 
 ## Project status
 
-Phases 1–24.7 are complete. The system is fully built and audited, ready for the Phase 25 real-vehicle test:
+The build is now at the endgame stage: the Pi app, remote server, and device-management/sync work
+are implemented and verified on the real Pi/unraid setup. The remaining roadmap phases are the
+temporary real-vehicle acceptance test and the low-priority Android companion.
 
 - **Phases 1–23.5**: core Pi system — GPS, OBD, dashcam, trip history, web UI redesign, WiFi upgrade, cellular fallback, alerts, settings, upload
 - **Phase 24**: remote web portal at `https://yaris.ceaf.dev/` — login-protected, trip history with CARTO live map, dashcam archive, delete, overview stats
 - **Phase 24.5**: full code audit — 6 bugs fixed across Pi modules and server, 63 tests passing
 - **Phase 24.6**: Yaris 2013 OBD compatibility hardening — `_decode_odometer` no longer kills the OBD session on unsupported PIDs, sensor globals reset on reconnect, `OBD_SKIP_VOLTAGE_CHECK` escape hatch for clone ELM327 adapters
 - **Phase 24.7**: diagnostic script (`scripts/diagnose.sh`), map tile switch to CARTO, zoom limit fix
+- **Phase 24.8**: deployment/readme cleanup and uplink interface consistency
+- **Phases 25.5a–25.5d**: offline-first device identity sync, remote portal device settings,
+  Pi-side hot-reload, multi-device provisioning, one-time API key rotation/registration, local
+  Settings UI for remote credentials, Sync now / Test connection, GPS live-status verification,
+  dedicated local Status page, and status-page quick actions
+- **Current known limitation**: the remote portal's device-management page is multi-device, but the
+  main remote overview/history/dashcam browsing views still follow one configured `DEVICE_NAME`
+  until a later portal-wide device selector/filter is added
 
-**Next**: Phase 25 — temporary real-vehicle test in the 2013 Yaris (see PLAN.md for the full acceptance checklist). Phase 26 (Android companion app) follows after that.
+**Next**: Phase 25 — temporary real-vehicle test in the 2013 Yaris (see [PLAN.md](./PLAN.md) for
+the full acceptance checklist). Phase 26 (Android companion app) follows after that.
 
 Phase 14 is partially complete: the Pi's hardware watchdog is deployed and reboot-verified.
 Read-only-root storage hardening is deferred until persistent storage is moved off the SD root
@@ -205,12 +224,12 @@ The browser-based phone relay was removed after real-world testing confirmed tha
 cannot reliably use the Pi's WiFi and cellular data simultaneously. A native Android companion is
 planned later instead (Phase 26).
 
-The local Web UI includes a Settings page for safe runtime configuration: dashcam uploads,
-uploaded-video retention, cellular APN fallback, optional ntfy delivery, and alert thresholds.
-Notification secrets are write-only in the browser API, and network credentials that could lock
-the Pi out remain SSH/file-managed. When cellular is configured, small ntfy notifications use the
-SIM868 first and WiFi/Ethernet only as fallback; that modem path is implemented and mock-tested but
-still needs real-SIM/carrier verification.
+The local web UI includes a Settings page for safe runtime configuration: dashcam uploads,
+uploaded-video retention, cellular APN fallback, optional ntfy delivery, alert thresholds, local
+device identity, and remote server credentials/API key. Notification secrets remain write-only in
+the browser API. When cellular is configured, small ntfy notifications use the SIM868 first and
+WiFi/Ethernet only as fallback; that modem path is implemented and mock-tested but still needs
+real-SIM/carrier verification.
 
 The Pi can also join a configured phone hotspot for outbound internet when no SIM is available,
 including trip synchronization and WiFi dashcam uploads, with automatic recovery to home WiFi or