Off-route re-routing with cue-sheet splicing

## Goal Compute an actual return leg when the rider goes off course, enrich it, and splice it into the active cue sheet — rather than the bearing arrow #57 ships in Phase 3. Deferred here from Phase 3 by D42, which supersedes D30. The bearing arrow gives an off-route rider a direction and a distance, which is what they actually need; this is the richer version, to be built against real evidence about how often riders go off course and what they wanted when they did. ## Acceptance criteria - [ ] BRouter asked for a route from the current position to the rejoin point chosen by #57 - [ ] **Tier 1 only.** The detour enriches through BRouter offline, or not at all. No network call ever happens mid-ride - [ ] Detour enrichment runs under a hard time budget; if it does not complete, the watch falls back to the #57 bearing arrow - [ ] Detour cues merged into the cue sheet, with every later cue's index shifted - [ ] The result is a **new route object with its own monotonic distance axis** (#31), swapped in once when the detour is accepted — never mutated underneath the navigation engine - [ ] `NAV_REMAIN_M` and `NAV_ETA_S` recomputed against the new geometry, and **must not jump** - [ ] `NAV_STATE = 3` (reserved for exactly this) shown while the detour is computed - [ ] Rider can decline; declining returns cleanly to the bearing arrow - [ ] Runs off the main thread and never blocks the ride view or the recording - [ ] Tests: a re-route on an out-and-back, and one that rejoins ahead of where the rider left ## Files - `companion/.../route/nav/Rerouter.kt` ## Notes D42, superseding D30. Everything here was previously in #57; #57 keeps rejoin-point selection and the bearing arrow.

robert commented

2026-09-02 19:41:40 +02:00

(Migrated from git.butzei.de)

Goal

Compute an actual return leg when the rider goes off course, enrich it, and splice it into the active cue sheet — rather than the bearing arrow #57 ships in Phase 3.

Deferred here from Phase 3 by D42, which supersedes D30. The bearing arrow gives an off-route rider a direction and a distance, which is what they actually need; this is the richer version, to be built against real evidence about how often riders go off course and what they wanted when they did.

Acceptance criteria

BRouter asked for a route from the current position to the rejoin point chosen by #57
Tier 1 only. The detour enriches through BRouter offline, or not at all. No network call ever happens mid-ride
Detour enrichment runs under a hard time budget; if it does not complete, the watch falls back to the #57 bearing arrow
Detour cues merged into the cue sheet, with every later cue's index shifted
The result is a new route object with its own monotonic distance axis (#31), swapped in once when the detour is accepted — never mutated underneath the navigation engine
NAV_REMAIN_M and NAV_ETA_S recomputed against the new geometry, and must not jump
NAV_STATE = 3 (reserved for exactly this) shown while the detour is computed
Rider can decline; declining returns cleanly to the bearing arrow
Runs off the main thread and never blocks the ride view or the recording
Tests: a re-route on an out-and-back, and one that rejoins ahead of where the rider left

Files

companion/.../route/nav/Rerouter.kt

Notes

D42, superseding D30. Everything here was previously in #57; #57 keeps rejoin-point selection and the bearing arrow.

Rows
Columns

Off-route re-routing with cue-sheet splicing #73

Goal

Acceptance criteria

Files

Notes