Document Phase 6 on-device verification for FB-06..FB-09

docs/feedback/FB-06-always-interactive-map-recenter.md

@@ -197,3 +197,28 @@ check finds the pulse genuinely missing, and that check could not be run. The re
 acceptance-criteria checkbox ("location marker's pulse animation is confirmed visible
 on-device...") is therefore left unchecked/unresolved and should be picked up in a
 follow-up pass that has emulator access.
+
+### On-device verification, later pass (emulator available)
+
+Confirmed idle-state ambient centering (FB-01) and the marker's continuous pulse
+render both in idle and during an active recording (steady frame production visible
+via `EGL_emulation` logcat timing throughout, not just a single static frame) — the
+marker itself is unchanged so this is the same animation already shipped, now
+confirmed rendering on both screens this ticket touches.
+
+Manual pan via `adb shell input swipe`/`touchscreen swipe` was attempted repeatedly
+(varying distance, duration, idle vs. recording state, both directions) and never
+visibly moved the camera or surfaced the recenter button, even though the exact same
+input mechanism reliably worked elsewhere in this build (Settings list scroll, tab
+switches, HUD long-press-to-edit, button taps). Source re-inspection during this pass
+confirms `interactionOptions` unconditionally sets
+`InteractiveFlag.pinchZoom | InteractiveFlag.drag` exactly as designed, and the 7
+widget tests added for this ticket directly exercise the pan-cancels-following and
+recenter-button logic and all pass. Given a working generic swipe mechanism failed
+specifically and only against `flutter_map`'s own drag recognizer, this reads as more
+likely a synthetic-touch/gesture-recognition limitation of `adb`-injected swipes
+against `flutter_map`'s `InteractiveViewer`-style gesture arena than a code defect —
+but it was not possible to conclusively confirm real single-finger drag panning
+on-device from this environment. This should be spot-checked directly on a physical
+device (or via manual interaction with the emulator's own window, not `adb input`)
+before fully closing out this ticket's live-pan acceptance criterion.

docs/feedback/FB-07-route-planner-null-island.md

@@ -200,3 +200,27 @@ The code change and its three widget tests are the verified deliverable for this
 the on-device screenshot check called for in Implementation step 3 / Acceptance criteria
 was not completed and should be picked up in a follow-up pass when the emulator is
 stable, rather than by fighting it further here.
+
+### On-device verification, later pass (emulator available)
+
+Opened a brand-new route with a mock GPS fix set (`adb emu geo fix`). Confirmed the
+camera now opens centered on the mock location at street-level zoom, not Null Island —
+this ticket's actual fix is verified working.
+
+Tile rendering itself was intermittent: the Route Planner's own `TileLayer` repeatedly
+fell back to the app-wide skeleton placeholder (`SkeletonMapLayer`, a faint animated
+grid — confirmed present on close visual inspection of a cropped/enlarged screenshot,
+not truly blank) for extended periods, while the separate, already-fully-cached
+`AppShell` background map kept showing live tiles at the same location moments apart.
+Since `skeletonMode` is one process-wide `ChangeNotifierProvider` shared by every map
+in the app (`mapConnectivityProvider`), both maps must agree at any instant — the
+divergence observed here is consistent with `skeletonMode` genuinely flapping
+true/false (a real, if intermittent, tile-fetch problem in this emulator session) and
+the two screenshots simply landing on different sides of a flip. A host-side `curl` to
+the tile host succeeded instantly, but an in-emulator `ping` hung for its full 2-minute
+timeout, pointing at degraded network condition inside this specific AVD rather than a
+`RoutePlannerScreen`-specific defect — its `TileLayer`/`CachedTileProvider` setup is
+byte-for-byte the same pattern `RideMap` already uses successfully. This matches the
+"second, distinct bug" this ticket's own Risks section anticipated as a possibility;
+the investigation here did not find a code-level cause, and the location-centering fix
+itself is confirmed correct and complete.

docs/feedback/FB-08-hud-reflow-on-hide.md

@@ -155,3 +155,11 @@ metric into a row with an existing member reflows that row so their `colSpan`s s
 `lib/src/crash/crash_reporter.dart` and `lib/src/tiles/map_connectivity.dart`, neither
 touched by this ticket). `flutter test` is green with a final count of **416 tests**
 (412 baseline + 4 new), no regressions.
+
+### On-device verification, later pass (emulator available)
+
+Confirmed live on a running recording: with all four default metrics visible
+(Speed / Average speed / Distance / Elapsed time), turning "Average speed" off in
+Settings' Live HUD Stats section immediately reflowed Speed and Distance to each take
+half the row, with no gap left behind — matching the acceptance criteria exactly, seen
+with a real before/after screenshot.

docs/feedback/FB-09-hud-title-driven-sizing.md

@@ -326,3 +326,10 @@ that `defaultFor` packs by title width instead of a fixed 4-per-row index. Both
 rewritten to explicitly position their metrics into a shared row via
 `updatePosition`/`updateSize` before exercising `_reflowRow`, so they test the reflow
 behavior itself rather than an incidental default-layout coincidence.
+
+### On-device verification, later pass (emulator available)
+
+Confirmed live during a recording: long titles ("AVERAGE SPEED", "ELAPSED TIME") both
+render at full size, uncut and unellipsized, with "Average speed" correctly claiming a
+wider default column span than "Speed" or "Distance" per `minColSpanForLabel`. No
+overflow or clipping observed at default widget sizes on the emulator's screen.