Dylan
342a8f8382
One file per feature, in the v2 shape that worked: goal, context, design, implementation, acceptance criteria, tests, risks, out of scope -- written before implementing so the risks are on paper rather than walked into. Three carry more weight than their size suggests. V3-01 ships the port's first real migration, and since the destructive fallback is gone, getting addColumn and a v1-database test right matters more than the feature. V3-08 forces a routing-engine decision with ongoing cost, so it sits behind a RoutingService interface mirroring what LocationSource did for GPS. V3-13 is not code at all -- it answers the three questions open since v2, and V3-15 may close unbuilt as a result, which is a legitimate outcome. Several tickets record constraints that are easy to lose: no activity picker in front of Start, because the founding premise is press-and-go with gloves; the Route-to-Trip foreign key must not cascade, or deleting an old plan deletes the ride; V3-14 will deliberately break the parity harness by adding GPX <type>, and that expectation should be updated rather than the check dropped; and V3-16 must not regress the explicit text colours that exist because of the black-on-black bug. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
|