Ride the drivetrain, command the load in watts

Speed now comes from the drivetrain and the load from the road, which is
the way round a bike actually works.

Speed is cadence x development, filtered lightly. Power, not cadence,
decides whether the rider is driving it: on a direct-drive trainer the
flywheel keeps the cranks turning after they stop, so cadence alone reads
a healthy 80 rpm for someone doing nothing. Below 15 W the speed runs
down to whatever the gradient sustains on no power - zero uphill, a real
freewheeling speed on a descent. Stopping on a 3.5% climb used to settle
at 22 km/h and stay there, because the model wanted to decelerate and a
blend toward the flywheel speed outvoted it; that blend is gone.

The D100 sends no cadence over FTMS - it is a rebadged Magene T110 with
cadence disabled in firmware (qdomyos-zwift#3282) - so it is inferred
from wheel speed, which one sprocket and no freewheel make exact. Its
Zwift channel does carry cadence, and is now greeted with RideOn and
subscribed on every notifying characteristic, so a measured value is used
where one arrives.

The load is commanded as power, not gradient. The trainer declares
50-600 W in 1 W steps against 0-6% inclination in 0.1% steps refusing
negatives, and whether it acts on 0x11 at all is still unconfirmed. Its
power target is a ceiling rather than a setpoint, which is very nearly
what a road is: exceed it and the surplus becomes speed. Gravity travels
on the same channel as watts, so nothing is lost by leaving 0x11 alone.
LoadChannel keeps the gradient path selectable and tested.

Virtual shifting reaches the trainer for the first time. The physics
load model was written but never called, and a paddle press both shifted
a gear in Rust and nudged the gradient in the webview - the shift
silently, the tilt visibly, so the paddles looked like a gradient trim.

Also: a fixed 12 W drivetrain loss, held as a power because that is how
it presents; crank length, so a gear can be reported as the force it puts
under the foot; gear and pedal force on the ride screen; a drag-race
profile for testing gearing on the flat.

Two readout bugs fixed on the way. The rolling windows were trimmed by
timestamp but fed on a fixed timer, so every second spent on the ride
screen before starting pushed samples at t=0 that could never expire -
speed read a fraction of the truth for the first 45 s. And the headline
speed was a 45 s mean, which took most of a minute to show a gear change.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

REQUIREMENTS.md

@@ -176,9 +176,17 @@ button we have found drives them.
 > two-button test returning 4, 7, 4, 7, 4, 7. The first capture had been pressed out of
 > order.
 
-> **Open:** all ten buttons arrived over the **single** pod at `f4:c4:59:03:a1:8e`
-> (type byte `0x0B`). What the second pod (`c0:4a:0e:f9:a8:78`, `0x0A`) contributes is
-> unknown — it may mirror the same state, or carry nothing we need.
+> **The pods are not disjoint — answered 2026-08-05.** All ten buttons arrived over the
+> **single** pod at `f4:c4:59:03:a1:8e` (type byte `0x0B`), and with both pods connected the
+> `+` paddle arrives **twice**: once from the pod it is printed on and once relayed by its
+> twin. `−` arrives once. Measured from a ride log rather than a capture — one press of `+`
+> moved the gear by two (7 → 9 → 11), one press of `−` by one.
+>
+> Two consequences, both handled in `controller::Buttons`. The app must **merge the pair into
+> one controller**: a button is held when either pod says so, and only that aggregate's edges
+> may act, or every `+` press shifts twice. And **a pod sending its twin's paddle is normal**,
+> so it is evidence of a wrong-way-round pair only while that pod has never sent its own —
+> otherwise the connection screen asks the rider to swap a pair that is filed correctly.
 
 ### 2.3.2 The D100's own Zwift service — telemetry, not shifting
 
@@ -379,7 +387,7 @@ bikecontrol/
 | FR-1.8 | When nothing is found, prompt to wake the device (per A-4) — pedal the trainer, press a Click button | Must |
 | FR-1.9 | Allow riding with the trainer alone; on-screen and keyboard controls substitute | Must |
 | FR-1.10 | A connect or reconnect attempt in flight is cancellable: disconnect and app exit abandon it rather than queue behind it, and any half-open GATT link is closed on the way out | Must |
-| FR-1.11 | Auto-reconnect is bounded. On giving up, the trainer settles in `Lost` carrying the reason — never silently back to `Idle` | Must |
+| FR-1.11 | Auto-reconnect is bounded, for the controller as well as the trainer. Giving up is announced as a terminal state carrying the reason — never a silent return to `Idle`, and never an actor that stops without saying so | Must |
 | FR-1.12 | Scanning resumes on its own whenever no trainer link is held or being attempted, so a disconnect or a failed connect does not leave a frozen device list | Should |
 
 **Cancellation note (FR-1.10):** a connect is a long operation — up to `scan_timeout` before the
@@ -633,6 +641,7 @@ tests, and removes dependence on the trainer's internal mass assumptions.
 | NFR-8 | **Observability** — all BLE traffic loggable at debug level, including decrypted Click frames, for protocol diagnosis |
 | NFR-9 | **Shutdown** — every exit path completes the SAF-2 sequence and closes within 8 seconds, whatever the radio was doing when the rider quit |
 | NFR-10 | **No busy-waiting** — a supervisor whose event source has closed drops it. No loop may spin on a permanently-ready future, and no arm of a `biased` select may starve the one that carries the shutdown command |
+| NFR-11 | **Screen stays lit** — a live ride (running or paused) holds a system idle inhibitor, so the display never blanks or locks under a rider whose hands are on the bars. Held for the ride, not for the app: it is taken when the ride starts and released when it ends, however it ends. Failing to take it costs a blanked screen, never a ride |
 
 ---