diff --git a/PLAN.md b/PLAN.md index 5e5cca7..e1b9d7a 100644 --- a/PLAN.md +++ b/PLAN.md @@ -1093,30 +1093,38 @@ 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: Remote trip portal with shared web UI — 🚧 PLANNED +### Phase 23: Remote trip + dashcam 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. +finished shell, components, trip list, route map, timeline replay, dashcam library, 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: +web portal backed by its Postgres tracking data and uploaded dashcam archive, so trip history, +recorded trip details, and footage can be accessed 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. +- Make the uploaded dashcam archive a required first-class remote page, matching the redesigned + in-car imported-video library: sortable/searchable file list, relative path, size, timestamp, + thumbnails, inline H.264 playback with Range/seeking support, and an explicit download action for + individual original files. Downloads must stream from server storage with safe + `Content-Disposition`, bounded/traversal-safe paths, and no whole-video memory buffering. Remote + deletion is not included unless it is designed later with separate safeguards; the server remains + the archive/backup. - 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. +- The remote portal is historical/read-only. It should feel like the same product, but render only + server-relevant navigation and data—not redacted/empty imitations of unavailable hardware. + Physical dashcam mount/import/delete, live OBD/GPS, cellular status/configuration, Pi health, and + local Pi settings are omitted entirely. Trip history/replay and the uploaded dashcam archive are + the required remote 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 @@ -1124,7 +1132,8 @@ be viewed away from the car: - 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 + copied data first, compare remote trip calculations with uploaded Pi records, verify playback, + Range requests, and downloads against disposable copies of real server footage, and browser-test desktop/mobile through the real hosted endpoint before committing. ### Phase 24: Native Android companion app — 🚧 PLANNED (low priority, do last) diff --git a/readme.md b/readme.md index 1be2f75..5faba19 100644 --- a/readme.md +++ b/readme.md @@ -116,6 +116,7 @@ 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. The next roadmap work is settings, followed by a final UI polish pass. 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 +self-hosted server, including trip replay and browsing/playing/downloading archived dashcam videos, +with clear Local Pi/Remote Server labeling and hardware-only Pi sections omitted remotely. Full +phase history, verification notes, and current scope live in [PLAN.md](./PLAN.md).