[ryanbr]

A brief wake ended the night. From @justinjor-bit's report: up once for the bathroom, straight back to sleep, and a 6h40m night scored 150 minutes at eff=0.96 — a confident, clean, wrong answer that then fed the 21-day baseline every later night is judged against.

Two mechanisms, both confirmed against the code, both fixed.

The bridge could never reach the case it was built for

bridgeSparseSleep merged only runs already adjacent in its own output:

if (last != null && last.stage == "sleep" && p.stage == "sleep") { …merge… }
out.add(p)

An intervening active run is appended first, so the next pair is unreachable. A bathroom trip is definitionally an active run — so the rescue built for fragmentation was structurally unavailable in the scenario that needs it most.

The reporter's trace put a number on it: the bridge merged nothing on 14 of 14 sparse nights, runsAfter == runsBefore every time. The pieces then died at the 60-minute session floor.

One active run up to sparseBridgeActiveMaxMin is now absorbed, with the whole span still subject to sparseBridgeGapMin and to the HR band. Two or more consecutive active runs are not — that is a night with structure in it, not one interruption.

The bound is defined as maxGapMin, not given a number of its own. That is already this file's threshold for "a discontinuity this long is decisive", so reusing it keeps one such judgement in the detector instead of two that drift apart. It is also the cheap half of the guard — the real one is the HR band, which a genuine wake fails because it keeps HR elevated for its duration. mergeMin (15) already absorbs shorter active runs upstream in mergePeriods, so this covers the band between that and a wake long enough to be a real break.

The HR gate used the wrong statistic

hrSleepBandAcross judged on the mean, which a single arousal spike drags out of band. confirmSleepWithHR, twelve lines below, already documents exactly this — "brief arousal / wake HR spikes (observed to ~190 bpm) … pull the MEAN above baseline × mult and reject the run" — and uses the median for that reason.

This gate asks the same question over a shorter window, where one spike dominates the mean even harder. Median now. It still rejects a sustained elevation just as firmly, which is the discrimination the gate exists to make — and without this, removing the active-run blocker would not have helped the target case anyway.

The shadow tracer is gone

Swift kept a second copy of the bridge loop purely to emit trace lines, which had to be edited in step with the real one. They are one pass now, so a trace cannot silently disagree with the behaviour it describes.

Android had none of that machinery at all. The line that made this issue diagnosable was iOS-only — which is why the reporter being on iPhone is the reason we know any of this. Ported, and both platforms now report the intervening active run's length, the number the old trace could not supply.

Two comments corrected rather than left

• The bridge's own doc said "Active runs … are left untouched; the span between two bridged sleep runs (an "active"/gap run, if present) is absorbed" — which reads as though the case was handled. It was not, and that sentence is a large part of why this went unnoticed.
• The empty-attempts trace line no longer claims "fragments separated by active runs", because that cause has just been removed. An empty list now means one sleep run, or fragments split by consecutive active runs.

A repinned test

One existing Swift test asserted "an intervening active run is never a considered pair". True when written — and it was the bug. Repinned to the same shape with the opposite expectation.

Not changed

minSleepMin stays at 60. The reporter also shows 45–57 minute runs dropped by it, which is real, but it is a separate judgement about what counts as a session and deserves its own evidence rather than riding along here. With the bridge working, fewer runs reach that floor fragmented in the first place.

What the absorbed minutes become

Worth stating precisely, because the reporter asked for a disturbance rather than a truncation.

A wake segment inside a session adds to WASO and increments disturbances (HypnogramMetrics), so a staged wake is preserved rather than deleted. But both stagers call wake primarily off HR, not motion — the motion-aware refinement is opt-in and only ever shrinks wake. An interruption the bridge absorbed had HR in the sleep band by construction, so it will generally stage as light sleep, and those minutes land in TST.

So the HR gate is what decides: movement with sleep-band HR is a stir scored as sleep, which is defensible; movement with elevated HR never reaches the bridge. Trading four lost hours for ~15 generously-scored minutes is a far smaller error pointed the right way — but it is an error, not a clean win.

Verification

• Android 4,937 tests, 0 failures — 11 new
• StrandAnalytics 1,671 tests (1 skip), 0 failures — 11 new, byte-parity twins
• the two end-to-end cases run detectSleep on a sparse fixture with a real 15-minute up-and-about, on both platforms
• doc-comment lint and the i18n --ci gate clean
• not validated on a real interrupted night — the reporter has not caught one with the trace on yet, so the unit cases stand in for it

Addresses the detection half of #1657.