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

This commit is contained in:
2026-08-25 08:32:32 -05:00
parent 2abbaf5564
commit c67072135b
4 changed files with 64 additions and 0 deletions

View File

@@ -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.