# V3-15 — Auto-pause

**Phase** Quality · **Depends on** V3-13 · **Size** M · **Status** Gated on evidence

## Goal
Decide — with data — whether the app should pause itself when the rider stops.

## Context
**Rejected in v2 as unreliable in traffic**, and that reasoning still stands: a motorcycle
at a long red light is stationary and still mid-ride. Auto-pausing there fragments a ride
into dozens of segments and makes the map look wrong.

Kept in the backlog because it is a common expectation from other ride apps.

## The gate
**Do not build this until V3-13 provides real ride data**, then answer:

1. How long is a typical traffic stop, versus a real break?
2. Is there a clean threshold between them, or do the distributions overlap?
3. Does moving time already handle this well enough? The noise floor **already excludes
   stationary time from moving time** — so the numbers may be right and only the segment
   count would change.

**If (3) is true, this ticket should be closed rather than built.** That is a legitimate
outcome and arguably the likely one.

## Design, if the data supports it
Time-based, not motion-based: pause after N minutes below the noise floor, resume on the
first fix above it. N derived from the data, not guessed, and never below two minutes.

Off by default, in settings, described plainly.

## Implementation
1. Analyse stop-duration distribution from real rides
2. **Decide and record whether to proceed**
3. If proceeding: a threshold in `RecordingEngine`, reusing the existing pause path so
   segments behave identically to a manual pause
4. Setting, defaulting off

## Acceptance criteria
- [ ] A written decision, with the data behind it
- [ ] If built: a traffic-light stop does **not** pause; a coffee stop does
- [ ] Auto-pause produces segments indistinguishable from manual ones
- [ ] Off by default

## Tests
- Synthetic stop patterns: short stop stays recording, long stop pauses
- An auto-paused ride's segments behave exactly like manual ones
- Distance still never spans the gap

## Risks
Building it because other apps have it, rather than because the data says so. The gate
exists for that reason.

## Out of scope
Motion-sensor detection. That is the paid-engine feature set, and this app deliberately
does not use it.