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>
v3 tickets
One file per feature, in the shape that worked for v2: Goal · Context · Design · Implementation · Acceptance criteria · Tests · Risks · Out of scope. Written before implementing, so the risks are on paper before they are walked into.
Menu, not a commitment. Nothing here is scheduled.
Everything in v3 is buildable with no server. Group rides, accounts and paid cloud backup are v4 — see ../BACKLOG.md.
Before starting anything: ../port/REAL-RIDE-CHECKLIST.md. The port has never recorded a real ride, and item I3 may still force a change of GPS engine — which would land underneath several of these tickets.
The tickets
| # | Ticket | Size | Depends on |
|---|---|---|---|
| V3-01 | Activity type per ride | M | — |
| V3-02 | Settings screen | S | — |
| V3-03 | Distance and speed units | S | V3-02 |
| V3-04 | Live map on the recording screen | M | — |
| V3-05 | Mounted (handlebar) mode | M | V3-04 |
| V3-06 | Live stats in the notification | S | — |
| V3-07 | Route drawing (pins, straight lines) | M | — |
| V3-08 | Road-snapped routing and ETA | L | V3-07, V3-01 |
| V3-09 | Follow a planned route | M | V3-04, V3-08 |
| V3-10 | Trip splitting | S | — |
| V3-11 | Offline tile pre-download | M | V3-04 |
| V3-12 | Crash reporting | S | — |
| V3-13 | Real-ride measurements | M | riding |
| V3-14 | GPX interoperability | S | V3-01 |
| V3-15 | Auto-pause | M | V3-13 (gated) |
| V3-16 | Visual identity | M | V3-04, V3-05 |
Dependencies
V3-01 ──┬────────────► V3-08 ──► V3-09
└──► V3-14 ▲
V3-07 ──────► V3-08 │
V3-02 ──► V3-03 │
V3-04 ──┬──► V3-05 ──┬───────┘
├──► V3-11 └──► V3-16
└──► V3-09
V3-13 ──► V3-15 (gate: may close unbuilt)
no dependencies: V3-01 · V3-02 · V3-04 · V3-06 · V3-07 · V3-10 · V3-12
Three that carry more weight than their size suggests
V3-01 ships the port's first real migration. The destructive fallback is gone, so
getting addColumn plus a v1-database test right matters more than the feature does —
V3-07 and V3-09 both add migrations behind it.
V3-08 forces a routing-engine decision with ongoing cost and vendor implications.
Behind a RoutingService interface, mirroring what LocationSource did for GPS.
V3-13 is not code. It answers the three questions that have been open since v2, and V3-15 may close unbuilt as a result — a legitimate and probably likely outcome.
Suggested order, if starting cold
- V3-01 — proves the migration path while the stakes are low, and unblocks V3-08/14
- V3-02 + V3-03 — small, self-contained, gives V3-01 a home
- V3-04 — the most visible change, and the gateway to four other tickets
- V3-07 — entirely independent; useful on its own before the routing decision
- V3-13 — as soon as there is a ride to measure
V3-12 is a good filler at any point. V3-16 should wait until the screens stop moving.