Files

Dylan 342a8f8382 Break v3 into 16 tickets

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>

2026-08-17 10:41:35 -05:00

2.2 KiB

Raw Blame History

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.

2.2 KiB Raw Blame History