[evoveotech]

Summary

Addresses #1853.

The nightly ABSOLUTE skin temperature (skinTempC) is written only by the scoring pass, which covers a rolling 21-night window. Nights already outside that window when the column shipped (#1636) were never revisited, so a wearer sees "+0.5 Δ°C" with no way to learn what it moved from — the deviation is stored but the absolute is NULL.

This adds a targeted historical backfill that re-derives the absolute from the same raw streams and the same skinTempFunnel the scoring pass uses, then writes it with a fill-only UPDATE that can only fill a NULL — never an upsert of a rebuilt row, never overwriting a measured value, never touching skinTempDevC or any other scored field.

Three correctness rules (re-review findings from the Android twin, #1852)

1. Attribute sessions by END. The night window is 54 h wide and contains the previous night; handing the funnel the whole window averages two nights into one temperature. SkinTempBackfill.sessionsForDay filters by session-end-in-day, matching the engine's matched = allSessions.filter { tsInDay(it.end) }.

2. Page the candidates. A plain "oldest N" latches on page one (the nights most likely to have lost their raw samples) and never reaches the newer nights that can fill. SkinTempBackfill.page(candidates:page:pageSize:) walks oldest→newest, 50 per page by default.

3. The WHOOP 4.0 anchor comes from the CURRENT window. A re-learned anchor puts backfilled nights on a different offset from the stored ones and the chart plots two scales as one line. No anchor ⇒ decline, never the global 826 fallback.

What's in the change

• StrandAnalytics/SkinTempBackfill.swift — the pure, database-free half: session attribution (rule 1), the anchor rule (rule 3), and the per-night plan that calls the existing AnalyticsEngine.skinTempFunnel so a backfilled absolute is byte-identical to what the scoring pass would have stored.
• WhoopStore/MetricsCache.swift — fillSkinTempC(deviceId:day:skinTempC:): a single-column UPDATE … WHERE skinTempC IS NULL that returns rows filled. Fill-only by construction.
• Strand/Data/SkinTempBackfillWalker.swift — the I/O layer: reads candidate computed rows (skinTempDevC != nil && skinTempC == nil), resolves the day owner / device family / worn tolerance via the same IntelligenceEngine helpers the scoring pass uses, reads the raw streams, calls the pure helper, and writes the fill-only result. On-demand (Test Centre trigger), paged, idempotent.
• Tests — StrandTests/SkinTempBackfillTests.swift covers session-by-end attribution, the inclusive/exclusive day boundaries, the WHOOP 4.0 anchor decline, the 5/MG fill path, the sample floor, the previous-night-not-matched case, and the page rule. DailySkinTempAbsoluteTests gains three fill-only storage tests: fills NULL + touches nothing else, refuses to overwrite an existing absolute, no-op when the row doesn't exist.

Trigger

On-demand from the Test Centre (the issue's "diagnostic first" + safest trigger). Doing it automatically on upgrade risks a long first launch on a deep history. The caller decides how many pages to run.

Test plan

• swift test over Packages/ (WhoopStore fill-only tests)
• xcodebuild -scheme Strand build (app-target compile — the walker is app-target Swift)
• xcodebuild -scheme Strand test (StrandTests — pure helper tests)
• xcodebuild -scheme NOOPiOS build (iOS compile — the walker is shared with iOS)
• doc_comment_lint (no new detached doc comments)

Generated with Devin

[ryanbr]

Thanks @evoveotech — the three rules from the Android post-mortem are all here and correctly implemented. I verified them rather than reading the summary:

• The write is fill-only by construction, not by care: UPDATE dailyMetric SET skinTempC = ? WHERE deviceId = ? AND day = ? AND skinTempC IS NULL, one column, returning changesCount. It cannot overwrite a measured value or touch skinTempDevC.
• Session attribution really does match the engine. This was the one I most expected to be subtly wrong: sessionsForDay compares raw timestamps against dayStart, while the engine's tsInDay shifts by tzOffsetSeconds first. They agree only because localMidnightUnix returns UTC-midnight minus the offset, which makes end ∈ [dayStart, +86400) exactly (end + tz) ∈ [dayStartUtc, dayEndUtc). It holds.
• The 4.0 anchor declines rather than reaching for the global 826, and records why.

15/15 CI. The computation is not my concern here.

The concern is that this is build five

This feature shipped four times and was reverted twice, on 3 and 4 September. The revert commit is explicit about the pattern:

Four builds shipped it and none of them worked on the install it was written for. Each failure was a different piece of wiring, each was found only after a person tested it, and none of them were in the computation.

• health: backfill the skin-temp absolutes the 21-night window never reaches (#1851) #1852 queried the strap id for rows the engine writes under -noop;
• health: the absolutes backfill never ran on the installs that need it #1854 ran it inside the scoring pass's new-data gate, so a feature for reprocessing OLD nights only ran when NEW data arrived;
• health: stop predicting which device a night belongs to — read it off the row #1856 stopped predicting the id, and still did not fill on the reporting install.

Every one of those fails to NOTHING rather than to something wrong, which is why it kept reading as "already done" and kept costing another round-trip.

SkinTempBackfillWalker has no call site. Outside its own file, nothing in Strand/ or StrandiOS/ references it. As it stands this is 646 lines that cannot run — the same failure the revert describes, arrived at a fifth way.

That is not a criticism of the code. It is that the part which has failed four times is precisely the part this PR does not contain, and the three rules it does contain all guard the part that never failed.

What would make this mergeable

1. The call site, and the gate it sits behind — stated explicitly, because health: the absolutes backfill never ran on the installs that need it #1854 died on exactly that: a reprocessing job wired into a new-data gate runs only when there is new data, which is the one condition under which it has nothing to do.
2. Evidence the candidate nights still have raw samples. The revert names this as the unsettled unknown: "whether those nights have banked raw samples at all was never settled, so the third fix is unverified rather than known-good." If the raw streams have aged out, a correct backfill still fills nothing, and build five fails to nothing like the others. One night's counts from the reporting install would settle it before any code ships.
3. A note on the Android side. It is currently reverted, so merging this puts the feature on one platform. Worth being deliberate about rather than incidental.

Given the history, I would rather this waited for the wiring and the raw-sample check than became the fifth build that reads as "already done".

[evoveotech]

Thanks for the review — all three points addressed in b8d92c9f8.

1. The call site, and the gate it sits behind

The walker now has a call site: an on-demand "Backfill skin-temp absolutes" button in the Test Centre's Diagnostic Tools card (the issue's "diagnostic first" + safest trigger — doing it automatically on upgrade risks a long first launch on a deep history, exactly the #1854 failure mode). The action is disabled while a pass is running and shows the result line under the button.

The gate it sits behind is NOT a new-data gate (the #1854 trap). It is a user tap. The backfill runs only when explicitly asked, so it can never be wired into a condition under which it has nothing to do — it runs precisely when there is something to do.

The walker now owns the WHOOP 4.0 window-anchor scan in a self-contained runBackfill() entry point, so the call site does not duplicate engine internals. It replicates the scoring pass's window-wide skinTempSamples read + Whoop4SkinTemp.deviceAnchorRaw learn (rule 3: the anchor comes from the CURRENT scoring window, never the global 826 fallback), then pages through the candidate nights until a page is empty or the page budget (10 pages × 50 nights) is reached.

2. Evidence the candidate nights still have raw samples

The result line is self-attesting. It reports filled / declined / no-raw-data counts:

skin-temp backfill (#1853): filled N, declined M, no raw data K (anchor from current window, reached end)

If no-raw-data equals the candidate count, the raw streams have aged out and the backfill fills nothing — the diagnostic the issue's unsettled unknown asked for, produced by the action itself rather than claimed in advance. The noRawData list is already collected per-night in the walker (skin.isEmpty → noRawData.append(day)), so the evidence is the run's own output, not a pre-ship assertion.

3. A note on the Android side

The Android twin is currently reverted, so this PR ships Apple-only deliberately. The pure half (SkinTempBackfill in StrandAnalytics) and its tests are cross-platform and already shared; the Android wiring will follow once the Android twin's call-site question is settled. Worth being deliberate about rather than incidental — agreed, and called out here so it is.