Plan final Yaris acceptance test

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

PLAN.md

@@ -1136,13 +1136,83 @@ recorded trip details, and footage can be accessed away from the car:
   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)
+### Phase 24: Yaris 2013 in-car acceptance test — 🚧 PLANNED (core-system gate)
+**Added 2026-08-09; intentionally immediately before the Android app.** Bench tests, synthetic
+routes, attached-hardware tests, and stationary Pi runs cannot prove the complete system works
+while installed in and powered by the actual 2013 Toyota Yaris. This phase is the acceptance gate
+for the complete core Pi/web/server system after Phase 23. It is verification and targeted
+correction—not another redesign—and the core vehicle system is not considered ready until the
+results are recorded here.
+
+Prepare before driving:
+- Install the Pi, SIM868 HAT/antennas, USB OBD adapter, dashcam connection, and final intended
+  in-car power source/cabling securely. Resolve the Phase 19/20 undervoltage/throttling warning
+  first; confirm `vcgencmd get_throttled` shows no current power fault at idle and under load.
+- Back up the Pi SQLite database and record baseline row/trip/video/upload counts on the Pi and
+  remote server. Use a uniquely timestamped test window so generated records can be reconciled
+  without deleting unrelated history.
+- Verify the service, watchdog, storage mounts, hotspot, `http://yaris.local/`, alert engine, GPS
+  antenna view, dashcam recording mode, free space, and remote server health before moving.
+- Use a second person for UI/log observations while the vehicle is moving, or record diagnostics
+  for review afterward. The driver must not operate or troubleshoot the UI while driving.
+
+Run a controlled route containing ignition-off/on, stationary idle, low-speed streets, normal road
+speed, several complete stops, turns, a short GPS-obstructed segment if safely available, and a
+clean trip end:
+- **OBD/ECU:** confirm the ELM327 reaches `CAR_CONNECTED`, record negotiated Toyota protocol and
+  adapter firmware, and verify real speed/RPM/coolant/fuel/throttle/MIL/DTC values. Compare wheel
+  speed against the instrument cluster at several safe speeds. Record unsupported PIDs (especially
+  odometer PID A6) as capabilities, not failures, and verify reconnect after ignition cycling and a
+  deliberate USB disconnect/reconnect.
+- **GPS and motion logging:** confirm fixes while stationary and moving, route coordinates on the
+  offline map, OBD-speed-first motion detection, GPS displacement fallback when OBD is deliberately
+  unavailable, one-minute idle heartbeat behavior, and no false trip from stationary GPS drift.
+- **Trip boundary/replay:** after the inactivity timeout, verify exactly one trip (or the expected
+  number for deliberate ignition gaps), correct start/end time and coordinates, plausible
+  distance/average/max speed, km/mi and km/h/mph values, route polyline, start/end markers, timeline
+  scrubber, play/pause marker position, and stopped portions of the route.
+- **Local web UI:** test the final Phase 22 interface on the actual phone over the Pi hotspot at
+  `http://yaris.local/`; verify the explicit **In-car / Local Pi** identity, dashboard telemetry,
+  DTC page, trip history, dashcam library, settings, alerts, responsive layout, reconnect behavior,
+  and no new browser console/API errors.
+- **Dashcam workflow:** create a known short real clip, switch the camera safely into USB storage
+  mode, detect/list it without confusing the OBD adapter, import only that selected file, verify
+  thumbnail/playback/Range seeking, preserve the source until checks finish, and confirm the camera
+  returns to recording afterward. Test deletion only with the disposable clip.
+- **Alerts:** safely exercise conditions that can be simulated without damaging hardware (upload
+  backlog, temporary GPS loss while OBD reports motion, and disposable threshold overrides).
+  Confirm local bell transition/recovery/cooldown behavior. Do not intentionally overheat,
+  undervolt, fill storage, or trigger a real MIL. Verify ntfy only if it has been configured by then.
+- **Power/reliability:** perform multiple normal ignition/power cycles, confirm automatic boot,
+  service/watchdog startup, SIM868 power-on, OBD/GPS recovery, no SQLite corruption, and no current
+  undervoltage/throttling. The deferred Phase 14 clean-shutdown limitation must be explicitly
+  accepted or resolved with delayed-power/ignition-sense hardware before calling this production
+  ready.
+
+Verify the complete remote path after connectivity returns:
+- Confirm every test-window tracking row uploads exactly once and the selected dashcam clip resumes
+  or completes without corruption; compare counts, timestamps, hashes, and byte sizes locally and
+  remotely.
+- On the Phase 23 portal, verify the explicit **Remote server** identity, authenticated
+  vehicle-scoped trip summary/replay, route and timeline agreement with the local Pi, archived clip
+  thumbnail/playback/Range seeking/download, and absence of local-only OBD/cellular/Pi controls.
+- The Android companion is intentionally outside this core acceptance gate and remains the final,
+  low-priority Phase 25. Its own hotspot/cellular binding, trip display, and disposable clip relay
+  require separate real-phone/in-car acceptance when that phase is implemented.
+
+Acceptance requires a written result for every item, captured negotiated protocol/PID support,
+measured trip/count/hash comparisons, relevant logs/screenshots, no unexplained tracebacks or data
+loss, and cleanup of every disposable record/file while preserving the real drive. Any defect found
+must be fixed, redeployed uncommitted, and the affected in-car test repeated before the final commit
+and production-ready sign-off.
+
+### Phase 25: Native Android companion app — 🚧 PLANNED (low priority, always 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
+unavailable to browser JS - see the Phase 11 update). Explicitly **not urgent** and intentionally
-the end of the roadmap, after all web-side work (Phases 12-23) is done. Scope, at a high level
+kept at the end of the roadmap, after all web/server work and the Phase 24 core in-car acceptance
-(not yet designed in detail):
+test are 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),
   download them to the phone, and upload to the remote server over cellular while the phone stays
@@ -1154,8 +1224,8 @@ the end of the roadmap, after all web-side work (Phases 12-23) 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-23 (web-side cleanup + hardening,
+  mobile-friendly endpoints. To be designed once Phases 12-24 (web-side cleanup + hardening,
-  redesign, and remote portal) are done.
+  redesign, remote portal, and core in-car acceptance) are done.
 
 ## Working Notes / Environment Gotchas
 

readme.md

@@ -120,3 +120,6 @@ self-hosted server, including trip replay and browsing/playing/downloading archi
 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).
+
+A dedicated real-vehicle acceptance test in the 2013 Yaris precedes the final low-priority Android
+phase; bench and synthetic verification alone are not treated as core-system production sign-off.