[ryanbr]

Refs #2208, reported by @pipiche38 from a code read. Every claim in that report checks out at the lines given; the review comment there lists what I verified.

The mechanism

One shared mutable field. LiveState.batteryPct is the WHOOP's and is never cleared, deliberately: clearBiometrics nils ouraBatteryPct and leaves it. connected goes true the moment any source streams, including the first live HR from a ring. So both halves of the old gate pass and the screen draws the strap's charge under an active ring.

Seven surfaces, not five

Three were routed through the seam in #2076. This report found five more. I did seven.

The two extra are the ones the report flagged and left out as "arguably the same bug one screen over". They are worse than the five it filed: the macOS sidebar and the menu-bar stat gated on nothing at all, so they showed the strap's last percentage with nothing connected, needing no ring to reproduce.

The sidebar is the sharper case. Its only honest branch is the nil one, and since batteryPct is never cleared, that branch stopped being reachable the first time a WHOOP ever connected. "Strap not connected" was dead text on any install that had paired a strap once.

Leaving them would have made a third pass over one class inevitable, and the reason each pass keeps missing something is that the class is defined by a shared field rather than by anything visible at a call site.

Why a new field, given a stale field caused this

A fair objection, so the difference is worth stating. batteryPct has many writers (every source), no owner, and is deliberately never cleared. activeIsWhoop has exactly one writer, is overwritten on every active-device transition, and never needs clearing.

It is published on LiveState because Today cannot ask the device registry. LiquidTodayView observes BLEManager and not AppModel on purpose: AppModel publishes on the 1 Hz heart-rate tick, so observing it would re-render the whole screen every second. Repository.activeDeviceIsOura exists but answers the wrong question, since a Polar or Garmin strap is neither Oura nor WHOOP and the strap's charge is just as wrong under one.

The writer is SourceCoordinator.activeDeviceChanged, the same activeDeviceId transition that decides which live source runs. Set before the Apple Watch branch returns, or a watch would read as a WHOOP. Defaults to true, matching the seam's own WHOOP-first default for an unresolvable row.

StrapBatteryDisplay.resolve takes the flag with no default value. A defaulted flag is one a future call site can forget, and forgetting it reinstates this bug in a form that still compiles.

charging and the #713 runtime estimate are gated the same way: charging is the strap's BATTERY_LEVEL event, the estimate is banked from strap SoC samples.

Tests

Four new rows on the Swift truth table, two vectors on the Kotlin seam. Every existing Swift row carries activeIsWhoop: true, so the old meaning is preserved rather than rewritten.

Negative control: forcing the Kotlin seam to ignore the flag fails 4, including two that predate this change. LiveConsoleReadout.kt was restored unchanged afterwards and is not in the diff.

com.noop.ui: 1054 tests, 0 failures. compileFullDebugKotlin clean, doc_comment_lint clean. Apple targets compile on CI.

Checked while re-reviewing

• No missed StrapBatteryDisplay.resolve call sites; the other .resolve( hits are ChargeDisplay and RecordingState.
• The new field registers no parity finding. The ledger does fail on this branch, with the pre-existing test-only-callsite|Packages/WhoopStore drift tracked in Parity ledger fails on main, and --refresh-derived cannot repair it #2211, which reproduces on main.
• The writer always runs: wireSourceCoordinator calls start() when the store opens, and registry.$activeDeviceId emits on subscribe.

Worth knowing, not fixed here

There are now several spellings of this one fact: whoopIsActiveDevice and activeDeviceIsWhoop on the Android client, activeIsWhoop on the Android view model, LiveConsoleReadout.activeIsWhoop as the shared seam, and this. Consolidating them is its own change.

Left as the report left them: the Settings strap card and the onboarding line, which sit under explicitly WHOOP-labelled headings.

[ryanbr]

Second re-review pass, and it found a bug I had introduced rather than one I was fixing.

I routed the Android sources pill through the seam, and the seam is wrong for that destination.

LiveConsoleReadout.batteryPercent substitutes the ring's charge when the active device is not a WHOOP. That is exactly right for a readout naming whichever device is active, which is what the Live Console and the Devices list are. It is wrong here, because this value lands in the SourceRow badged today_source_whoop, and it also feeds that row's present flag:

val whoopPresent = (footer.whoopDays ?: 0) > 0 || strapBatteryPct != null

So the substitution would have put the ring's percentage under a WHOOP label and asserted a WHOOP source that is not there. That is worse than the reading being fixed: the old bug at least showed a number that really was the strap's.

Gated instead, matching the six other surfaces and the iOS row directly beside it, which is labelled "Strap battery" and hides for the same reason. Nothing is the honest answer for a strap that is not active.

@pipiche38, your suggested fix had this too, and for the same reason mine did. The seam is correct for a readout that names the active device; a WHOOP-labelled row is not one. Applying it mechanically is what we both did. What the destination means is the part that has to be read, and I did not read it until this pass. Not a criticism of the report, which is otherwise the most precise one I have had this week; just worth naming so the next person routing through that seam checks where the number lands.

ouraBatteryPct is no longer collected in TodayScreen, since nothing there reads it now.

com.noop.ui: 1054 tests, 0 failures. compileFullDebugKotlin clean.

[pipiche38]

Same shape as the one I had built for this (#2214, closing it as superseded — yours carries the Kotlin vectors, the negative control and one writer for activeIsWhoop, which is the right argument). And yes, the issue's "route both liveSnap sites through the seam" was wrong for the WHOOP-labelled row for exactly the reason you give; the PR gated it, the issue text didn't. Noted for the next time I write "route through the seam" without saying where the number lands.

One delta left between the two, and it's your call.

A streaming ring now draws the offline glyph on the Today header. StrapBatteryDisplay.resolve returns .offline for a non-WHOOP active device, so with a ring connected and reporting 93% the header ring shows the crossed-out bolt and VoiceOver says "Strap battery, strap not connected"; the Android header does the same (null → bolt-slash). #2076 chose "the ring's own charge when it has reported, nothing when it hasn't" for the console, Devices and the widget, and ouraBatteryPct + the seam already provide it — I had routed the brand-neutral surfaces (header ring, the two Today rows, sidebar, menu bar) that way, with ring charging from ouraWearState == .charging, and kept the WHOOP-labelled row gated. The counter-argument is real (the label still says "Strap battery", and "Ring battery" is a nine-locale string), so I'm not arguing for it; only that "offline" for a ring that is streaming is a new wrong claim on the very screen this issue is about, and the Ring 5 reporter wears no strap, so it's what they'd see every day. Hiding the surface entirely under a ring (as the two rows already do) would be the honest middle if the ring's own number isn't wanted there.

Everything else matched line for line after your second pass, sidebar and menu bar included. Not hardware-checked on my side yet; I'll run the ring + WHOOP pair against whichever shape lands.

[ryanbr]

You are right, and thank you for standing #2214 down in favour of this rather than the other way round. The delta you named was the thing wrong with mine.

Fixed in e63ff26. The previous shape traded one false claim for another on the same screen. .offline for a non-WHOOP active device meant a wearer with a ring streaming 93% saw the crossed-out bolt and VoiceOver read "Strap battery, strap not connected". That is a different wrong statement from the one reported, not a repair of it, and the Ring 5 reporter would meet it every day.

.notActiveDevice is its own case now, and the header control is not drawn at all when it applies. Adding a case rather than reusing .offline meant the compiler required both switches to answer, which is the property that already caught a missed call site earlier in this PR.

.offline stays for a strap that IS active and disconnected, because that is a real claim worth making. The two were being collapsed; a test now asserts they differ.

Android matches. LiquidTodayHeader takes strapIsActiveDevice separately from batteryPct and skips the ring entirely when it is false. Separate parameters on purpose: batteryPct says what the control reads, the flag says whether the control should exist. A null percentage while the strap IS active means "connected, no reading yet" and is worth drawing.

I took the hiding option rather than the ring's charge, which is the one you suggested as the honest middle and did not argue against. Your counter-argument holds: the label says "Strap battery", "Ring battery" is a nine-locale string, and ring charging would need its own source through ouraWearState. Hiding is also what the two Today rows already do, so there is now one answer across all of them rather than two.

If you want the ring's own charge on the brand-neutral surfaces later, that is a real feature rather than a bug fix, and it wants the label and the locales doing properly.

On the seam note: agreed, and I did the same thing you did. Your issue said "route both liveSnap sites through the seam" and I routed them, and neither of us looked at where the number landed until the second pass. The field itself now carries the warning, in ee00683bf: batteryPct had no documentation at all, which is how it got read raw by seven surfaces across two reports. It now says it is the strap's alone, that it is never cleared, that connected does not qualify it, and which of the two correct readings a surface needs depending on what its label claims.

Sweep is enumerated rather than asserted now: seven fixed here, six already correct through the seam, four out of scope under WHOOP-labelled headings, one Test Centre diagnostic where the raw strap SoC is the point, and three that are not readouts.

Hardware would be welcome whenever you get to it. Nothing here is hardware-checked either, and the ring-plus-WHOOP pair is the case neither of us can reason our way to.