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).
58 lines
2.2 KiB
Markdown
58 lines
2.2 KiB
Markdown
# 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:
|
|
|
|
1. How long is a typical traffic stop, versus a real break?
|
|
2. Is there a clean threshold between them, or do the distributions overlap?
|
|
3. 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
|
|
1. Analyse stop-duration distribution from real rides
|
|
2. **Decide and record whether to proceed**
|
|
3. If proceeding: a threshold in `RecordingEngine`, reusing the existing pause path so
|
|
segments behave identically to a manual pause
|
|
4. 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.
|