From 0540a1a8ebf83acb5e112bf6a8dfe4d146500fc3 Mon Sep 17 00:00:00 2001 From: Mathieu Moran Date: Sun, 9 Aug 2026 17:53:17 -0400 Subject: [PATCH] Reorder roadmap phases by execution Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- PLAN.md | 193 ++++++++++++++++++++++++++++---------------------------- 1 file changed, 98 insertions(+), 95 deletions(-) diff --git a/PLAN.md b/PLAN.md index e5ddd41..80fe686 100644 --- a/PLAN.md +++ b/PLAN.md @@ -676,90 +676,15 @@ returns HTTP 200 with no "relay" text over the real network) and the remote serv 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). -**Update 2026-08-09**: Phase 17 (OBD hardening) was completed next; see its section below. -Phase 14 is the recommended next software phase because Phases 15/16 and the later list-based -features depend on its shared UI foundation. Phase 13 remains independent but requires a careful +**Update 2026-08-09**: Phase 13 (OBD hardening) was completed next; see its section below. +Phase 15 is the recommended next software phase because Phases 16/17 and the later list-based +features depend on its shared UI foundation. Phase 14 remains independent but requires a careful hardware/filesystem deployment pass rather than ordinary application deployment. -### Phase 13: Power-loss resilience & watchdog — 🚧 PLANNED -**New phase, not code-dependent on anything else — OS/hardware-level, can be done anytime, -ideally before the Pi lives in the car full-time.** A car cuts power abruptly at every key-off; -nothing in the project currently protects against that, and repeated unclean power loss is a -classic cause of SD card corruption on embedded Pi projects. Two complementary angles: -- **Filesystem hardening**: convert the Pi's root filesystem to read-only with a writable overlay - (`overlayroot`/`raspi-config`'s built-in overlay FS option), so an abrupt power cut can no longer - corrupt the OS itself. App data that must persist (`db/sql/`, `dash/videos/`, logs) needs to - live on an explicitly writable partition/bind-mount carved out of the overlay, since those - still need real writes. -- **Clean shutdown before power loss**: either (a) a small delayed-shutdown power module/circuit - (holds 5V for a few seconds after ignition-off so the Pi can run `shutdown -h now` cleanly), or - (b) if the SIM868 HAT or another ADC/GPIO source can sense ignition/voltage state, a software - voltage-drop watcher that triggers a clean shutdown proactively. Exact approach TBD - depends - on what's easiest to wire into the existing power setup. -- **Hardware watchdog**: enable the Pi's built-in `bcm2835_wdt` watchdog (via `systemd`'s - `RuntimeWatchdogSec`/`watchdog-device` support) so a fully hung app or kernel gets a hard reboot - automatically instead of sitting dead in the car until someone notices. - -### Phase 14: UI design-system foundation — 🚧 PLANNED -**New phase, pulled forward from the old "do the whole redesign at the end" plan.** Building the -Phase 15/16 file browsers (and later the trip-history/Pi-health/settings pages) against the -current old admin-template style just means rebuilding the same UI twice once the full redesign -(Phase 22) happens. Instead, do a *small, scoped* slice of the redesign right now: a shared page -layout/shell plus one reusable list/table component (sortable columns, per-row action buttons, -delete-with-confirmation pattern, empty-state messaging) that every subsequent list-based feature -in this plan (dashcam browser, video browser, trip history, settings) can be built on directly, -instead of writing bespoke list/delete UI code from scratch each time. Not a full redesign of -every existing page yet - just establishes the pattern once so nothing built after this point -needs to be redone in Phase 22. - -### Phase 15: Dashcam USB file browser (list + delete) — 🚧 PLANNED -Replace the current all-or-nothing "Import videos" flow's blind spot (no visibility into what's -actually on the camera) with a real file browser for the mounted USB dashcam device, built on the -Phase 14 shared list component: -- New endpoint(s) in `modules/app_dash.py` to list every video file on the mounted dashcam - (relative path, size, modified time) without copying anything - reuses the existing - `find_video_files()` walk, pointed at the dashcam's mount point instead of the local - destination folder. -- Delete support: individual file delete and a "delete all" bulk action, each requiring the - mount to be briefly remounted read-write (currently always `ro`) - only for the duration of - the delete call, then back to read-only (or unmounted) afterward, to minimize risk of - filesystem corruption from an unclean power loss while writable. -- UI: a `/dash` card showing total file count + total size on the dashcam, a scrollable file - list with a delete button per row, a "Delete all" button behind a confirmation dialog (real - data loss risk - no undo). -- Explicitly deferred/out of scope: no in-browser preview/playback of files still on the - dashcam itself (only after import - see Phase 16). No changes to the USB - select-mode/data-communication toggle behavior - the user replugs power manually to return the - camera to recording mode, as they already do. - -### Phase 16: Local imported-video browser + player — 🚧 PLANNED -Same file-browser treatment for videos already imported to the Pi's own disk -(`dash/videos/`, populated by `import_dashcam()`), built on the Phase 14 shared list component: -- List endpoint (reuses `find_video_files()` against `app_dash.DEFAULT_DESTINATION`) showing - relative path, size, modified time, and upload status (cross-check against - `app_sql.dashcam_file_marked_uploaded()` - so it's visible at a glance which imported clips - have already reached the remote server and which are still pending the Pi's own background - uploader). -- Delete support: **local Pi copy only** - remote server copies are intentionally left alone - as the safe backup/archive (explicit user decision - see 2026-08-09 discussion). No - "also delete from server" option is being built for now. -- In-browser video player: since the dashcam records **MP4** (confirmed with the user), this - is a plain HTML5 `