Document dashcam browser completion

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

PLAN.md

@@ -809,7 +809,7 @@ needs to be redone in Phase 22.
   overflow; injected sample rows confirmed ascending sort, `aria-sort`, empty-state switching,
   and cancellation of a destructive handler.
 
-### Phase 16: Dashcam USB file browser (list + delete) — 🚧 PLANNED
+### Phase 16: Dashcam USB file browser (list + delete) — ✅ DONE
 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 15 shared list component:
@@ -829,6 +829,25 @@ Phase 15 shared list component:
   select-mode/data-communication toggle behavior - the user replugs power manually to return the
   camera to recording mode, as they already do.
 
+**Implemented 2026-08-09**:
+- Added list, single-delete, and delete-all backend operations using the existing USB-only storage
+  detection. Each list/import/delete operation shares one lock so mount and file operations cannot
+  race; listings include relative path, byte size, modified timestamp, count, and total size.
+- Deletes accept only recognized video extensions, resolve and re-check every target beneath the
+  selected mount, and reject absolute paths, traversal, missing files, and symlink escapes.
+- Delete operations mount or remount the dashcam read-write only for the operation, then unmount
+  or restore it read-only. If unmount fails, the cleanup path immediately attempts a read-only
+  remount and reports a cleanup failure if neither safety action succeeds.
+- Added `/api/dash/files` and `/api/dash/file` routes plus a `/dash` browser built on Phase 15's
+  shared component: file/size/time sorting, totals, refresh, per-row confirmed delete, confirmed
+  delete-all, empty/no-device states, and error feedback.
+- Verified metadata, traversal rejection, one/all deletion, non-video preservation, import
+  regression behavior, and cleanup-failure reporting against temporary filesystem fixtures.
+  Deployed to the Pi; the live API correctly returned no storage devices while ignoring the
+  attached PL2303 OBD adapter, and the responsive browser UI passed no-device and mocked populated
+  list/sort/confirmation/delete tests. Actual deletion from the physical dashcam remains a
+  hardware verification item for the next time it is connected in USB storage mode.
+
 ### Phase 17: 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 15 shared list component:

readme.md

@@ -42,7 +42,8 @@ i have a dream
   port number)
 - 🎥 **Dashcam file retrieval** — detects a USB dashcam automatically (any brand/folder layout,
   no hardcoded device path), mounts it read-only, and safely copies footage locally. Verified
-  against a real 28GB/87-file import
+  against a real 28GB/87-file import. The web UI can also browse, sort, and delete individual or
+  all videos directly from the connected dashcam with confirmed, temporary read-write operations
 - ☁️ **Remote upload** — a self-hosted server (Flask + Postgres, `server/`) receives trip/GPS
   logs and dashcam footage over the internet (via Cloudflare Tunnel or a plain port-forward).
   Dashcam videos upload in resumable 40MB chunks (works around tunnel body-size limits and keeps
@@ -87,7 +88,7 @@ For the remote server (receives trip logs + dashcam uploads), see [server/README
 
 ## Project status
 
-This project was revived after a couple of years on the shelf. Phases 1-13 and 15 are complete:
+This project was revived after a couple of years on the shelf. Phases 1-13 and 15-16 are complete:
 real GNSS, hardened OBD support, offline maps/UI, automatic WiFi hotspot switching, local logging,
 dashcam import, resumable remote upload, deployment, and the shared UI foundation are implemented.
 The pipeline has been exercised on the real Pi and dashcam, including a complete 28GB import and
@@ -99,6 +100,6 @@ 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 the dashcam/local-video browsers, followed by trip
-history, Pi health, alerts, settings, and a final UI polish pass. Full phase history, verification
-notes, and current scope live in [PLAN.md](./PLAN.md).
+planned later instead. The next roadmap work is the local imported-video browser/player, followed by trip history, Pi
+health, alerts, settings, and a final UI polish pass. Full phase history, verification notes, and
+current scope live in [PLAN.md](./PLAN.md).