From 90cfd7bd04911189e2ca1d64ee4de99f8450e643 Mon Sep 17 00:00:00 2001
From: Mathieu Moran <mathieumoran1@gmail.com>
Date: Fri, 14 Aug 2026 23:04:42 -0400
Subject: [PATCH] docs: close BUG-22 (smoothed GPS max verified)

---
 BUGS.md | 25 +++++++++++++------------
 PLAN.md |  7 ++++---
 2 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/BUGS.md b/BUGS.md
index 46bd273..e93eee6 100644
--- a/BUGS.md
+++ b/BUGS.md
@@ -24,22 +24,23 @@ When CLOSED, move the entire entry to Resolved — don't duplicate.
   fills the cards immediately on load (and every 15 s) via REST. Needs in-car
   verification.
 
-### BUG-22 — Trip max speed ignores GPS-only stretch (shows OBD max only)
-- **Status**: `OPEN` 2026-08-14
-- **Phase**: 29
-- **Symptom**: trip #9 shows "max 111.0 km/h" but the replay scrubber shows "GPS: 135.6 km/h"
-  at 6:26 p.m. — the top speed reached during the OBD dropout isn't reflected in the trip max.
-- **Cause**: `max_speed_kmh` was computed from OBD speeds only (`max(obd_speeds or segment_speeds)`
-  on the Pi, `max(speeds)` on the server). When a trip has any OBD speed at all, the GPS-only
-  stretch is ignored for the max. The replay already shows GPS-derived speed for that stretch
-  (BUG-21 fallback), so the scrubber shows a higher speed than the stored max.
-- **Fix**: union OBD + GPS-derived segment speeds when computing the max, on both the Pi
-  (`build_trip_summaries`) and the server (`compute_trips_for_device`).
-
 ---
 
 ## Resolved
 
+### BUG-22 — Trip max speed ignores GPS-only stretch (shows OBD max only)
+- **Status**: `CLOSED` 2026-08-14
+- **Commit**: `PENDING`
+- **Fix**: `max_speed_kmh` was computed from OBD speeds only, so the top speed reached during
+  the 20-min OBD dropout wasn't reflected. Both trip builders now union OBD speeds with
+  GPS-derived speeds computed over a trailing ~30s window (`GPS_SPEED_WINDOW=6`) to average out
+  GPS position jitter — raw 5s segments swing wildly (e.g. 58→141→58 km/h, peaks ~162), so an
+  unsmoothed union overshoots the real top speed. Also bumped `TRIP_BUILD_VERSION` to force a
+  Pi-side trip rebuild.
+- **Verification**: trip #9 max went 111 (OBD-only) → 162 (raw union) → **119** (smoothed), and
+  trip #8 → **127.8**, identical on the server and the Pi. The 135.6 the scrubber showed was a
+  single noisy 5s GPS sample, not the sustained top speed.
+
 ### BUG-21 — OBD speed drops out mid-drive, replay shows 0 km/h (GPS-only)
 - **Status**: `CLOSED` 2026-08-14
 - **Commit**: `7c8f27b`
diff --git a/PLAN.md b/PLAN.md
index f090fbb..d6cc114 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -2286,9 +2286,10 @@ logged as `BUG-XX` entries in [BUGS.md](./BUGS.md) (BUG-16 onward) and fixed + v
   on 2026-08-13 (22:23:50→22:43:41 UTC). Fixed: server `get_trip_route()` mirrors the Pi's
   GPS-speed fallback (derives speed from consecutive GPS points when OBD speed is missing), so
   the portal replay no longer flatlines at 0 km/h. Follow-up: OBD reconnect on stalled reads.
-- **BUG-22 (trip max ignores GPS-only stretch) — 🚧 IN PROGRESS**: `max_speed_kmh` used OBD speeds
-  only, so the top speed during the OBD dropout (e.g. 135 GPS) wasn't reflected. Fix: union OBD +
-  GPS-derived segment speeds in the max on both Pi + server.
+- **BUG-22 (trip max ignores GPS-only stretch) — ✅ FIXED**: `max_speed_kmh` used OBD speeds
+  only. Fixed: union OBD + GPS-derived speeds with a trailing ~30s window (`GPS_SPEED_WINDOW=6`)
+  to smooth GPS jitter, on both Pi + server; bumped `TRIP_BUILD_VERSION` for a Pi rebuild.
+  Trip #9 max 111 → 119, trip #8 → 127.8 (server + Pi agree).
 
 Open items from the drive — fill in as reported:
 - (none clock-related — BUG-17/BUG-18 closed 2026-08-14).