[bhelm]

Why

Raw physiology is currently stored under the device ID that produced or imported it. Some readers treated that storage provenance as the boundary of the user's timeline and queried only the currently active device or the legacy my-whoop source.

That breaks as soon as a user replaces, removes, archives, or alternates WHOOP straps: data remains in the database but disappears from Stress, Sleep, AI Coach, and timeline views. It also makes correctness depend on every caller remembering which device namespace happens to contain a given period.

Device IDs should remain precise write provenance, but they should not fragment reads of the user's own WHOOP physiology. The read contract therefore resolves one deterministic source set everywhere:

1. the explicitly active source first (preserving existing explicit-device behavior),
2. every registered WHOOP strap, including archived straps, in stable registry order,
3. the canonical legacy/import source my-whoop last,
4. duplicates removed while preserving that precedence.

Archived devices are deliberately included: archiving stops future connection attempts; it must not orphan retained history. Non-WHOOP devices are not implicitly folded into this WHOOP timeline.

What changes

• Unifies Android raw HR, R-R, gravity, HR buckets, sleep sessions, computed sleep, and habitual-midsleep reads across registered WHOOP straps.
• Applies the same source-resolution contract on Apple platforms.
• Routes Stress, Sleep, AI Coach, Full Day/Deep Timeline, and Rhythm consumers through the device-aware repository facades.
• Removes Android's ambiguous device-scoped repository names. Legitimate owner/export/diagnostic reads now require explicit *ForDevice APIs, while personal timeline consumers use only union APIs; an architecture test prevents the old names from returning.
• Preserves exact R-R identity as (timestamp, rrMs, sequence) and aligns deterministic ordering across Kotlin and Swift.
• Keeps stored canonical daily stress unchanged; only its raw intraday inputs and dependent views become device-aware.
• Retains single-device and legacy my-whoop behavior.

Parity guard

A shared JSON oracle defines source ordering, legacy collapse, non-WHOOP handling, and R-R identity/order. Native Android and Swift tests consume the same contract, while source-wiring guards prevent consumers from regressing to direct current-device reads.

The clean PR branch passed all Android parity/wiring suites (22 tests, 0 failures). Source-level Apple parity review found no divergence. Apple tests cannot execute on the Linux build host because Xcode/Swift is unavailable.

Verification

• Android full unit suite: 4,788 tests, 0 failures, 0 errors, 6 skipped.
• assembleFullDebug: successful.
• Independent final review: no open P0/P1 findings.
• Verified on the staging build: the Stress screen displays the intraday chart from the unified raw timeline.

Known boundary

Alternating straps is supported: each strap's disjoint retained periods form one timeline. If two straps are genuinely worn at the same time, distinct same-time R-R beats can coexist because the current schema has no wear-interval/device-era ownership signal. Exact duplicates are removed deterministically; selecting a single owner for simultaneous wear is intentionally outside this change.

Related issues and PRs

• Partially addresses Multi-WHOOP: sweep the hardcoded "my-whoop" assumptions (the #512 class) #1304, the broader audit of hardcoded my-whoop read assumptions; this PR closes the raw-physiology subset, not every canonical-source use.
• Related to Devices: switch between / compare two straps (4.0 + 5/MG) for one user — not fused scores #1300: this change joins retained raw periods across alternating straps, but does not fuse completed daily scores or change the single-owner-per-day scoring rule.
• WHOOP serial identity: adopt a stable serial id (mirror the Oura path) — multi-strap keystone #1303 / feat(ble): adopt a stable whoop-<serial> identity for 5.0/MG (#1303 phase 1) #1455 add stable WHOOP serial identity. That reduces future identity fragmentation but does not replace correct reads of already-separated history.
• Possible merge overlap: feat: add sleep-aware steps and physiological day cycles #1572 (WhoopRepository, Reads, IntelligenceEngine, TodayView), feat(imu): unlock WHOOP 5/MG 100 Hz capture and labeled recording sessions #1709 (WhoopRepository, Reads, BLE/export/Test Centre), and feat: AI Coach — streaming, voice, brief, history, widgets, Siri (K1-K15) #1547 (AI Coach). None implements this complete raw-read contract or makes this PR redundant.

[ryanbr]

@bhelm — the read contract is right, and the architecture test that blocks the old device-scoped names from returning is a good touch. One stream worries me, and I think it needs treating differently from the others.

R-R interleaving changes the number, not the volume

The boundary is stated as benign:

Exact duplicate beats are removed with the active source winning; distinct beats sharing a timestamp remain intact.

For HR buckets, gravity, sleep sessions and habitual midsleep that reasoning holds — averaging and interval data tolerate extra rows. R-R does not, because of where it lands:

rrIntervalsUnion → StressScreen / AiCoach / FullDayChartScreen → DaytimeStress, which buckets every beat by hour and hands it to HrvAnalyzer.analyzeRaw(...) for RMSSD (DaytimeStress.kt:334-351).

RMSSD is the root mean square of SUCCESSIVE DIFFERENCES. Interleaving two straps' beats does not duplicate it — the successive differences start alternating between two independent measurements of the same heart, so they carry the inter-device offset instead of real beat-to-beat variability. The result is not a doubled number that a reader can discount; it is a wrong number that looks normal.

This is reachable today, not theoretical: I have a period of genuine simultaneous 4.0 + 5.0 wear with both straps registered, so both feed the union across that window.

It also stacks on an open defect. #1008 / #1118 have 4.0 R-R already over-counting roughly 2x via crossSecondOverCount; this would put a second, larger multiplier on top of one that is not yet fixed.

What I would suggest

Keep the union for every other stream, and hold R-R to the active strap (or exclude it) until there is a wear-interval / device-era ownership signal. That keeps the whole benefit of the change — Stress, Sleep, Coach and timeline stop losing history at a strap swap — without letting one stream's semantics change silently for anyone who has ever worn two straps at once.

Alternating straps, which is the case the PR is really aimed at, is unaffected either way: disjoint periods never interleave.

Two smaller things

• The two new StrandTests/ files run only under app-build, which is disabled by default — the same gap that left four red tests unnoticed on feat(imu): unlock WHOOP 5/MG 100 Hz capture and labeled recording sessions #1709. Worth dispatching it against this PR before merge; test (StrandAnalytics) and test (WhoopStore) passing does not cover them.
• Merge overlap with feat(imu): unlock WHOOP 5/MG 100 Hz capture and labeled recording sessions #1709 on WhoopRepository and Reads is real; whichever lands second will need a rebase.

[ryanbr]

Dispatched app-build against this PR: both legs green — macOS (Strand + StrandTests) and iOS.

That covers the gap you flagged. DeviceRawSourceParityTests and RawPhysiologyUnionTests run only under that workflow, which is disabled by default, so they had not executed anywhere — not on your Linux host and not in the 15 normal checks. They compile and pass.

The R-R question above is the only thing still open from my side.