Daytime stress: score against a personal cross-day baseline, not the day's own calm hours

[vishk23]

Daytime stress: score against a personal cross-day baseline (Oura-style), not the day's own calm hours

Today's intraday stress timeline (DaytimeStress) z-scores each waking hour against that same day's calm hours (.dayRelative). That masks an all-day-elevated day: a stressful day pulls its own floor up, so nothing reads as high. This wires the alternative that a personal, cross-day rolling baseline enables — .baselineRelative — the same shape Oura uses.

The pieces (all additive; each degrades honestly on thin history)

• DaytimeBaselines (new) — folds a person's trailing per-day daytime streams into personal baselines via the identical Winsorized-EWMA path the nightly baselines use (Baselines.foldHistory). Each day contributes one aggregate: HR = the 10th-percentile of waking-hour mean HRs (a calm-hour reference), RMSSD = the median waking-hour RMSSD. Today is excluded from its own baseline.
• DaytimeStress.baselineRelative(hr:rmssd:) (mode) — z-scores each waking hour against the cross-day baseline instead of a day-local reference. The +15 bpm "high" margin is translated onto the shared 0–3 squash curve so an hourly point keeps the daily score's scale and bands exactly.
• Baselines — two new metric configs (daytime_hr, daytime_rmssd) with bounds/floors appropriate to waking (warmer, noisier) physiology, distinct from the nightly resting_hr/hrv configs.
• StressView — resolves the mode from the trailing ~30 local days after the existing HR-count guard; .baselineRelative once there's enough real worn daytime-HR history for a usable baseline, else .dayRelative (the unchanged default). Cold start and all-sparse/imported windows keep today's exact current behavior.

Validation (against real data)

The .baselineRelative HR margin was tuned on a 26-day Oura-reference correlation: a ~15 bpm daytime-HR elevation over the pooled 10th-percentile baseline is where elevated HR starts reading as Oura-comparable "high" stress (r≈0.6). A per-day baseline scored worse in the same comparison (r 0.43–0.53) — which is the whole reason for the cross-day reference.

I also replayed the pipeline against ~18 days of my own 1 Hz wrist data:

• Density: waking hours carry ~3600 HR samples/hr — ~12× the aggregation gate, so the feature actually activates rather than silently degrading.
• Calm-HR baseline: the P10-of-waking-hour-means lands ~65 bpm, matching the tuning reference, so the +15 bpm → ~80 bpm high threshold is physiologically sane for a real wearer.

RMSSD is built but gated OUT of the live score (daytimeRMSSDScoringEnabled = false)

rawScore sums the HRV z equal-weight with the HR z. On real wrist data, daytime RMSSD off the strap is artifact-dominated — hourly values swing ~40→430 ms as posture/motion/talking break the R-R stream, an order of magnitude noisier than overnight recumbent HRV. Enabling it before it's shown to improve the correlation risks pushing the combined score below the HR-only r≈0.6 it was validated at.

So the whole RMSSD half — aggregate, fold, config, rawScore term — is built and unit-tested, but held out of production scoring behind a single documented flag until it has its own Oura-reference validation pass. Flipping the flag is a one-line change with a tripwire test that inverts with it. This mirrors how I've kept other unvalidated engines (the SWC-tier HRVReadiness) behind a flag until validated on real data.

Notes

• Full StrandAnalytics suite green; macOS build green.
• Kotlin twin included + gradle-tested (12 tests green). android/…/analytics/DaytimeBaselines.kt mirrors the Swift caller-side fold exactly — the same P10 daytime-HR / P50 daytime-RMSSD per-day aggregates (reusing DaytimeStress's own floorDiv/bucketSeconds/isWakingHour/minHourHrSamples/HrvAnalyzer so the folded value equals the value later scored against), the same Baselines.foldHistory path with daytimeHRCfg/daytimeRMSSDCfg, the usable-gated RMSSD-withhold, the scoringMode degradation gate, and the daytimeRMSSDScoringEnabled = false live-score flag with its inverting tripwire test — so Swift and Kotlin yield byte-identical baselines and scores. The 12 Swift DaytimeBaselinesTests are mirrored 1:1 as Kotlin DaytimeBaselinesTest with identical inputs and expected values, all green under ./gradlew :app:testFullDebugUnitTest (stacked on the stress: baseline-relative daytime mode + Oura-comparable high-stress minutes #413 Kotlin twin).
• Opening for review + validation — if the intraday timeline reads wrong on your own worn data, that's exactly the feedback I'm after.

[vishk23]

Merged current main (274 commits, no conflicts) to clear the UNSTABLE state and get a fresh CI run.

On the failing check: the red leg was test (NoopLocalAccess), which failed after 45m01s on 14 Jul. That is a stalled runner, not a code defect — this branch does not touch Packages/NoopLocalAccess at all (only StrandAnalytics, StressView, and the Android twins), and every other package leg passed in under two minutes in the same run. Its logs have since expired, so I reproduced the leg locally on the merged tree instead: swift build 84s, swift test 9/9 pass.

Verified on the merged tree:

• Packages/NoopLocalAccess — 9/9 (the leg that went red).
• Packages/StrandAnalytics — 1160/1160.
• Strand/Screens/StressView.swift is app-target Swift that no default CI job compiles, so I built it: xcodegen generate + xcodebuild -scheme Strand -destination 'platform=macOS' CODE_SIGNING_ALLOWED=NO → BUILD SUCCEEDED.
• Android ./gradlew testFullDebugUnitTest — 3082 tests, 1 failure: SyncChipStateTest.lastSyncedAt_takesPriorityOverHistorySyncExperimental ("NoopApplication is not attached"), which also fails on a clean main and is unrelated to this branch.

Also worth flagging for triage: #413 is a strict subset of this PR. Its three commits are the first three here (feat(stress): add baseline-relative daytime-stress mode…, fix(stress): calibrate…, feat(android): Kotlin twin… — two of the three are patch-id-identical), and this branch adds three more on top. #413 can be closed as superseded.