[bhelm]

Summary

• extract the contiguous Fitness Age, Vitality, and WHOOP 4 Steps persistence phase into one private suspend helper at the same serial call site
• preserve repository reads, writes, callbacks, traces, cancellation, and failure propagation
• add a direct JaCoCo 0.8.12 offline-instrumentation regression guard with exact JVM method-size budgets and runtime ordering/failure checks

Verification

• focused runtime order/failure guard: 1 passed
• affected analytics selection: 92 passed
• FullDebug unit suite: 4,192 passed, 0 failures/errors, 6 established skips
• fresh targeted and full JaCoCo reports: no MethodTooLargeException, IllegalClassFormatException, or instrumentation errors
• raw method sizes: analyzeRecentOnCpu 50,459 bytes; helper 4,693 bytes
• instrumented method sizes: analyzeRecentOnCpu 59,171 bytes (6,364-byte JVM-limit margin); helper 6,389 bytes
• assembleFullDebug: BUILD SUCCESSFUL, 38/38 tasks

Fixes bhelm#102

[ryanbr]

Reviewed. This is a clean piece of work and I'd take it as-is. One cross-PR note at the end that's worth sequencing around.

The extraction is a pure move, verified mechanically

The thing that matters for a 50 KB method being carved up is whether anything changed on the way out. I diffed removed against added lines, normalised for whitespace:

• 117 removed lines, 0 of which fail to reappear. Every line is a verbatim move.
• The only genuinely new lines are 33: the 15 named arguments at the call site, the matching 15-parameter signature, and the closing brace. Nothing else.

That is exactly what I wanted to see and it's rare — no smuggled edits, no reordering, no defaults quietly changed. Specifically:

• suspend is preserved, so cancellation still propagates through the same structured-concurrency path;
• no try/catch was introduced around the call, so failure propagation is unchanged;
• named arguments throughout, so a 15-parameter signature can't be silently mis-wired positionally.

The guard is well built

The part I probed hardest was whether the budget test warns or just waits for the cliff. It warns: assertExactMethodBudget(lengths, "analyzeRecentOnCpu", 61_535) sits 4,000 bytes below the JVM's 65,535 limit, so CI goes red with real headroom left rather than at the moment JaCoCo actually breaks. The helper gets 12,000 against a current 6,389.

The ordering tests are the right complement: exactly one declaration, exactly one call, positioned after replaceComputedScoreWindow and before DismissedSleepGuard.keeping, with each internal operation asserted to appear once and in sequence. A future refactor that relocates the block fails loudly instead of silently reordering persistence.

testImplementation-scoped, so JaCoCo never reaches the APK — right call for this project — and registered in both the lockfile and verification-metadata.xml.

Verified on the merged tree

Your branch is based on ec200630f, several merges behind, and it touches the same file my #1521 hoist landed in, so I tested the merge rather than the branch:

• zero conflicts, and the rrOrds hoist survives intact (declared once, used at all three call sites)
• 4,211 tests, 0 failures, 6 established skips (--no-build-cache --rerun-tasks; main is 4,208, so +3)
• all three new tests pass: offlineInstrumentedMethodsKeepSafeCodeMargins, extractedBlockRemainsSerialAndAtTheRequiredCallSite, extractedBlockRetainsRuntimeReadCallbackTraceAndFailureOrder

One note, and it's about your other PR

This adds a new one-sided Kotlin function — persistFitnessVitalityAndSteps has no Swift counterpart, and correctly so: it's a JVM method-size workaround and Swift has no 64 KB limit, so a twin would be structure-for-structure mimicry with no value.

But that is precisely the shape your parity ledger in #1534 reports as add-unpaired-function kotlin. When I fed it a synthetic one-sided Kotlin helper, that is exactly the rule it fired. So whichever of these lands second will need either an issue-bound exemption or a deliberate note in the authority — worth deciding the order now rather than discovering it as a red gate later. Given #1534 regenerates its authority from whatever tree it rebases onto, merging this one first is probably the cheaper sequence.

Not a change request. Ready to merge from my side.