perf(rescore): stop a post-sync pass re-scoring nights and cycles whose inputs did not change by Iskrata · Pull Request #2293 · ryanbr/noop

Iskrata · 2026-09-17T08:22:12Z

What this PR does

Two changes stop the post-sync re-score from repeating work whose inputs did not change. Most of the cost of a backgrounded pass came from these two places.

1. Sleep habits are learned from finished nights only. sleepNeedHours, sleepConsistency and habitualMidsleepSec are all in the day-cache config signature, and computeHabitualSleep read them from every banked session up to now. That includes tonight's session, which every sync re-banks while it is still growing. So each sync through a morning moved the consistency and midsleep, the signature changed, and the whole 21-night cache was dropped (configDropped(sleepNeedHours+sleepConsistency+habitualMidsleep)). computeHabitualSleep now takes finishedBefore: and the pass passes its local midnight. A night joins the learned history the day after it ends, when the window rolls anyway.

2. A closed sleep-to-sleep cycle keeps its Effort and calories. In .sleepOnset mode (the default), DayCycleIntelligenceIntegration.compute re-read each cycle's full day of 1 Hz heart rate from every owner on every pass. It then re-scored Effort and calories for all 21 cycles, although only the open cycle gains samples. Step counts already had a per-cycle cache. Effort and calories now have one too, keyed on the index-only hrFingerprint (count and newest timestamp) per owner, the same witness the day cache uses, plus resting HR, HRmax, method and profile.

Why

A phone log showed backgrounded passes of 8 813 s and 2 345 s running back to back, with scores arriving hours late. A backgrounded app only gets short execution windows, so a pass that costs seconds of CPU in the foreground takes hours of wall-clock time in the background.

I measured this by replaying analyzeRecent on a Mac against a copy of that phone's database (21 nights, Debug build, so compare the numbers with each other rather than with a phone):

Pass	Before	After
Cold (first pass of a process)	171 s	166 s
Again, nothing changed	96 s (`reused=0/21`, `configDropped(sleepConsistency+habitualMidsleep)`)	2.9 s (`reused=21/21`)
One more minute of heart rate today	16 s	7.9 s

In the last row, the score2 phase went from 5.9 s to 0.3 s. The time before the scoring loop was nearly all DayCycleIntelligenceIntegration.compute (6–12 s, measured with temporary timers). The detected nights, stages, and the resulting sleep sessions are unchanged by either commit.

Behaviour change

This is not only a speed-up. Learning from finished nights moves three user-visible numbers: sleepNeedHours, sleepConsistency and habitualMidsleepSec will differ slightly from what the same database produced before, for everyone, on upgrade. The most recently finished night is held out of the learned history for up to about a day, until the window rolls past it. The reasoning is that a night still being slept is not a habit yet, and learning from a session every sync re-banks while it grows is what produced the churn. Anyone picking up the open anchor half of #2350 should know habitualMidsleepSec moved underneath it.

The cycle load key names the profile's fields explicitly (UserProfile.cacheKey on both platforms, a test per field) rather than relying on String(describing:) / toString, whose format is not a contract.

Type of change

Bug fix (performance / battery)
Behaviour change (learned sleep habits, see above)

How it was tested

New StrandTests/HabitualSleepFinishedNightsTests: tonight's session, synced first to 04:00 and then to 09:30, does not change the learned midsleep or nightly hours.
The replay above, before and after, on the same database copy.
doc_comment_lint.py is clean, and parity_ratchet.py --base upstream/main --offline reports 0 errors.

Android. The Kotlin twin is in this PR:

IntelligenceEngine.computeHabitualSleep(finishedBefore) learns from finished nights only, through finishedSessions.
PhysiologicalStepCycleEngine keeps a per-cycle Effort and calories cache keyed by loadCacheKey, with the index-only WhoopRepository.hrUnionFingerprint as the HR witness.
Both platforms keep deciding when tonight's night joins the learned habits the same way.
Built and tested locally: the new RescoreUnchangedInputsTest covers both changes. The full suite has 6287 tests with 2 failures, both in RecoveryDriversTest (a half-tie rounding assertion), and they fail identically on unmodified main on this Mac.
The four Kotlin functions are recorded as platform_specific in parity_dispositions.json, because their Swift twins sit in the app layer (Strand/Data/), outside the governed roots.
parity_ratchet.py --offline reports 0 errors and the parity-governance suite passes under Python 3.12, as CI runs it.

Checklist

No new build warnings introduced
Follows the conventions in docs/CONTRIBUTING.md
I did not commit generated output (Strand.xcodeproj/) or any secrets/keystores

ryanbr · 2026-09-20T06:42:44Z

Thanks @Iskrata, this is careful work: a measured problem, a named cost, both
platforms in one change, and tests on each side. I checked the substance rather
than taking the write-up on trust, so here is what I verified and the one thing
standing in the way.

What holds up

The habitual-sleep change is parity-correct. Both platforms filter on
endTs < finishedBefore with finishedBefore = nowLocalMidnight. Swift applies it
inline on the deduped list, Kotlin routes it through finishedSessions as a test
seam. Same predicate, same cutoff, so the two cannot learn from different nights.

The load cache key is complete. The owner set is encoded in the witness
prefixes rather than left out, and resting HR, HRmax, effort method and profile are
all in the key. The witnesses really are index-only on both sides:
hrFingerprint is COUNT(*), COALESCE(MAX(ts), 0) and hrUnionFingerprint is the
countHrInWindow / maxHrTsInWindow pair, so a closed cycle costs two aggregates
instead of a day of rows.

The profile interpolation is value-based, which was my main worry. Swift
UserProfile is a public struct with no custom description and Kotlin's is a
data class, so both render their fields. An identity-based description would have
been stable within a process and therefore served stale calories after a mid-session
profile edit, with the cache looking like it worked.

The empty-witness path is consistent. When hrEndInclusive < onset the witness
is empty and the recompute reads nothing either, so both arrive at nil rather than
one of them caching an answer the other would not have produced.

One code note

The key's coverage of the profile rests on the DEFAULT description of both types.
If UserProfile ever gains a custom description or toString that omits a field,
the key silently stops witnessing it and the cache serves stale Effort and calories,
with nothing failing. Worth either a comment pinning that dependency where the key
is built, or keying on the fields explicitly so the compiler notices when one is
added. Not a change I would hold the PR for, but it is the part most likely to rot
quietly.

One thing worth naming

This is filed as performance, and it is, but learning only from finished nights also
moves user-visible numbers: sleepNeedHours, sleepConsistency and
habitualMidsleepSec will differ from what the same database produced before. The
reasoning is sound, a night still being slept is not a habit yet, and it is the right
call. It is a behaviour decision as well as a speed-up though, so it should be taken
as one rather than arrive as a side effect.

What is blocking it, which is not your doing

This branch is based on 8ea500a12, before #2348 landed. Your parity_twin_map.json
moves functions from 4453 to 4456, which is exactly right for the three functions
you add. Current main derives 4454, because #2348 added a Swift helper in a governed
root and the derived map was never refreshed. So on a rebase the derived count is
4457 against your checked-in 4456, and parity-governance reports a mismatch of one
function you never touched.

That is the failure mode the workflow header calls out, and the scheduled run on main
went red on it earlier today, so it is main that needs repairing rather than anything
here. I will sort that out first. Once main carries a correct authority again, a
rebase plus one more --refresh-derived on your side should bring this green, and I
will confirm the numbers here when it does.

Nothing above needs action from you yet beyond the profile-key note, which is your
call. The measurements, the replay method and the twin coverage are all exactly what
makes a change like this reviewable.

The scheduled parity-governance run on main went red this morning on test_checked_metadata_is_compact_v3_and_expands_losslessly: the checked-in authority no longer reproduced from the current sources. The cause was #2348, which added a Swift helper inside a governed root without a re-derive. Nothing went red at the time because the workflow deliberately excludes product source from its path filters, so the merge that caused the drift is never the one that reports it. The schedule exists for exactly that, and it did its job. The numbers move by that one function: functions 4453 to 4454, unpaired_functions 4107 to 4108. The baseline file is untouched and the refresh reports the same 300 known findings, so no debt changed hands. --refresh-derived alone refuses here, because the base's stored manifest cannot be reproduced at all, and --repair-stale-base cannot help either: repair is for a base whose governed state matches and whose metadata drifted, which is not this. So this is --refresh-derived --migrate-authority, which waives only the reproducibility of the base manifest and no semantic debt. Every one-sided declaration still needs its own issue-bound disposition, and the tool refuses to migrate onto anything but an exactly derived current authority. This was blocking an outside contributor: PR #2293 branched before #2348 and carries a correct authority for its own three additions, so on a rebase it would have reported a mismatch of one function it never touched. That is the failure the workflow header warns about, and this clears it. Verification: the parity-governance suite CI runs, 124 tests, OK.

ryanbr · 2026-09-20T06:51:50Z

Main is repaired, so this is unblocked. Reporting the numbers as promised.

0599d8a28 on main re-derives the authority: functions 4453 to 4454,
unpaired_functions 4107 to 4108, which is the single Swift helper #2348 added
inside a governed root without a re-derive. The baseline file is untouched and the
refresh reports the same 300 known findings, so no debt moved. The
parity-governance run on main is green again after being red on the 04:31
schedule.

The remedy was --refresh-derived --migrate-authority. For anyone who hits this
later: --repair-stale-base reads like the right flag from its description, but it
is for a base whose governed state matches and whose metadata drifted. Here the
base's stored manifest could not be reproduced at all, so there was no exact basis
to compare against. Migration waives only that reproducibility and no semantic
debt, and it refuses to run against anything but an exactly derived current
authority.

What that means for this branch: your 4453 to 4456 was correct for the three
functions you add, and the base underneath it has now moved by one. After a rebase
onto main the derived counts should be functions 4457 and unpaired_functions 4111,
so one more --refresh-derived should land you exactly there. If it comes out
anywhere else, say so rather than adjusting the file by hand, because that would
mean something other than the #2348 helper is in play.

The review above stands unchanged: the two changes are sound, the twins agree, and
the only open question is the profile-key fragility, which is yours to judge.

ryanbr · 2026-09-21T04:17:13Z

Reviewed at 5ef4775. Three things in here looked wrong on a first read and turned out to be fine, so let me record those first, because the names invite the wrong conclusion and the next reader will land in the same places.

hrUnionFingerprint is not a collapsed union. The name suggests one count across owners, which would be strictly weaker than Swift's per-owner loop: one source losing a row while another gains one leaves the total unchanged. It is not that. It iterates rawWhoopSourceIds and builds "$id=$count:$maxTs", the same per-owner shape Swift builds, and is named for the hrSamplesUnion it witnesses. The two platforms invalidate on the same events.
The windows match. Swift's hrEndInclusive = window.endExclusive - 1 against Kotlin's window.endExclusive - 1L.
"\(profile)" in the cache key is value-sensitive. My concern was that Profile is an @Published class, where interpolation gives a bare type name, so an edited age or weight would never invalidate the cache and a user changing their profile would keep stale calories forever. Different type: UserProfile is a struct, so reflection prints the stored values. Worth knowing the hazard exists one type away.

Also verified: Swift declines the cache when a fingerprint read failed (hasSuffix("=unread")), and the new cache.loads eviction mirrors the existing cache.cycles one so a cycle leaving the window cannot strand an entry. CI is 8 of 8 green.

1. This is a behaviour change, not only a performance one

computeHabitualSleep now filters endTs < nowLocalMidnight, so the most recently FINISHED night is held out of the learned history for up to about 24 hours. sleepConsistency, habitualMidsleepSec and sleepNeedHours will therefore shift slightly for everyone on upgrade.

I think the change is right. A night still being slept is not a habit, and learning from a session that every sync re-banks while it grows is what produced the churn in the first place. Your doc comments are honest about the mechanism. But the PR is typed "Bug fix (performance / battery)" and the body reads as a pure speedup, and this moves three user-visible numbers. Worth saying so in the description so it is on the record rather than discovered later. Note #2350's open anchor half touches habitualMidsleepSec as well, so whoever picks that up should know this moved underneath it.

2. Worth connecting to #2360

That is an open background-battery report on a 4.0, and the two costs there are distinct: the radio side, which is the history-offload protocol gap, and the app side. Your 8 813 s and 2 345 s passes are the app side, and 96 s down to 2.9 s on an unchanged re-pass is the most concrete battery improvement anyone has put up this week. The replay methodology, same database copy before and after, with the caveat that it is a Debug build so the numbers are comparable to each other and not to a phone, is exactly the right shape for this claim.

3. Minor

private static to static on computeHabitualSleep widens the surface for the test. Fine, worth one line saying that is why.
The key leans on String(describing:) of a struct. It works and it is value-sensitive, but the format is not a documented contract and it runs reflection per cycle per pass. UserProfile is Equatable; naming the fields explicitly would be sturdier and cheaper.

Housekeeping

Dirty, 32 behind, carrying a parity_twin_map.json stamp derived on the old base. Main's authority was migrated earlier today in f8ada93f6, so a rebase plus a plain --refresh-derived re-derives cleanly now, with no --migrate-authority. That would not have worked before today, so if you tried and saw a base-authority error, that was main and not you.

One pattern across your three open PRs: this, #2284 and #2285 all report the same two RecoveryDriversTest half-tie failures, each verified unrelated by stashing. Three reports is a pattern rather than three coincidences, and that test being environment-sensitive on your machine probably deserves its own issue so the next person does not have to re-derive that it is noise.

Approving after the rebase, with point 1 in the description.

Iskrata · 2026-09-21T10:35:39Z

Rebased onto main (73a6004ba), and:

Behaviour change. It's in the description now, as its own section and a second type box. It names sleepNeedHours, sleepConsistency and habitualMidsleepSec, says the most recent night is held out for up to a day, and flags Body clock dial: 'ideal window' is driven by daytime HR timing, not sleep #2350's anchor half.
Profile key. It's keyed on the fields now: UserProfile.cacheKey on both platforms names every stored field (doubles by bit pattern, so no reflection), with a test per field on each side. The two types live in differently named files, so they're recorded as a cross-file twin pair in parity_dispositions.json.
computeHabitualSleep visibility. Now has a one-line comment saying it's internal only so the test can drive finishedBefore.
Background Battery consumption #2360. Noted. I'll leave the battery thread to you to connect.

On RecoveryDriversTest: it's reproducible on clean upstream/main here (Apple Silicon, JDK 17). Both failures assert an exact -0.5 at a hand-tuned HRV input, and this machine lands on -0.4999999999999929. Kotlin's exp/ln go to java.lang.Math, which may use CPU-specific intrinsics within 1 ulp; only StrictMath is bit-reproducible. So an input tuned to hit the tie on CI's x86 runner misses it on arm64. Glad to open a separate issue if you'd like one. I'd suggest having the test search for the tie input at runtime rather than hardcoding it.

Locally: UserProfileCacheKeyTests, HabitualSleepFinishedNightsTests and Kotlin RescoreUnchangedInputsTest (3) all pass.

…ync stops dropping the day cache

…ies instead of re-reading its heart rate every pass

… and reuse a closed cycle's Effort and calories

…scription String(describing:) of the struct was value-sensitive but its format is not a contract and it ran reflection per cycle per pass. UserProfile.cacheKey names every stored field (bit patterns for doubles) on both platforms, with a test per field.

…ep is internal

…e toggle ryanbr#2293's day-cycle load cache keys a cycle's Effort and calories on the window, the per-owner HR witness and the scoring profile. Once the MET-calories toggle routes a cycle's calories through the ring's MET series, that key cannot see what the figure depends on: - a later drain that banks MET minutes inside an ended window leaves the HR witness unchanged, so the cache keeps serving calories from the thinner stream (or a withheld nil, when the first pass was under the floor); - a toggle flip over unchanged data matches the entry cached under the other setting and serves the previous mode's figure. Both platforms now append a MET witness to the key: `met=off` when the toggle is off, otherwise `met=<owner>=<count>:<maxTs>` from an index-only aggregate over ouraMetSample, the same shape as the HR witness. Swift adds WhoopStore.ouraMetFingerprint(deviceId:from:to:), injected into the fold as MetFingerprint beside MetReader, and an unread witness never serves a cached load. Kotlin adds the countOuraMetInWindow / maxOuraMetTsInWindow DAO pair and WhoopRepository.ouraMetFingerprint, and loadCacheKey takes the witness. The rebase onto ryanbr#2293 moved the fold's MET-vs-HR decision into the cache-miss branch as cycleCalories() on both platforms, unchanged in behaviour. Tests: OuraMetStoreTests fingerprint (count/maxTs, inclusive bounds, per device, moves on an in-window insert); DayCycleRecoveryTests and DayCycleMetCaloriesTest each gain "MET banked after a pass is not served from the cache" and "a toggle flip over unchanged data rescores the cycle"; RescoreUnchangedInputsTest pins the witness in the key; Kotlin repo fingerprint. With the witness replaced by a constant, 4 of 6 DayCycleMetCaloriesTest cases fail. Parity: loadCacheKey/8 replaces /7 in the dispositions, the two DAO primitives are platform_specific like their HR counterparts; ratchet 0 errors, ledger no new findings. Refs ryanbr#2242 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y9RCdbENSxgnGFTikJPbBq

…e toggle ryanbr#2293's day-cycle load cache keys a cycle's Effort and calories on the window, the per-owner HR witness and the scoring profile. Once the MET-calories toggle routes a cycle's calories through the ring's MET series, that key cannot see what the figure depends on: - a later drain that banks MET minutes inside an ended window leaves the HR witness unchanged, so the cache keeps serving calories from the thinner stream (or a withheld nil, when the first pass was under the floor); - a toggle flip over unchanged data matches the entry cached under the other setting and serves the previous mode's figure. Both platforms now append a MET witness to the key: `met=off` when the toggle is off, otherwise `met=<owner>=<count>:<maxTs>` from an index-only aggregate over ouraMetSample, the same shape as the HR witness. Swift adds WhoopStore.ouraMetFingerprint(deviceId:from:to:), injected into the fold as MetFingerprint beside MetReader, and an unread witness never serves a cached load. Kotlin adds the countOuraMetInWindow / maxOuraMetTsInWindow DAO pair and WhoopRepository.ouraMetFingerprint, and loadCacheKey takes the witness. The rebase onto ryanbr#2293 moved the fold's MET-vs-HR decision into the cache-miss branch as cycleCalories() on both platforms, unchanged in behaviour. Tests: OuraMetStoreTests fingerprint (count/maxTs, inclusive bounds, per device, moves on an in-window insert); DayCycleRecoveryTests and DayCycleMetCaloriesTest each gain "MET banked after a pass is not served from the cache" and "a toggle flip over unchanged data rescores the cycle"; RescoreUnchangedInputsTest pins the witness in the key; Kotlin repo fingerprint. With the witness replaced by a constant, 4 of 6 DayCycleMetCaloriesTest cases fail. Parity: loadCacheKey/8 replaces /7 in the dispositions, the two DAO primitives are platform_specific like their HR counterparts; ratchet 0 errors, ledger no new findings. Refs ryanbr#2242 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y9RCdbENSxgnGFTikJPbBq (cherry picked from commit a2031f9)

…e toggle ryanbr#2293's day-cycle load cache keys a cycle's Effort and calories on the window, the per-owner HR witness and the scoring profile. Once the MET-calories toggle routes a cycle's calories through the ring's MET series, that key cannot see what the figure depends on: - a later drain that banks MET minutes inside an ended window leaves the HR witness unchanged, so the cache keeps serving calories from the thinner stream (or a withheld nil, when the first pass was under the floor); - a toggle flip over unchanged data matches the entry cached under the other setting and serves the previous mode's figure. Both platforms now append a MET witness to the key: `met=off` when the toggle is off, otherwise `met=<owner>=<count>:<maxTs>` from an index-only aggregate over ouraMetSample, the same shape as the HR witness. Swift adds WhoopStore.ouraMetFingerprint(deviceId:from:to:), injected into the fold as MetFingerprint beside MetReader, and an unread witness never serves a cached load. Kotlin adds the countOuraMetInWindow / maxOuraMetTsInWindow DAO pair and WhoopRepository.ouraMetFingerprint, and loadCacheKey takes the witness. The rebase onto ryanbr#2293 moved the fold's MET-vs-HR decision into the cache-miss branch as cycleCalories() on both platforms, unchanged in behaviour. Tests: OuraMetStoreTests fingerprint (count/maxTs, inclusive bounds, per device, moves on an in-window insert); DayCycleRecoveryTests and DayCycleMetCaloriesTest each gain "MET banked after a pass is not served from the cache" and "a toggle flip over unchanged data rescores the cycle"; RescoreUnchangedInputsTest pins the witness in the key; Kotlin repo fingerprint. With the witness replaced by a constant, 4 of 6 DayCycleMetCaloriesTest cases fail. Parity: loadCacheKey/8 replaces /7 in the dispositions, the two DAO primitives are platform_specific like their HR counterparts; ratchet 0 errors, ledger no new findings. Refs ryanbr#2242 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y9RCdbENSxgnGFTikJPbBq

…default-off Experimental toggle (ryanbr#2242) [1/7] feat(analytics): day energy from a MET stream — Oura's documented rule, no fitted constant Adds Calories.estimateDayEnergyFromMET (Swift) / estimateDayEnergyFromMet (Kotlin): active = Σ_{met ≥ 1.5} (met − 1.5) × 0.0175 kcal·kg⁻¹·min⁻¹ × weight over the day's samples — Oura's support wording ("the portion that exceeds 1.5 MET") at the standard MET→kcal definition (1 MET = 3.5 ml O₂·kg⁻¹·min⁻¹). Resting is the same revised Harris–Benedict the HR path uses, scaled by covered seconds; coverage is reported over the window the caller passes so today's partial day is judged against elapsed hours. Missing minutes are unknown — never extrapolated to activity, never banked as rest. The rule was identified, not fitted: on the Oura export's own per-minute MET series it reproduces active_calories with r = 1.0000 and 0.6 kcal/day RMSE over 75 current-era days (r 0.9999 / 3 kcal over 396 pre-2025 days), zero intercept, the only input being the wearer's weight. A re-served minute counts once. The ring's timestamps go through a per-session 0x13 anchor, so a record served again under a second session lands 2–5 s off its first copy, while the ring's own minute grid steps back a second between records (a real successor starts 59–61 s on). Half a period tells them apart: two samples are the same minute when |Δ| × 2 < min(epochS), and the walk compares against the last counted start. Kotlin is pinned to Swift by oracle: the real Calories enum compiled standalone over a case spread (84 output lines) (four profiles × empty / rest floor / bout / 1.5 threshold edge / decoder boundary / partial coverage / 120 s cadence / duplicate ts / 3-s twins / 59-s phase steps / window edges / partial today / DST 23 h / clamp / bad epochs / realistic day), stdout pasted verbatim into MetCaloriesOracleTest. MetCaloriesTests pins the Swift side with hand-derived literals. [2/7] feat(store): persist the Oura ring's per-minute MET series — ouraMetSample, both platforms Until now the 0x50 MET stream existed only as the diagnostic JSONL sidecar, so nothing scored could read it. GRDB v47-oura-met-sample / Room MIGRATION_40_41 (schema 41) add ouraMetSample(deviceId, ts, met REAL, state, epochS) keyed (deviceId, ts), column order identical on both sides and pinned in schema_oracle.json (both copies). epochS is carried per row so a cadence other than 60 s scales the estimate rather than skewing it. Insert drops a re-served twin: the (deviceId, ts) key alone does not catch a record served again under another session anchor (it lands a few seconds off), so the insert reads the stored rows around the batch and drops any incoming sample within half a period of a stored one or of one accepted earlier in the batch (earlier start wins, lower MET on an exact tie). The pure rule is OuraMetSample.droppingTwins / OuraMetSampleEntity.droppingTwins, same integer test as the estimator, testable without a database. A 59-s phase-step successor is kept. Swift: OuraMetStore (insert, bounded range read, count), the table on DeviceRegistryStore.deviceScopedTables so forgetting a ring clears it. Android: entity, DAO insert/read/delete, DeviceRegistry.deleteDeviceData wiring, repository wrappers, the committed v41 Room schema for the upgrade test. Tests: OuraMetStoreTests (Swift), OuraMetSampleMigrationTest (Kotlin, incl. the twin rule); SchemaOracleTest / WhoopDatabaseUpgradeTest / the device-scoped-table guards on both sides. [3/7] feat(analytics): analyzeDay scores calories from the owner's MET series when supplied analyzeDay gains dayMet (the day owner's own per-minute MET samples), dayMetNow (so today's coverage is judged against elapsed hours, not 24 h) and a caloriesDiag sink. Rule: MET samples present ⇒ activeKcalEst = estimateDayEnergyFromMET(...).totalKcal when the stream covers ≥ 50 % of the window; below that the estimate is withheld (nil) rather than substituted by the HR path, which on a ring day runs over sparse banked HR and does not track Oura's number (r ≈ −0.1). nil/empty dayMet keeps the HR path byte-identical — every WHOOP and pure-function caller is unchanged. One always-on log line per MET day. Both platforms; AnalyticsEngineMetCaloriesTests / AnalyticsEngineMetCaloriesTest pin the selection, the withhold, the elapsed-hours window and the byte-identical no-MET path. [4/7] feat(oura): score active calories from the ring's MET records, behind an Experimental toggle The toggle (iOS AppModel.ouraMetCaloriesKey / Android NoopPrefs.KEY_OURA_MET_CALORIES, default OFF) gates: • the writer — OuraLiveSource fans each anchored 0x50 record out to ouraMetSample, one row per minute, next to the existing JSONL sidecar call. The record's timestamp is the END of its last sample: fitted against Oura's own per-minute export, every record length n matched best at exactly −n minutes (85 % exact minute matches, r 0.90, vs 23 % / 0.57 read forward), so sample i starts at utc − (n − i)·60 and a record straddling local midnight lands its minutes on the right days. • the read — IntelligenceEngine reads the day owner's rows (registry active id, calendar- day scoped like dayHr) and hands them to analyzeDay as dayMet, with dayMetNow = now; the calories line goes through the same per-day diag recorder as the Effort funnel. • the day-cycle fold — DayCycleIntelligenceIntegration (and Android's PhysiologicalStepCycleEngine) recomputed Keytel for every cycle and wrote it over activeKcalEst, which would have hidden the MET decision on any phone with a day-cycle history. The fold now takes the same decision analyzeDay takes, over its own window [onset, min(endExclusive, now)): covered → the MET total, thin → withheld with no HR substitute, no rows or toggle off → Keytel byte for byte. A "stepsCycle calories … path=met" trace line names the decision. The toggle joins the day-cache config signature on both platforms so a flip re-scores every cached day. Android threads the flag Context-free like spo2CandidateDisplay, carries it into the pass on a field and reads the MET rows inside readDaySkinAndWristOff, and hands the fold a Boolean rather than a lambda — all to stay inside analyzeRecentOnCpu's JaCoCo budget (a new suspend call there spills ~0.7 K instructions of continuation state). Settings gains "Experimental · Oura Calories" (iOS card / Android row), shown only with an Oura ring, caption stating the method, the < 50 % coverage withhold, that Oura re-scores a logged workout's minutes by activity type (NOOP does not, so such a day reads lower), and that turning it on starts storing MET samples. Strings in de/es/fr/pt-PT plus it/pl/ru/zh-Hans/ zh-Hant (iOS) and pl/ru/zh (Android). Docs: OURA_PROTOCOL.md §6.13 (day-sum validation of the 0x50 decode, end-of-record timestamps, the formula); README Oura table "Active calories". OFF keeps both the DB and every score byte-identical. Tests: DayCacheConfigFieldTests / DayCacheConfigFieldTest; DayCycleRecoveryTests (Swift, xcodebuild test) and DayCycleMetCaloriesTest (Kotlin, Robolectric + Room) on a seeded 8-h main sleep: covered cycle carries the MET total, 10 %-covered is withheld, no reader / empty table = Keytel. [5/7] feat(oura): pair the MET store with its twins in the parity ledger Review follow-up. The parity ledger flagged the MET store's Kotlin reads and writes as one-sided; run in full it also flagged the MET toggle's arity changes to existing functions, which read as new identities. Paired, with twin claims where the ledger reads them: - `WhoopRepository.insertOuraMetSamples` <-> `WhoopStore.insertOuraMetSamples` - `WhoopRepository.ouraMetSamples` <-> `WhoopStore.ouraMetSamples` (on the Repository, since the DAO's `@Query` puts its declaration outside the claim's attach window) - `AnalyticsEngine.analyzeDay`, `IntelligenceEngine.analyzeRecent` and `DayCycleIntelligenceIntegration.compute`, whose parameter lists grew here Removed: `WhoopStore.ouraMetSampleCount` and `WhoopDao.countOuraMetFor`. Neither had a production caller (the Kotlin one had no caller at all); the store tests count through `ouraMetSamples` instead. `platform_specific` dispositions for what is Kotlin-only by construction: the Room `@Insert` and `@Query` primitives under the paired Repository functions, the per-table forget-device delete (Swift clears the table through the `DeviceRegistryStore` name list), the Room migration override (its GRDB twin is the `v47-oura-met-sample` closure, pinned by the shared schema oracle), and the two JVM 64 KiB extractions `readDaySkinAndWristOff` and `PhysiologicalStepCycleEngine.compute`. The authority is re-derived with `--migrate-authority` because `main` at 5783c49 no longer reproduces its stored one. Verified: `parity_ledger.py` OK; `parity_ratchet.py --migrate-authority` 0 errors; `test_parity_*` 180 OK; StrandAnalytics 2068/0; WhoopStore 617/0; macOS `StrandTests` (DayCacheConfigField, DayCycleRecovery) 17/0; `NOOPiOS` builds; Android 6402 tests, the 8 failures reproduce identically on `upstream/main`; doc lint and `i18n_audit --ci` clean. [6/7] doc(calories): say at the MET assignment that activeKcalEst holds a total Review follow-up. `activeKcalEst = met.totalKcal` reads like a category error: the estimate carries the active share separately. It is correct, because the field is a pre-existing misnomer and the HR path's `estimateDayCalories` already stores `estimateDayEnergy(...).totalKcal` in it. That is now written at both `analyzeDay` sites, so the next reader does not have to work it out again. Comment only. [7/7] fix(oura): key an ended cycle's MET calories on the MET series and the toggle the per-owner HR witness and the scoring profile. Once the MET-calories toggle routes a cycle's calories through the ring's MET series, that key cannot see what the figure depends on: - a later drain that banks MET minutes inside an ended window leaves the HR witness unchanged, so the cache keeps serving calories from the thinner stream (or a withheld nil, when the first pass was under the floor); - a toggle flip over unchanged data matches the entry cached under the other setting and serves the previous mode's figure. Both platforms now append a MET witness to the key: `met=off` when the toggle is off, otherwise `met=<owner>=<count>:<maxTs>` from an index-only aggregate over ouraMetSample, the same shape as the HR witness. Swift adds WhoopStore.ouraMetFingerprint(deviceId:from:to:), injected into the fold as MetFingerprint beside MetReader, and an unread witness never serves a cached load. Kotlin adds the countOuraMetInWindow / maxOuraMetTsInWindow DAO pair and WhoopRepository.ouraMetFingerprint, and loadCacheKey takes the witness. The rebase onto ryanbr#2293 moved the fold's MET-vs-HR decision into the cache-miss branch as cycleCalories() on both platforms, unchanged in behaviour. Tests: OuraMetStoreTests fingerprint (count/maxTs, inclusive bounds, per device, moves on an in-window insert); DayCycleRecoveryTests and DayCycleMetCaloriesTest each gain "MET banked after a pass is not served from the cache" and "a toggle flip over unchanged data rescores the cycle"; RescoreUnchangedInputsTest pins the witness in the key; Kotlin repo fingerprint. With the witness replaced by a constant, 4 of 6 DayCycleMetCaloriesTest cases fail. Parity: loadCacheKey/8 replaces /7 in the dispositions, the two DAO primitives are platform_specific like their HR counterparts; ratchet 0 errors, ledger no new findings. Rebase onto main at ca24978: main's ryanbr#2472 grew analyzeRecentOnCpu to 55,559 instrumented bytes, which left 141 against the 55,700 JaCoCo budget, and this change measured 239. The day's MET rows now reach analyzeDay through a pass field (ouraMetDayForPass, written by readDaySkinAndWristOff), not through the DaySkinReads holder. On the holder, the holder stayed live across every later suspension point of the day loop and was spilled and restored at each one. The helper derives the calendar-day window from dayStart itself (same 14-parameter arity). Measured 55,669. Refs ryanbr#2242 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y9RCdbENSxgnGFTikJPbBq Claude-Session: https://claude.ai/code/session_01484Ef871BnAuniyDJYYHoV Claude-Session: https://claude.ai/code/session_01RgqTwKfXLXzKo81ECb4aDz Claude-Session: https://claude.ai/code/session_01RuJdFu6iobsWfRtPYUR4C8

…default-off Experimental toggle (ryanbr#2242) [1/7] feat(analytics): day energy from a MET stream — Oura's documented rule, no fitted constant Adds Calories.estimateDayEnergyFromMET (Swift) / estimateDayEnergyFromMet (Kotlin): active = Σ_{met ≥ 1.5} (met − 1.5) × 0.0175 kcal·kg⁻¹·min⁻¹ × weight over the day's samples — Oura's support wording ("the portion that exceeds 1.5 MET") at the standard MET→kcal definition (1 MET = 3.5 ml O₂·kg⁻¹·min⁻¹). Resting is the same revised Harris–Benedict the HR path uses, scaled by covered seconds; coverage is reported over the window the caller passes so today's partial day is judged against elapsed hours. Missing minutes are unknown — never extrapolated to activity, never banked as rest. The rule was identified, not fitted: on the Oura export's own per-minute MET series it reproduces active_calories with r = 1.0000 and 0.6 kcal/day RMSE over 75 current-era days (r 0.9999 / 3 kcal over 396 pre-2025 days), zero intercept, the only input being the wearer's weight. A re-served minute counts once. The ring's timestamps go through a per-session 0x13 anchor, so a record served again under a second session lands 2–5 s off its first copy, while the ring's own minute grid steps back a second between records (a real successor starts 59–61 s on). Half a period tells them apart: two samples are the same minute when |Δ| × 2 < min(epochS), and the walk compares against the last counted start. Kotlin is pinned to Swift by oracle: the real Calories enum compiled standalone over a case spread (84 output lines) (four profiles × empty / rest floor / bout / 1.5 threshold edge / decoder boundary / partial coverage / 120 s cadence / duplicate ts / 3-s twins / 59-s phase steps / window edges / partial today / DST 23 h / clamp / bad epochs / realistic day), stdout pasted verbatim into MetCaloriesOracleTest. MetCaloriesTests pins the Swift side with hand-derived literals. [2/7] feat(store): persist the Oura ring's per-minute MET series — ouraMetSample, both platforms Until now the 0x50 MET stream existed only as the diagnostic JSONL sidecar, so nothing scored could read it. GRDB v47-oura-met-sample / Room MIGRATION_40_41 (schema 41) add ouraMetSample(deviceId, ts, met REAL, state, epochS) keyed (deviceId, ts), column order identical on both sides and pinned in schema_oracle.json (both copies). epochS is carried per row so a cadence other than 60 s scales the estimate rather than skewing it. Insert drops a re-served twin: the (deviceId, ts) key alone does not catch a record served again under another session anchor (it lands a few seconds off), so the insert reads the stored rows around the batch and drops any incoming sample within half a period of a stored one or of one accepted earlier in the batch (earlier start wins, lower MET on an exact tie). The pure rule is OuraMetSample.droppingTwins / OuraMetSampleEntity.droppingTwins, same integer test as the estimator, testable without a database. A 59-s phase-step successor is kept. Swift: OuraMetStore (insert, bounded range read, count), the table on DeviceRegistryStore.deviceScopedTables so forgetting a ring clears it. Android: entity, DAO insert/read/delete, DeviceRegistry.deleteDeviceData wiring, repository wrappers, the committed v41 Room schema for the upgrade test. Tests: OuraMetStoreTests (Swift), OuraMetSampleMigrationTest (Kotlin, incl. the twin rule); SchemaOracleTest / WhoopDatabaseUpgradeTest / the device-scoped-table guards on both sides. [3/7] feat(analytics): analyzeDay scores calories from the owner's MET series when supplied analyzeDay gains dayMet (the day owner's own per-minute MET samples), dayMetNow (so today's coverage is judged against elapsed hours, not 24 h) and a caloriesDiag sink. Rule: MET samples present ⇒ activeKcalEst = estimateDayEnergyFromMET(...).totalKcal when the stream covers ≥ 50 % of the window; below that the estimate is withheld (nil) rather than substituted by the HR path, which on a ring day runs over sparse banked HR and does not track Oura's number (r ≈ −0.1). nil/empty dayMet keeps the HR path byte-identical — every WHOOP and pure-function caller is unchanged. One always-on log line per MET day. Both platforms; AnalyticsEngineMetCaloriesTests / AnalyticsEngineMetCaloriesTest pin the selection, the withhold, the elapsed-hours window and the byte-identical no-MET path. [4/7] feat(oura): score active calories from the ring's MET records, behind an Experimental toggle The toggle (iOS AppModel.ouraMetCaloriesKey / Android NoopPrefs.KEY_OURA_MET_CALORIES, default OFF) gates: • the writer — OuraLiveSource fans each anchored 0x50 record out to ouraMetSample, one row per minute, next to the existing JSONL sidecar call. The record's timestamp is the END of its last sample: fitted against Oura's own per-minute export, every record length n matched best at exactly −n minutes (85 % exact minute matches, r 0.90, vs 23 % / 0.57 read forward), so sample i starts at utc − (n − i)·60 and a record straddling local midnight lands its minutes on the right days. • the read — IntelligenceEngine reads the day owner's rows (registry active id, calendar- day scoped like dayHr) and hands them to analyzeDay as dayMet, with dayMetNow = now; the calories line goes through the same per-day diag recorder as the Effort funnel. • the day-cycle fold — DayCycleIntelligenceIntegration (and Android's PhysiologicalStepCycleEngine) recomputed Keytel for every cycle and wrote it over activeKcalEst, which would have hidden the MET decision on any phone with a day-cycle history. The fold now takes the same decision analyzeDay takes, over its own window [onset, min(endExclusive, now)): covered → the MET total, thin → withheld with no HR substitute, no rows or toggle off → Keytel byte for byte. A "stepsCycle calories … path=met" trace line names the decision. The toggle joins the day-cache config signature on both platforms so a flip re-scores every cached day. Android threads the flag Context-free like spo2CandidateDisplay, carries it into the pass on a field and reads the MET rows inside readDaySkinAndWristOff, and hands the fold a Boolean rather than a lambda — all to stay inside analyzeRecentOnCpu's JaCoCo budget (a new suspend call there spills ~0.7 K instructions of continuation state). Settings gains "Experimental · Oura Calories" (iOS card / Android row), shown only with an Oura ring, caption stating the method, the < 50 % coverage withhold, that Oura re-scores a logged workout's minutes by activity type (NOOP does not, so such a day reads lower), and that turning it on starts storing MET samples. Strings in de/es/fr/pt-PT plus it/pl/ru/zh-Hans/ zh-Hant (iOS) and pl/ru/zh (Android). Docs: OURA_PROTOCOL.md §6.13 (day-sum validation of the 0x50 decode, end-of-record timestamps, the formula); README Oura table "Active calories". OFF keeps both the DB and every score byte-identical. Tests: DayCacheConfigFieldTests / DayCacheConfigFieldTest; DayCycleRecoveryTests (Swift, xcodebuild test) and DayCycleMetCaloriesTest (Kotlin, Robolectric + Room) on a seeded 8-h main sleep: covered cycle carries the MET total, 10 %-covered is withheld, no reader / empty table = Keytel. [5/7] feat(oura): pair the MET store with its twins in the parity ledger Review follow-up. The parity ledger flagged the MET store's Kotlin reads and writes as one-sided; run in full it also flagged the MET toggle's arity changes to existing functions, which read as new identities. Paired, with twin claims where the ledger reads them: - `WhoopRepository.insertOuraMetSamples` <-> `WhoopStore.insertOuraMetSamples` - `WhoopRepository.ouraMetSamples` <-> `WhoopStore.ouraMetSamples` (on the Repository, since the DAO's `@Query` puts its declaration outside the claim's attach window) - `AnalyticsEngine.analyzeDay`, `IntelligenceEngine.analyzeRecent` and `DayCycleIntelligenceIntegration.compute`, whose parameter lists grew here Removed: `WhoopStore.ouraMetSampleCount` and `WhoopDao.countOuraMetFor`. Neither had a production caller (the Kotlin one had no caller at all); the store tests count through `ouraMetSamples` instead. `platform_specific` dispositions for what is Kotlin-only by construction: the Room `@Insert` and `@Query` primitives under the paired Repository functions, the per-table forget-device delete (Swift clears the table through the `DeviceRegistryStore` name list), the Room migration override (its GRDB twin is the `v47-oura-met-sample` closure, pinned by the shared schema oracle), and the two JVM 64 KiB extractions `readDaySkinAndWristOff` and `PhysiologicalStepCycleEngine.compute`. The authority is re-derived with `--migrate-authority` because `main` at 5783c49 no longer reproduces its stored one. Verified: `parity_ledger.py` OK; `parity_ratchet.py --migrate-authority` 0 errors; `test_parity_*` 180 OK; StrandAnalytics 2068/0; WhoopStore 617/0; macOS `StrandTests` (DayCacheConfigField, DayCycleRecovery) 17/0; `NOOPiOS` builds; Android 6402 tests, the 8 failures reproduce identically on `upstream/main`; doc lint and `i18n_audit --ci` clean. [6/7] doc(calories): say at the MET assignment that activeKcalEst holds a total Review follow-up. `activeKcalEst = met.totalKcal` reads like a category error: the estimate carries the active share separately. It is correct, because the field is a pre-existing misnomer and the HR path's `estimateDayCalories` already stores `estimateDayEnergy(...).totalKcal` in it. That is now written at both `analyzeDay` sites, so the next reader does not have to work it out again. Comment only. [7/7] fix(oura): key an ended cycle's MET calories on the MET series and the toggle the per-owner HR witness and the scoring profile. Once the MET-calories toggle routes a cycle's calories through the ring's MET series, that key cannot see what the figure depends on: - a later drain that banks MET minutes inside an ended window leaves the HR witness unchanged, so the cache keeps serving calories from the thinner stream (or a withheld nil, when the first pass was under the floor); - a toggle flip over unchanged data matches the entry cached under the other setting and serves the previous mode's figure. Both platforms now append a MET witness to the key: `met=off` when the toggle is off, otherwise `met=<owner>=<count>:<maxTs>` from an index-only aggregate over ouraMetSample, the same shape as the HR witness. Swift adds WhoopStore.ouraMetFingerprint(deviceId:from:to:), injected into the fold as MetFingerprint beside MetReader, and an unread witness never serves a cached load. Kotlin adds the countOuraMetInWindow / maxOuraMetTsInWindow DAO pair and WhoopRepository.ouraMetFingerprint, and loadCacheKey takes the witness. The rebase onto ryanbr#2293 moved the fold's MET-vs-HR decision into the cache-miss branch as cycleCalories() on both platforms, unchanged in behaviour. Tests: OuraMetStoreTests fingerprint (count/maxTs, inclusive bounds, per device, moves on an in-window insert); DayCycleRecoveryTests and DayCycleMetCaloriesTest each gain "MET banked after a pass is not served from the cache" and "a toggle flip over unchanged data rescores the cycle"; RescoreUnchangedInputsTest pins the witness in the key; Kotlin repo fingerprint. With the witness replaced by a constant, 4 of 6 DayCycleMetCaloriesTest cases fail. Parity: loadCacheKey/8 replaces /7 in the dispositions, the two DAO primitives are platform_specific like their HR counterparts; ratchet 0 errors, ledger no new findings. Rebase onto main at ca24978: main's ryanbr#2472 grew analyzeRecentOnCpu to 55,559 instrumented bytes, which left 141 against the 55,700 JaCoCo budget, and this change measured 239. The day's MET rows now reach analyzeDay through a pass field (ouraMetDayForPass, written by readDaySkinAndWristOff), not through the DaySkinReads holder. On the holder, the holder stayed live across every later suspension point of the day loop and was spilled and restored at each one. The helper derives the calendar-day window from dayStart itself (same 14-parameter arity). Measured 55,669. Refs ryanbr#2242 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y9RCdbENSxgnGFTikJPbBq Claude-Session: https://claude.ai/code/session_01484Ef871BnAuniyDJYYHoV Claude-Session: https://claude.ai/code/session_01RgqTwKfXLXzKo81ECb4aDz Claude-Session: https://claude.ai/code/session_01RuJdFu6iobsWfRtPYUR4C8 Claude-Session: https://claude.ai/code/session_01QUwfZ8hUzmV6ScwZcuaTAr

…isagree WhoopRepository carried two functions computing the same value. Issue #2566. hrUnionFingerprint/3 line 1185, from #2293 hrFingerprintWindowUnion/3 line 728, which I added in #2543 Same signature, same rawWhoopSourceIds walk, same COUNT plus MAX per id. They differed only in how they punctuated the result: "id=count:maxTs" joined with a comma against "id:count:maxTs" joined with a pipe. Neither encoding is observable. StressLensCache is an in-memory object holding a single key, and PhysiologicalStepCycleEngine's loadCache is a plain HashMap field of a private data class. Nothing persists either string or sends it anywhere, so both doc comments were right that the format is free to change. The redundancy was not the risk. Two witnesses of one fact that are allowed to drift is the risk, and the fact they witness is whether cached scoring work can be reused. Teach one union to walk an extra id or carry a third aggregate and the other keeps answering the older question, silently. So: hrFingerprintWindowUnion is gone, the daytime stress lens memo reads hrUnionFingerprint, and hrUnionFingerprint now calls hrFingerprintWindow for each id rather than repeating the two DAO reads inline. One union, one encoding, one per-id read. The cycle load cache keeps the exact value it had. Strand/Data/Repository.swift referenced the deleted function as its Kotlin twin, so that pointer moves to the survivor. Both sides now also say what kind of twin this is: each compares its own value against its own previous value, neither is persisted or transmitted, and the two encode the same facts differently. There is no byte-identity contract here and no oracle asserting one. Without that note the next reader could take "twin" for the usual byte-level pair this repository means by the word and align the encodings believing they were repairing something. Neither union had a single test, which is how a duplicate survived review. HrUnionFingerprintTest pins the property that motivated the union at all: a row landing under an alias id or under the canonical id must move the witness even when the active id is untouched (#908). A fingerprint keyed on the active id alone passes a naive equality check and fails these. The stubbed DAO throws on any method other than the two index aggregates, so a row fetch creeping into the cheap path fails too. Mutation-verified rather than assumed. Replacing the union walk with the bare active id reddens 4 of 6; dropping maxTs from each entry reddens a different 4 of 6. The survivors are explainable in both cases: stableWhenNothingChanged only asserts determinism, and canonicalActiveIsNotDuplicated sets the active id to the canonical one, where the union and the single id genuinely coincide.

…default-off Experimental toggle (ryanbr#2242) [1/7] feat(analytics): day energy from a MET stream — Oura's documented rule, no fitted constant Adds Calories.estimateDayEnergyFromMET (Swift) / estimateDayEnergyFromMet (Kotlin): active = Σ_{met ≥ 1.5} (met − 1.5) × 0.0175 kcal·kg⁻¹·min⁻¹ × weight over the day's samples — Oura's support wording ("the portion that exceeds 1.5 MET") at the standard MET→kcal definition (1 MET = 3.5 ml O₂·kg⁻¹·min⁻¹). Resting is the same revised Harris–Benedict the HR path uses, scaled by covered seconds; coverage is reported over the window the caller passes so today's partial day is judged against elapsed hours. Missing minutes are unknown — never extrapolated to activity, never banked as rest. The rule was identified, not fitted: on the Oura export's own per-minute MET series it reproduces active_calories with r = 1.0000 and 0.6 kcal/day RMSE over 75 current-era days (r 0.9999 / 3 kcal over 396 pre-2025 days), zero intercept, the only input being the wearer's weight. A re-served minute counts once. The ring's timestamps go through a per-session 0x13 anchor, so a record served again under a second session lands 2–5 s off its first copy, while the ring's own minute grid steps back a second between records (a real successor starts 59–61 s on). Half a period tells them apart: two samples are the same minute when |Δ| × 2 < min(epochS), and the walk compares against the last counted start. Kotlin is pinned to Swift by oracle: the real Calories enum compiled standalone over a case spread (84 output lines) (four profiles × empty / rest floor / bout / 1.5 threshold edge / decoder boundary / partial coverage / 120 s cadence / duplicate ts / 3-s twins / 59-s phase steps / window edges / partial today / DST 23 h / clamp / bad epochs / realistic day), stdout pasted verbatim into MetCaloriesOracleTest. MetCaloriesTests pins the Swift side with hand-derived literals. [2/7] feat(store): persist the Oura ring's per-minute MET series — ouraMetSample, both platforms Until now the 0x50 MET stream existed only as the diagnostic JSONL sidecar, so nothing scored could read it. GRDB v47-oura-met-sample / Room MIGRATION_40_41 (schema 41) add ouraMetSample(deviceId, ts, met REAL, state, epochS) keyed (deviceId, ts), column order identical on both sides and pinned in schema_oracle.json (both copies). epochS is carried per row so a cadence other than 60 s scales the estimate rather than skewing it. Insert drops a re-served twin: the (deviceId, ts) key alone does not catch a record served again under another session anchor (it lands a few seconds off), so the insert reads the stored rows around the batch and drops any incoming sample within half a period of a stored one or of one accepted earlier in the batch (earlier start wins, lower MET on an exact tie). The pure rule is OuraMetSample.droppingTwins / OuraMetSampleEntity.droppingTwins, same integer test as the estimator, testable without a database. A 59-s phase-step successor is kept. Swift: OuraMetStore (insert, bounded range read, count), the table on DeviceRegistryStore.deviceScopedTables so forgetting a ring clears it. Android: entity, DAO insert/read/delete, DeviceRegistry.deleteDeviceData wiring, repository wrappers, the committed v41 Room schema for the upgrade test. Tests: OuraMetStoreTests (Swift), OuraMetSampleMigrationTest (Kotlin, incl. the twin rule); SchemaOracleTest / WhoopDatabaseUpgradeTest / the device-scoped-table guards on both sides. [3/7] feat(analytics): analyzeDay scores calories from the owner's MET series when supplied analyzeDay gains dayMet (the day owner's own per-minute MET samples), dayMetNow (so today's coverage is judged against elapsed hours, not 24 h) and a caloriesDiag sink. Rule: MET samples present ⇒ activeKcalEst = estimateDayEnergyFromMET(...).totalKcal when the stream covers ≥ 50 % of the window; below that the estimate is withheld (nil) rather than substituted by the HR path, which on a ring day runs over sparse banked HR and does not track Oura's number (r ≈ −0.1). nil/empty dayMet keeps the HR path byte-identical — every WHOOP and pure-function caller is unchanged. One always-on log line per MET day. Both platforms; AnalyticsEngineMetCaloriesTests / AnalyticsEngineMetCaloriesTest pin the selection, the withhold, the elapsed-hours window and the byte-identical no-MET path. [4/7] feat(oura): score active calories from the ring's MET records, behind an Experimental toggle The toggle (iOS AppModel.ouraMetCaloriesKey / Android NoopPrefs.KEY_OURA_MET_CALORIES, default OFF) gates: • the writer — OuraLiveSource fans each anchored 0x50 record out to ouraMetSample, one row per minute, next to the existing JSONL sidecar call. The record's timestamp is the END of its last sample: fitted against Oura's own per-minute export, every record length n matched best at exactly −n minutes (85 % exact minute matches, r 0.90, vs 23 % / 0.57 read forward), so sample i starts at utc − (n − i)·60 and a record straddling local midnight lands its minutes on the right days. • the read — IntelligenceEngine reads the day owner's rows (registry active id, calendar- day scoped like dayHr) and hands them to analyzeDay as dayMet, with dayMetNow = now; the calories line goes through the same per-day diag recorder as the Effort funnel. • the day-cycle fold — DayCycleIntelligenceIntegration (and Android's PhysiologicalStepCycleEngine) recomputed Keytel for every cycle and wrote it over activeKcalEst, which would have hidden the MET decision on any phone with a day-cycle history. The fold now takes the same decision analyzeDay takes, over its own window [onset, min(endExclusive, now)): covered → the MET total, thin → withheld with no HR substitute, no rows or toggle off → Keytel byte for byte. A "stepsCycle calories … path=met" trace line names the decision. The toggle joins the day-cache config signature on both platforms so a flip re-scores every cached day. Android threads the flag Context-free like spo2CandidateDisplay, carries it into the pass on a field and reads the MET rows inside readDaySkinAndWristOff, and hands the fold a Boolean rather than a lambda — all to stay inside analyzeRecentOnCpu's JaCoCo budget (a new suspend call there spills ~0.7 K instructions of continuation state). Settings gains "Experimental · Oura Calories" (iOS card / Android row), shown only with an Oura ring, caption stating the method, the < 50 % coverage withhold, that Oura re-scores a logged workout's minutes by activity type (NOOP does not, so such a day reads lower), and that turning it on starts storing MET samples. Strings in de/es/fr/pt-PT plus it/pl/ru/zh-Hans/ zh-Hant (iOS) and pl/ru/zh (Android). Docs: OURA_PROTOCOL.md §6.13 (day-sum validation of the 0x50 decode, end-of-record timestamps, the formula); README Oura table "Active calories". OFF keeps both the DB and every score byte-identical. Tests: DayCacheConfigFieldTests / DayCacheConfigFieldTest; DayCycleRecoveryTests (Swift, xcodebuild test) and DayCycleMetCaloriesTest (Kotlin, Robolectric + Room) on a seeded 8-h main sleep: covered cycle carries the MET total, 10 %-covered is withheld, no reader / empty table = Keytel. [5/7] feat(oura): pair the MET store with its twins in the parity ledger Review follow-up. The parity ledger flagged the MET store's Kotlin reads and writes as one-sided; run in full it also flagged the MET toggle's arity changes to existing functions, which read as new identities. Paired, with twin claims where the ledger reads them: - `WhoopRepository.insertOuraMetSamples` <-> `WhoopStore.insertOuraMetSamples` - `WhoopRepository.ouraMetSamples` <-> `WhoopStore.ouraMetSamples` (on the Repository, since the DAO's `@Query` puts its declaration outside the claim's attach window) - `AnalyticsEngine.analyzeDay`, `IntelligenceEngine.analyzeRecent` and `DayCycleIntelligenceIntegration.compute`, whose parameter lists grew here Removed: `WhoopStore.ouraMetSampleCount` and `WhoopDao.countOuraMetFor`. Neither had a production caller (the Kotlin one had no caller at all); the store tests count through `ouraMetSamples` instead. `platform_specific` dispositions for what is Kotlin-only by construction: the Room `@Insert` and `@Query` primitives under the paired Repository functions, the per-table forget-device delete (Swift clears the table through the `DeviceRegistryStore` name list), the Room migration override (its GRDB twin is the `v47-oura-met-sample` closure, pinned by the shared schema oracle), and the two JVM 64 KiB extractions `readDaySkinAndWristOff` and `PhysiologicalStepCycleEngine.compute`. The authority is re-derived with `--migrate-authority` because `main` at 5783c49 no longer reproduces its stored one. Verified: `parity_ledger.py` OK; `parity_ratchet.py --migrate-authority` 0 errors; `test_parity_*` 180 OK; StrandAnalytics 2068/0; WhoopStore 617/0; macOS `StrandTests` (DayCacheConfigField, DayCycleRecovery) 17/0; `NOOPiOS` builds; Android 6402 tests, the 8 failures reproduce identically on `upstream/main`; doc lint and `i18n_audit --ci` clean. [6/7] doc(calories): say at the MET assignment that activeKcalEst holds a total Review follow-up. `activeKcalEst = met.totalKcal` reads like a category error: the estimate carries the active share separately. It is correct, because the field is a pre-existing misnomer and the HR path's `estimateDayCalories` already stores `estimateDayEnergy(...).totalKcal` in it. That is now written at both `analyzeDay` sites, so the next reader does not have to work it out again. Comment only. [7/7] fix(oura): key an ended cycle's MET calories on the MET series and the toggle the per-owner HR witness and the scoring profile. Once the MET-calories toggle routes a cycle's calories through the ring's MET series, that key cannot see what the figure depends on: - a later drain that banks MET minutes inside an ended window leaves the HR witness unchanged, so the cache keeps serving calories from the thinner stream (or a withheld nil, when the first pass was under the floor); - a toggle flip over unchanged data matches the entry cached under the other setting and serves the previous mode's figure. Both platforms now append a MET witness to the key: `met=off` when the toggle is off, otherwise `met=<owner>=<count>:<maxTs>` from an index-only aggregate over ouraMetSample, the same shape as the HR witness. Swift adds WhoopStore.ouraMetFingerprint(deviceId:from:to:), injected into the fold as MetFingerprint beside MetReader, and an unread witness never serves a cached load. Kotlin adds the countOuraMetInWindow / maxOuraMetTsInWindow DAO pair and WhoopRepository.ouraMetFingerprint, and loadCacheKey takes the witness. The rebase onto ryanbr#2293 moved the fold's MET-vs-HR decision into the cache-miss branch as cycleCalories() on both platforms, unchanged in behaviour. Tests: OuraMetStoreTests fingerprint (count/maxTs, inclusive bounds, per device, moves on an in-window insert); DayCycleRecoveryTests and DayCycleMetCaloriesTest each gain "MET banked after a pass is not served from the cache" and "a toggle flip over unchanged data rescores the cycle"; RescoreUnchangedInputsTest pins the witness in the key; Kotlin repo fingerprint. With the witness replaced by a constant, 4 of 6 DayCycleMetCaloriesTest cases fail. Parity: loadCacheKey/8 replaces /7 in the dispositions, the two DAO primitives are platform_specific like their HR counterparts; ratchet 0 errors, ledger no new findings. Rebase onto main at ca24978: main's ryanbr#2472 grew analyzeRecentOnCpu to 55,559 instrumented bytes, which left 141 against the 55,700 JaCoCo budget, and this change measured 239. The day's MET rows now reach analyzeDay through a pass field (ouraMetDayForPass, written by readDaySkinAndWristOff), not through the DaySkinReads holder. On the holder, the holder stayed live across every later suspension point of the day loop and was spilled and restored at each one. The helper derives the calendar-day window from dayStart itself (same 14-parameter arity). Measured 55,669. Refs ryanbr#2242 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y9RCdbENSxgnGFTikJPbBq Claude-Session: https://claude.ai/code/session_01484Ef871BnAuniyDJYYHoV Claude-Session: https://claude.ai/code/session_01RgqTwKfXLXzKo81ECb4aDz Claude-Session: https://claude.ai/code/session_01RuJdFu6iobsWfRtPYUR4C8 Claude-Session: https://claude.ai/code/session_01QUwfZ8hUzmV6ScwZcuaTAr

Iskrata force-pushed the fix/rescore-habits-from-finished-nights branch 2 times, most recently from caa9fd4 to 5ef4775 Compare September 19, 2026 08:46

Iskrata force-pushed the fix/rescore-habits-from-finished-nights branch from 5ef4775 to 73a6004 Compare September 21, 2026 10:21

Iskrata mentioned this pull request Sep 21, 2026

fix(rhr): report resting HR as the deep-sleep mean, not the night's lowest 5-min bin #2284

Open

6 tasks done

Iskrata added 6 commits September 23, 2026 23:48

perf(rescore): learn sleep habits from finished nights so tonight's s…

99f4c0b

…ync stops dropping the day cache

perf(rescore): reuse a closed sleep-to-sleep cycle's Effort and calor…

f8cd233

…ies instead of re-reading its heart rate every pass

perf(rescore): Android twin: learn sleep habits from finished nights,…

4b5941b

… and reuse a closed cycle's Effort and calories

docs: keep the Kotlin twin's doc comments attached

1c6c654

chore(parity): refresh derived snapshots; note why computeHabitualSle…

0085da5

…ep is internal

ryanbr force-pushed the fix/rescore-habits-from-finished-nights branch from 73a6004 to 0085da5 Compare September 23, 2026 11:54

ryanbr mentioned this pull request Sep 23, 2026

feat(oura): active calories from the ring's own MET stream, behind a default-off Experimental toggle (#2242) #2414

Closed

ryanbr merged commit 9d85ea8 into ryanbr:main Sep 23, 2026
19 checks passed

This was referenced Sep 28, 2026

WhoopRepository: two HR union fingerprints compute the same value #2566

Closed

refactor(data): one HR union fingerprint, not two that were free to disagree #2570

Merged

Navigation Menu

Repository navigation

perf(rescore): stop a post-sync pass re-scoring nights and cycles whose inputs did not change - #2293

perf(rescore): stop a post-sync pass re-scoring nights and cycles whose inputs did not change#2293
ryanbr merged 6 commits into
ryanbr:mainfrom
Iskrata:fix/rescore-habits-from-finished-nights

Iskrata commented Sep 17, 2026 •

edited

Loading

Uh oh!

ryanbr commented Sep 20, 2026

Uh oh!

ryanbr commented Sep 20, 2026

Uh oh!

ryanbr commented Sep 21, 2026

Uh oh!

Iskrata commented Sep 21, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

Iskrata commented Sep 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What this PR does

Why

Behaviour change

Type of change

How it was tested

Checklist

Uh oh!

ryanbr commented Sep 20, 2026

What holds up

One code note

One thing worth naming

What is blocking it, which is not your doing

Uh oh!

ryanbr commented Sep 20, 2026

Uh oh!

ryanbr commented Sep 21, 2026

1. This is a behaviour change, not only a performance one

2. Worth connecting to #2360

3. Minor

Housekeeping

Uh oh!

Iskrata commented Sep 21, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Iskrata commented Sep 17, 2026 •

edited

Loading