Live Oura ring: overnight vitals (skin temp / RHR / HRV) never surface — banked IBI is stored but no hrSample is derived, so the nightly pipeline scores the night NULL #728

Summary

For a live Oura ring (oura-<uuid>, sourceKind = oura, active), the nightly skin-temperature reading — and, by the same mechanism, resting HR and HRV — never appears on the vital-detail screens. The Skin Temperature screen shows only WHOOP-imported days and stops at the last import.

Root cause: the ring banks overnight IBI (rrInterval) and skin temp (skinTempSample), but no overnight hrSample is ever produced from that IBI. The nightly analytics pipeline gates on hrSample, so with zero overnight HR the day-owner probe finds no data, ownership falls back to a device with nothing for that day, and the whole night scores NULL — taking skin temp down with it even though the skin-temp samples cover the full night.

Evidence (staging DB, live ring oura-5C4C0BF8-…, overnight 00:00–08:00 local)

hrSample for the ring exists only in daytime live-streaming windows (hours when the app was open and connected). Resulting dailyMetric rows for those days are under my-whoop-noop with skinTempDevC, restingHr, avgHrv, totalSleepMin all NULL.

Why it cascades

1. IntelligenceEngine.resolveDayOwner probes store.hrSamples(deviceId:, night window, limit:1) → 0 → the live ring is not a candidate-with-data → owner falls back (to my-whoop, which has no data those days).
2. The nightly funnel additionally requires guard hr.count >= 200 in the night window (IntelligenceEngine day loop) → fails regardless of owner.
3. skinTempDevC / restingHr / avgHrv land NULL.
4. The Skin Temperature vital screen (MetricExplorerView → Repository.exploreSeries(key:"skin_temp")) reads the per-day DailyMetric.skinTempDevC column + imported WHOOP metricSeries — neither gets a live-Oura value → the Oura days are blank.

Key insight

The overnight HR chart works because that path derives HR from the banked IBI at read time (#511). The daily analytics pipeline instead reads persisted hrSample rows, which are never materialized from the overnight IBI. The two paths disagree — display shows overnight HR, scoring sees none.

Where it lives (both platforms — parity)

• Storage mapping: Packages/WhoopStore/…/OuraStreamMapping.swift (+ Kotlin com.noop.oura.OuraStreamMapping) — banked IBI (0x60/0x80/0x6E) → .ibi → rrInterval only; live .hr push → hrSample. No banked-window HR derivation.
• Gate: Strand/Data/IntelligenceEngine.swift resolveDayOwner (HR presence probe) and the day loop's guard hr.count >= 200; Kotlin twins in com.noop.analytics / RegistryDayOwnerSource.

Scope / not-a-regression

• Not caused by the Oura sleep-persist work — sleep persists from the phase-code stream, independent of HR, so it correctly shows "Oura". Only the HR-gated vitals (skin temp / RHR / HRV) are affected.
• Pre-existing structural gap in the live-Oura path; affects the ring the moment it's the active device.

Proposed approach

Option A (recommended — the complete fix): derive + persist hrSample from the banked Oura IBI

When the banked overnight IBI is decoded and stored to rrInterval, also compute HR and persist hrSample under the same deviceId, anchored to ring-time (same anchor as the IBI, per #677 — never drain-arrival now):

• bpm = round(60000 / ibiMs), with the existing honesty guards (drop implausible bpm; already applied for live HR).
• Cadence: ~27k IBI/night is too dense to store 1:1 as HR; aggregate to a sane cadence (e.g. one HR per rolling window / per second) so hrSample volume matches the live path.
• Dedup: the daytime live .hr push already writes hrSample; the banked derivation should fill only the gap and dedup by ts so a window covered by both isn't double-counted.
• Parity: implement as byte-identical Swift/Kotlin twins with a pure, fixture-tested derivation (belongs in Packages / com.noop.oura, not the app layer).
• Payoff: overnight hrSample ≥ 200 in the night window → resolveDayOwner routes to the live ring → the funnel computes skinTempDevC, restingHr, avgHrv and scores the night. Lights up skin temp and RHR and HRV and proper day-ownership in one change.

Option B (narrower, less complete)

Teach resolveDayOwner's presence probe and the funnel's HR gate to treat rrInterval as HR presence for an Oura owner, and derive an in-memory HR series from IBI inside the funnel. Avoids new stored rows but spreads Oura-special-casing across analytics and still needs an HR series — Option A is cleaner and reusable.

Related follow-up (separate)

The skin_temp daily column is a deviation (DailyMetric.skinTempDevC, ±°C) while the WHOOP import metricSeries is absolute °C — so even once an Oura day scores, it would render on a different scale than the import rows in the readings table. Worth reconciling (own issue) so Oura and WHOOP skin temp read consistently.