HRV: default Overnight only ON for fresh installs (#1008, minimum half)

[ryanbr]

The safe half of #1008. No existing user's behaviour changes.

What

WHOOP publishes no daytime HRV figure — its reading is an overnight one. So a 24/7 stream has no official-app analogue, and the setting's own copy says overnight-only "roughly halv[es] the battery cost".

Today, turning on Continuous HRV capture gives you the expensive, non-WHOOP-like behaviour unless you separately find and enable Overnight only. That is the wrong way round: the cheaper, comparable option should be what you get, and the expensive one should be the deliberate choice.

Existing users are unchanged, and that is the whole design

A one-time launch migration pins the old default for anyone already running it:

• has used Continuous HRV, never chose an overnight setting → pinned to OFF (always-on preserved)
• everything else → left alone, so the read takes the new ON default
• an explicit choice is never overwritten, in either direction

It runs before the user can reach either toggle, and it is idempotent, so it is a no-op on every launch after the first and on every fresh install.

Why a migration and not a read-time default

I tried the read-time version first and it was wrong. It keyed the default on "has ever enabled Continuous HRV" — a fact the user's own opt-in creates. So a fresh install read overnight-only ON, and then flipped to OFF the moment they enabled Continuous HRV: the exact opposite of the intent.

State-by-state tests could not see it. Every individual state was correct; only the sequence was wrong. There is now a test for that sequence specifically.

A @AppStorage onChange hook cannot substitute on iOS either — @AppStorage writes the value before the handler runs, so by then a first-ever toggle is indistinguishable from any other. That asymmetry is why this is a launch migration rather than something wired to the toggle.

What is deliberately NOT here

The other half of #1008 — defaulting HrvWindow to DEEP_SLEEP to match WHOOP's reading. Two reasons, both in the issue:

• setHrvWindow's own comment says it "re-scores + re-baselines (the value itself moves)". Flipping it moves every existing HRV number and everything built on it.
• DEEP_SLEEP pools RMSSD over deep-sleep windows, so it is only as trustworthy as deep-sleep detection — which changed in Sleep: forbid wake → deep/REM transitions — the one part of #348 that survives a de-contaminated benchmark #987 and is still unsettled on 5/MG. It needs Tools/SleepPSG evidence before it can be a default, and possibly needs to be family-aware rather than global.

Parity

Both platforms, same rule, same five test cases in the same order. Android's UI NoopPrefs and iOS's PuffinExperiment each keep their own storage; only the decision is shared in shape.

UserDefaults.bool(forKey:) cannot express the new default on its own — it returns false for a missing key, which is indistinguishable from an explicit off — so the read is object(forKey:) as? Bool ?? true, and the migration checks object(forKey:) for presence, mirroring Android's contains().

The migration is wired into StrandiOSApp.init() and StrandApp.init() (macOS). Those are app-target Swift, which nothing compiles here — parse-checked only, same limitation as the rest of the app target while app-build.yml is disabled.

Verification

• The rule is lifted into continuousHrvOvernightDefault on both platforms so it is testable without a Context or UserDefaults.
• Kotlin: 5 tests green, run locally against the rule extracted verbatim from source. They run in CI under testFullDebugUnitTest.
• Kotlin compile against a main worktree: 2517 errors both sides, 41 in MainActivity.kt both sides, error sets byte-identical. No new errors.
• swiftc -parse clean on PuffinExperiment.swift and the new test.
• Tools/doc_comment_lint.py clean.
• The Swift tests live in StrandTests, which only runs under xcodebuild on macOS — and app-build.yml is disabled, so they are not executed by CI today. Stated in the test file itself so nobody reads them as covered.

Note for the release

No stored value changes and no score moves, so this does not belong under "scores that change". It is worth one line in the notes for new users: enabling Continuous HRV now captures overnight by default, and the all-day behaviour is one toggle away.

Re-review: the iOS toggle and the behaviour disagreed

Changing the read default left SettingsView's @AppStorage on false. Same key, two routes — so a fresh install would show "Overnight only" OFF while capture was actually overnight-only.

The failure mode is worse than a wrong label: a user "correcting" the toggle by flipping it on and off would write an explicit false and end up with exactly the 24/7 behaviour they were trying to avoid.

Android was never affected — its toggle reads through NoopPrefs.continuousHrvOvernight, so it cannot disagree with what the BLE client acts on. That is the better shape, and it is why the bug was iOS-only.

I then checked the rest of SettingsView for the same class. journalReminderEnabled and experimentalSleepV2Enabled are the only other true-default toggles, and both already pair with an accessor that handles the unset case — the first with the exact object(forKey:) as? Bool ?? true spelling used here. So the fix matches how the codebase already solves this twice, and there is no other instance.