docs: add features.md tracker with odometer-fallback idea

features.md

@@ -0,0 +1,68 @@
+# yaris-obd Feature Requests
+
+Ideas and requests for **new features** (distinct from bugs, which belong in `BUGS.md`, and the
+phase-by-phase implementation history in `PLAN.md`). Use this file to record anything that should
+be built eventually but isn't an active roadmap phase yet. When a feature gets picked up, create a
+dedicated PLAN.md phase (or fold it into the relevant existing work) and mark it here.
+
+## How to use this file
+
+- **One `## FEAT-XX` section per idea.** Keep numbering sequential.
+- **Status field**: `IDEA` (brainstormed, not planned) → `PLANNED` (has an assigned phase) →
+  `IN PROGRESS` → `SHIPPED` (deployed + verified) or `WONTFIX`/`SUPERSEDED` as appropriate.
+- **Relate to roadmap**: when a feature lands in a phase, note the phase here and drop a link back
+  here from PLAN.md so the two stay in sync.
+- **Keep each entry small and one-idea-per-entry** so it's easy to pick up and scope.
+
+---
+
+## Feature ideas
+
+### FEAT-01 — Parallel/concurrent chunked dashcam uploads
+- **Status**: `IDEA`
+- **Area**: `modules/app_upload.py` (Pi upload client)
+- **Phase**: n/a
+- **Requested**: noted in Phase 10 of PLAN.md as a possible future optimization; not yet requested
+  explicitly by the owner.
+- **Idea**: upload multiple dashcam chunks (and/or multiple files) concurrently instead of the
+  current strictly sequential one-chunk-then-one-file at a time. Would speed up the multi-hour
+  full-backlog drain of a large local dashcam archive, at the cost of more complexity (bounded
+  concurrency, per-file state, failure handling for the individual concurrent workers).
+- **Outstanding considerations**: memory budget on the Pi (~900MB, no swap — must stay streaming),
+  and whether the sequential pace is actually annoying enough in practice to justify the added
+  complexity.
+
+### FEAT-02 — QR / claim-code device pairing flow
+- **Status**: `IDEA`
+- **Area**: server device provisioning + Pi credential setup (Phase 25.5c)
+- **Phase**: n/a
+- **Requested**: discussed in Phase 25.5c as a possible follow-up to the manual copy/paste API-key
+  provisioning.
+- **Idea**: zero-manual-copy provisioning of `YARIS_SERVER_URL` / `YARIS_DEVICE_NAME` /
+  `YARIS_API_KEY` onto the Pi — e.g. the portal shows a short-lived claim code / QR that the Pi
+  app (or owner) enters/scans once to adopt the device, instead of typing credentials by hand.
+- **Outstanding considerations**: bigger scope than the current copy/paste flow; ship copy/paste
+  first, add pairing only if provisioning still feels annoying.
+
+### FEAT-03 — Manual start odometer fallback when OBD odometer is unavailable
+- **Status**: `IDEA`
+- **Area**: Settings page / odometer display (Pi `app_settings`, `/api/stats`, trip odometer)
+- **Phase**: n/a
+- **Requested**: owner — the 2013 Yaris's ECU is (as expected) NOT exposing OBD PID 0xA6
+  odometer (see Phase 24.6), so the odometer reads nothing.
+- **Idea**: allow the owner to enter the vehicle's current odometer reading once in the Settings
+  page; the app then computes a rolling odometer by adding subsequent trip distances
+  (from `trips` table cumulative distance) to that entered baseline, instead of relying on the
+  unavailable OBD odometer PID.
+- **Outstanding considerations**: what happens when the user's entered value comes from the car's
+  instrument cluster vs the OBD one being absent — this would be the *only* odometer source in
+  that case; needs a clear "this is a manual baseline" indicator in the UI so it's not mistaken
+  for a live OBD reading; decide whether it should also sync to the remote device config
+  (Phase 25.5) or stay local.
+
+---
+
+## Ideas that landed
+
+(No entries yet — shipped features land here. Keep the original idea text intact and add the
+shipped phase/date.)