uhryniuk
6f1bfc753a
Adds Activity (motorcycle/bicycle/scooter/skateboard/running/walking/other) as a column on Trip, and threads it through as real behaviour rather than a label: ActivityProfile (domain/activity_profile.dart) carries a noise floor, accuracy gate, histogram bucket width, and elevation smoothing window/threshold per activity, consumed by sanitizeSpeedKmh, isUsableFix, computeSummary, Accumulator and speedHistogram. The motorcycle profile reproduces the exact constants the app shipped with before this existed, and a test asserts they never drift apart. This is the port's first real migration: schemaVersion 1 -> 2, m.addColumn(trips, trips.activity) with a motorcycle default so every existing row survives unmodified. Proven with a hand-built v1 SQLite file (raw sqlite3, not drift_dev's schema tooling) that a real database with real rides upgrades and keeps every trip, segment and point. No picker in front of Start: a new trip defaults to whichever activity was most recently used, derived live from the trips table rather than duplicated into a Config field. Editable afterwards on trip detail, which recomputes aggregates under the new profile immediately -- a walking pace that reads as noise under a motorcycle's floor reads as real movement once the activity is corrected, and there's a test proving exactly that transition. The widget-test pass for the activity-picker sheet caught a real overflow bug: seven options overflowed a Column-based bottom sheet the same way the record screen once did. Fixed with a scrollable ListView + isScrollControlled, same shape as that earlier fix. 188 tests (171 -> 188): 2 migration, 5 ActivityProfile, 3 profile-threading proofs in computeSummary, 5 repository, 2 widget. Analyze clean. Co-Authored-By: Claude Sonnet 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.