Plan remote trip portal

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

PLAN.md

@@ -1093,12 +1093,46 @@ remaining cleanup once all the functional phases above have landed:
   framework rewrite would add deployment weight and offline assets on the Pi without improving
   the tracker features, and would discard the foundation deliberately built before Phases 16-21.
 
-### Phase 23: Native Android companion app — 🚧 PLANNED (low priority, do last)
+### Phase 23: Remote trip portal with shared web UI — 🚧 PLANNED
+**Added 2026-08-09; intentionally scheduled after Phase 22.** Phase 22 first establishes the final
+visual language and complete in-car interface. Building the remote portal afterward avoids
+duplicating the current unfinished theme and lets both deployments deliberately share the same
+finished shell, components, trip list, route map, timeline replay, units, and responsive behavior.
+
+Extend the existing self-hosted `server/` deployment from an upload-only API into a secure remote
+web portal backed by its Postgres tracking data, so trip history and all recorded trip details can
+be viewed away from the car:
+- Add server-side trip boundary/index data equivalent to Phase 18, generated from uploaded tracking
+  points without changing or deleting the raw records. Expose trip summaries, full/downsampled
+  routes, timestamps, distance in km/mi, average/max speed in km/h and mph, and timeline replay.
+- Reuse the redesigned Phase 22 Jinja/Bootstrap UI rather than creating a visually separate app.
+  Extract/share presentation assets where practical so local and remote pages do not drift, while
+  keeping their data providers and available actions explicit.
+- Put an always-visible environment indicator in the shared shell: **In-car / Local Pi** on
+  `yaris.local`, and **Remote server** on the hosted portal. Page title, navigation, and status
+  styling must also make the context unambiguous so the user cannot mistake remote historical data
+  for a live connection to the car.
+- The remote portal is primarily historical/read-only. Hardware-only actions (physical dashcam
+  mount/delete/import, live OBD/GPS state, Pi settings) must be hidden, disabled with a clear
+  explanation, or replaced by their remote equivalent rather than appearing to control the car.
+  Uploaded dashcam archive browsing can be included if it reuses the existing server storage
+  safely, but trip detail/replay is the required first scope.
+- Add real human-user authentication and secure sessions for the internet-facing UI. Existing
+  device `X-Device-Name`/`X-Api-Key` upload authentication remains separate and must not become a
+  browser login mechanism. Preserve Cloudflare Tunnel compatibility and do not expose secrets in
+  HTML/JavaScript.
+- Support selecting a vehicle/device if more than one is registered later, while defaulting
+  cleanly to the current Yaris. Keep trip APIs scoped to the authenticated user/device.
+- Deploy only after Phase 22 is complete: rebuild the unraid Docker stack, verify migrations against
+  copied data first, compare remote trip calculations with uploaded Pi records, and browser-test
+  desktop/mobile through the real hosted endpoint before committing.
+
+### Phase 24: 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-22) is done. Scope, at a high level
+the end of the roadmap, after all web-side work (Phases 12-23) 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 17 local video browser, just a native client instead of/alongside the web UI),
@@ -1111,8 +1145,8 @@ the end of the roadmap, after all web-side work (Phases 12-22) is done. Scope, a
 - 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-22 (web-side cleanup + hardening +
+  mobile-friendly endpoints. To be designed once Phases 12-23 (web-side cleanup + hardening,
-  redesign) are done.
+  redesign, and remote portal) are done.
 
 ## Working Notes / Environment Gotchas
 

readme.md

@@ -114,6 +114,8 @@ partition, and clean shutdown still needs delayed-power or ignition-sense hardwa
 
 The browser-based phone relay was removed after real-world testing confirmed that mobile browsers
 cannot reliably use the Pi's WiFi and cellular data simultaneously. A native Android companion is
-planned later instead. The next roadmap work is settings, followed by a final UI polish pass. Full
+planned later instead. The next roadmap work is settings, followed by a final UI polish pass.
-phase history, verification notes, and current scope live in
+After the redesign, the same interface will become a secure remote trip portal backed by the
+self-hosted server, with clear Local Pi/Remote Server labeling. Full phase history, verification
+notes, and current scope live in
 [PLAN.md](./PLAN.md).