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.3 KiB

Raw Blame History

V3-09 — Follow a planned route while riding

Phase Route planning · Depends on V3-04, V3-08 · Size M · Status Not started

Goal

Pick a saved route before starting, see it on the live map underneath your actual track, and afterwards compare what you rode against what you planned.

Context

The payoff that makes V3-07 and V3-08 worth building, and the point where route planning meets the live map. Not navigation — no turn-by-turn, no voice. Just the line you meant to follow, drawn under the line you actually rode.

Design

Attach an optional routeId to Trip. That is enough for both the live overlay and the after-the-fact comparison.

Live: the planned route in a muted colour, the recorded track drawn over it in the existing speed colours. Immediately obvious when you have left the plan.

Afterwards, on trip detail: both lines, plus how far you deviated and how the real duration compared with the estimate — which also, over time, tells you how honest the ETA is.

Deliberately not: rerouting, off-route alerts, or anything that demands attention while riding. A rider glancing at handlebars wants a picture, not an interruption.

Implementation

routeId on Trip — third migration
Route picker on the record screen before Start, defaulting to none
Live map renders the planned polyline beneath the track
Trip detail renders both, with a comparison block
Deviation: max and mean distance from the recorded points to the planned polyline — perpendicularDistanceMeters already exists and is parity-proven

Acceptance criteria

A route can be selected before starting, or not
Both lines render, visually distinguishable
Deviation and duration-vs-estimate appear on trip detail
A ride with no route behaves exactly as today
Deleting a route does not delete rides that referenced it

Tests

Deviation maths against a known track and route
Repository: deleting a route nulls routeId rather than cascading to the trip — the cascade direction here is the opposite of segments and is easy to get wrong
Widget: both polylines present when a route is attached

Risks

The Route → Trip foreign key must not cascade. Deleting an old plan must never delete the ride you did.

Out of scope

Turn-by-turn, off-route alerts, rerouting.

2.3 KiB Raw Blame History