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>
This commit is contained in:
49
docs/v3/V3-02-settings-screen.md
Normal file
49
docs/v3/V3-02-settings-screen.md
Normal file
@@ -0,0 +1,49 @@
|
||||
# V3-02 — Settings screen
|
||||
|
||||
**Phase** Foundations · **Depends on** nothing (pairs with V3-01, V3-03) · **Size** S · **Status** Not started
|
||||
|
||||
## Goal
|
||||
One place for the preferences that currently have nowhere to live.
|
||||
|
||||
## Context
|
||||
`Config` already holds `uploadEndpoint`, `deviceId` and `mapEnabled`, but there is no UI
|
||||
for any of them. The map toggle sits on trip detail because a single switch did not justify
|
||||
a screen. V3-01 and V3-03 both add preferences, which finally does justify one.
|
||||
|
||||
The upload endpoint has **never** had UI, in the native app or the port. This is where it
|
||||
stops being a code-only setting.
|
||||
|
||||
## Design
|
||||
Reached from the record screen. Sections:
|
||||
|
||||
- **Recording** — default activity (V3-01), units (V3-03)
|
||||
- **Map** — render maps on trip detail; later, live map (V3-04)
|
||||
- **Sync** — upload endpoint, with the device id shown read-only and copyable
|
||||
- **About** — version, a link to the privacy policy, licences
|
||||
|
||||
Keep it plain. This is not a screen anyone should spend time in.
|
||||
|
||||
## Implementation
|
||||
1. `SettingsScreen` + a `go_router` route
|
||||
2. Make `Config` reactive — it is currently read once into a provider; settings need writes
|
||||
to propagate. A `ConfigNotifier` over `shared_preferences`.
|
||||
3. Move the map toggle off trip detail
|
||||
4. Endpoint field validates it parses as a URL and is http(s)
|
||||
|
||||
## Acceptance criteria
|
||||
- [ ] Every `Config` value is viewable and editable
|
||||
- [ ] Changing the map toggle takes effect without an app restart
|
||||
- [ ] An invalid endpoint is rejected with a readable message, not silently stored
|
||||
- [ ] Device id is copyable — it is the only way to identify this install to a server
|
||||
|
||||
## Tests
|
||||
- Widget: each control renders and writes through to `Config`
|
||||
- Widget: invalid URL rejected
|
||||
- Changing the map toggle rebuilds trip detail
|
||||
|
||||
## Risks
|
||||
`Config` is currently loaded once at startup into a `StateProvider`. Making it writable
|
||||
without introducing a second source of truth is the only subtle part.
|
||||
|
||||
## Out of scope
|
||||
Account settings (v4). Theme selection (V3-16).
|
||||
Reference in New Issue
Block a user