[pipiche38]

Problem

The scoring R-R read excludes only 0x6E (#1071) and keeps both remaining Oura beat channels. On two rings, 0x60 (ibiAmplitude) is the complete beat train and 0x80 (greenQuality) a partial second copy of the same beats over the same time. On one of them, 0x60 alone covers 0.91–0.99 of the wall clock on 10 of 11 nights, and 0x60 + 0x80 reads 1.01–1.31. The #1118 coverage gate then refuses whichever nights banked more 0x80. HRV goes blank and Charge calibration stalls ("3 of 4 nights" for days) for reasons unrelated to the night.

Change

• Swift WhoopStore.rrIntervals: among Oura beat channels, keep 0x80 alone when it holds more beats in the requested window than the amplitude family (0x60 + 0x44: one decoder, split for labelling only, so never scored against each other), otherwise the amplitude family alone, ties included. It's an uncorrelated subquery over the same time/suspect predicates, evaluated before LIMIT, the same shape as the WHOOP 5 transport selection.
• A ring with only one beat channel keeps it ([oura][hrv] rrInterval mixes two optical channels, so every beat is stored twice #1071's guarantee). NULL rows and non-Oura codes are untouched, so WHOOP 4, WHOOP 5 and legacy rows read exactly as before.
• Kotlin RR_INTERVALS_SQL: same predicate through a shared SCORABLE_OURA_CHANNELS twin constant. The diagnostic export (rawRrIntervalsForDevice) moves to its own RAW_RR_INTERVALS_SQL, so an export still carries both beat channels as each other's cross-check.
• Rows are filtered, never deleted. No migration.
• The fingerprint comments on both platforms now say they count the superset the selection chooses from (a new row on either channel can flip it).

Verification

• The exact new SQL was run against two real backups, reading from 30 h before to 6 h after each main session (the app reads a wide window, not the session alone):
  • Reporting ring: 6 refused nights → 5 pass, 1 still refused.
  • Second ring: 4 refused nights now pass.
  • No night that passed before regresses on either ring.
  • The nights still refused are 0x60 over-covering on its own (record overlap). That's a separate problem this PR does not claim to fix.
• swift test WhoopStore: 616/0. Five new tests in RrSourceChannelTests: fuller channel wins, green wins when it is the fuller one, the choice is per requested window, a tie goes to the amplitude family, 0x60 + 0x44 are counted and kept as one.
• Kotlin OuraOneChannelReadSqliteTest (new, 6/0) runs the production SQL on real SQLite using the Swift fixtures and expected values verbatim, plus a raw-export case. RrSourceChannelTest 14/0, Whoop5RRSqliteTest 19/0, and Room's compile-time query check passes.
• Full Android unit suite: the same 8 failures as untouched upstream/main (RecoveryDrivers, StandardHrSensorFormat, StepsDetailIntegration, TodayExplainability), none in touched code.
• doc_comment_lint: OK. No UI strings.
• Not hardware-verified as a live night yet. The backups above are real captures; the read change needs no strap to exercise.

Refs #2424, #1071, #1118

[ryanbr]

Thanks @pipiche38. The report behind this is the best-evidenced one on the tracker: eleven nights of per-channel coverage, cross-checked against the app's own hrv diag lines so the numbers are the same beats the gate classified, and the observation that only 305 of channel 1's 1,373 occupied seconds are also channel 3 seconds. That last one is what makes the diagnosis land, because it rules out same-second duplicates and leaves two channels tiling the same wall time, which is a different bug needing a different remedy.

It is also the root cause of the refusals behind #2425, which merged earlier today. That one stopped a refused night being replaced by naps. This stops the refusal happening for a reason that has nothing to do with the night.

I checked the two ways the predicate could be wrong and it is right on both:

• 0x6E cannot return through the new clause. NOT IN (1, 3, 4) is true for channel 2, but the outer read still carries srcChannel <> :rrx independently, so the known duplicate stays excluded.
• The subquery cannot evaluate to NULL for a row that reaches it. Any Oura row passing the outer time and suspect predicates is itself counted by the subquery, so the SUMs are never over an empty set.

Ties going to the amplitude family matches the doc, the Kotlin SQL matches the Swift byte for byte, and grouping 0x60 with 0x44 as one decoder rather than letting them compete is right.

The witness is the part I want to single out. rrFingerprint deliberately counts every beat BOTH channels offer rather than the selected one, because a new row on the losing channel can flip the selection. Witnessing only the winner would have cached a score the next drain silently invalidates. You wrote that down at the site. I raised the same class of problem on #2414 today where it had been missed, so this one standing correct is worth naming.

One thing to change: the evidence goes one-sided

RAW_RR_INTERVALS_SQL keeps both channels for the Android export. Swift has no equivalent, and Strand/System/DebugDataDiagnostics.swift:284 reads store.rrIntervals, which now applies the selection. Two things follow on iOS:

• The rr= count in the strap log's Night …: grav=N hr=N rr=N resp=N skin=N line quietly changes meaning, from beats banked to beats scored, and stops being comparable with the Android line or with every log already filed.
• An iOS export can no longer reproduce the per-channel analysis that found this bug. You are on iOS. The next person to hit a channel-balance problem would be holding an export that has already hidden it.

The parity ledger reaches the same place from the other direction:

add-unpaired-function: WhoopDao.kt::rawRrIntervals/4#1

parity-governance does not run here, since nothing under Tools/ is touched, so that is a local run rather than something CI would have told you.

A Swift rawRrIntervals twin with DebugDataDiagnostics pointed at it settles both the divergence and the ledger finding at once. Everything else is ready.

[ryanbr]

Taking the Swift twin myself rather than sending this back, since it is a mechanical mirror of SQL you have already written and you have turned enough around today. Do not start on it.

I will add rawRrIntervals to Reads.swift alongside the selecting read, point DebugDataDiagnostics at it so the strap log's rr= keeps meaning beats banked on both platforms, and push it to this branch. That clears the ledger finding at the same time, since the Kotlin function stops being one-sided.

Everything else here stands as reviewed.

[pipiche38]

Thanks @ryanbr, and thanks for taking the Swift twin. One thing I found while checking the shape, before you push, because it changes where the fix belongs:

Android's rr= line reads the selecting query too. AndroidDiagnostics.kt:385 builds the same Night …: grav=N hr=N rr=N resp=N skin=N line from repo.rrIntervalsForDevice(...), which routes to dao.rrIntervals, so on this branch it also changed from beats banked to beats scored. Today the two platforms agree with each other, and both differ from every log filed before. The only consumer of rawRrIntervals is RawSensorExport. If DebugDataDiagnostics alone moves to a Swift raw read, the lines split the other way: iOS prints banked, Android prints scored.

So the fix is three small changes, not two:

1. WhoopStore.rawRrIntervals(deviceId:from:to:limit:) in Reads.swift, the same SQL as RAW_RR_INTERVALS_SQL: 0x6E and tsSuspect excluded, no selection, same ORDER BY.
2. DebugDataDiagnostics.swift:284 reads it.
3. AndroidDiagnostics.kt:385 reads rawRrIntervalsForDevice.

One side effect: on a WHOOP 5, the raw read also skips the strict single-transport selection, so rr= on a 5/MG would count every transport, not the one scored. If you'd rather keep that line exactly as before on a WHOOP 5, the alternative is to leave rr= as scored on both platforms and add a separate rrBanked= from the raw read. Your call. I've gone with the raw read, as you described.

On the export: an iOS .noopbak still carries the whole rrInterval table with srcChannel, since the selection filters at read time and never deletes rows. The per-channel numbers in #2424 came from exactly that, so the analysis stays reproducible on iOS either way.

I have this as a patch (the three changes, plus a Swift testTheRawDiagnosticReadKeepsBothBeatChannels on the same fixture and expected values as the Kotlin theRawExportReadKeepsBothBeatChannels; RrSourceChannelTests 18/0). It's on my fork as proposal/2423-raw-rr-twin (393cbe20a, one commit on top of this PR's head), not on this PR's branch, since you said you're taking it. Cherry-pick it, ask me to push it here, or use it as a checklist for yours.