uhryniuk
4c634354bd
V3-04 through V3-07, V3-10, V3-16 shipped complete; V3-11/V3-12/V3-14 shipped code-complete pending device/account verification; V3-08/V3-09 deferred behind a new V3-17 (self-hosted OSRM investigation). 316 tests passing, up from 221. The APK is a fresh release build (debug-signed, no release signing config exists yet) with two build fixes applied: core library desugaring enabled for flutter_local_notifications, and sentry_flutter bumped to 9.27.0 (8.14.2's bundled Kotlin plugin was incompatible with this project's Kotlin 2.4.0 toolchain).
2.2 KiB
V3-15 — Auto-pause
Phase Quality · Depends on V3-13 · Size M · Status Gated on evidence
Goal
Decide — with data — whether the app should pause itself when the rider stops.
Context
Rejected in v2 as unreliable in traffic, and that reasoning still stands: a motorcycle at a long red light is stationary and still mid-ride. Auto-pausing there fragments a ride into dozens of segments and makes the map look wrong.
Kept in the backlog because it is a common expectation from other ride apps.
The gate
Do not build this until V3-13 provides real ride data, then answer:
- How long is a typical traffic stop, versus a real break?
- Is there a clean threshold between them, or do the distributions overlap?
- Does moving time already handle this well enough? The noise floor already excludes stationary time from moving time — so the numbers may be right and only the segment count would change.
If (3) is true, this ticket should be closed rather than built. That is a legitimate outcome and arguably the likely one.
Design, if the data supports it
Time-based, not motion-based: pause after N minutes below the noise floor, resume on the first fix above it. N derived from the data, not guessed, and never below two minutes.
Off by default, in settings, described plainly.
Implementation
- Analyse stop-duration distribution from real rides
- Decide and record whether to proceed
- If proceeding: a threshold in
RecordingEngine, reusing the existing pause path so segments behave identically to a manual pause - Setting, defaulting off
Acceptance criteria
- A written decision, with the data behind it
- If built: a traffic-light stop does not pause; a coffee stop does
- Auto-pause produces segments indistinguishable from manual ones
- Off by default
Tests
- Synthetic stop patterns: short stop stays recording, long stop pauses
- An auto-paused ride's segments behave exactly like manual ones
- Distance still never spans the gap
Risks
Building it because other apps have it, rather than because the data says so. The gate exists for that reason.
Out of scope
Motion-sensor detection. That is the paid-engine feature set, and this app deliberately does not use it.