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>
2.6 KiB
V3-16 — Visual identity
Phase Quality · Depends on V3-04, V3-05 · Size M · Status Not started
Goal
Move from "functional dark" to a look that is deliberately designed.
Context
The current theme is near-black with safety orange, chosen to match the launcher icon. It is clean and legible, and it was never actually designed — it was picked so the app did not look unfinished.
Deliberately sequenced after the live map and mounted mode. Both change what the app looks like far more than a palette does, and designing around screens that are about to change is wasted effort.
Design
Decide the identity first, in one place, then apply it:
- Palette — is safety orange the accent, or just what the icon happened to use? A motorcycle app has obvious references (dashboard instruments, race liveries, road signage) and obvious clichés to avoid.
- Typography — the app is numbers-first. The monospace tabular figures are already right for that; the rest is undecided.
- Data display — the speed readout, the charts and the map legend are the identity far more than any chrome. This is an instrument, not a document.
- Motion — currently none. A ride recorder probably wants very little.
Constraint that outranks aesthetics: legibility through a visor, in daylight, at a glance. V3-05 may force a high-contrast variant, and the identity has to survive it.
Implementation
- Write the direction down — palette, type, and what the app is trying to feel like — before touching code
- Extend
ripprColorsinto a fuller token set - Apply screen by screen, keeping
flutter testgreen throughout - Keep the explicit text colours. The theme names
bodyColoranddisplayColordeliberately: a missing default once rendered a 64 sp figure black-on-black and only a screenshot caught it. Do not regress that while restyling.
Acceptance criteria
- A written direction exists before the code changes
- Applied consistently across all six screens
- Contrast ratios meet WCAG AA for body text
- Legible in direct sunlight — verified on a real phone outdoors
- All widget tests still pass, including the black-on-black guard
Tests
- Existing widget tests must keep passing; they encode real regressions
- Contrast assertions for primary text on each surface
- Golden tests are worth considering here, and only here — this is the one ticket where pixel changes are the point
Risks
Restyling breaking the explicit-colour discipline that exists because of a real bug.
Out of scope
A new app icon. The Route mark is good and recently applied.