[ryanbr]

Addresses #1705, reported by @pipiche38 with the file and line references already done — I verified every citation against current main before writing this, and they were accurate.

What was wrong

skin_temp is deliberately bimodal: a WHOOP CSV import writes absolute wrist °C into the same field the computed pipeline fills with a signed deviation from the personal baseline.

Formatting survives that, because the per-value formatter re-derives the kind for each number — which is precisely why nothing looks broken. Aggregates do not. A min, max, mean, or window-over-window delta drawn across both kinds is arithmetic on two scales, and the result is plausible rather than obviously wrong.

The fix

The guard already existed and the Explorer paths had never adopted it. VitalSignsSummary / HealthVitalsLogic pick one kind and filter to it before touching a sparkline, and SkinTempDisplay already models the kind on both platforms with tests.

So this adds one decision beside it — dominantKind, the kind a mixed window reduces to, which is the newest entry's, matching what those two already do — rather than a fourth inline copy of the >= 20 check.

Applied at the one place each platform merges, not at each screen:

	where	what it merges
Swift	Repository.exploreSeries	the three layers collapsing into [String: Double]
Kotlin	WhoopRepository.resolvedSeries	imported ∪ computed identities, resolved first-wins

That covers every consumer at once, including two the report did not have to name: the Explorer correlation scan, and Compare's min–max chart normalisation on Android. I confirmed both sides emit ascending-by-day, which dominantKind depends on.

Android was exposed too

The report flagged this as untraced. It is affected, by a different route: Android's importer emits no metricSeries skin_temp row and there is no exploreSeries twin — but sourceCandidates unions the import identity with the computed -noop one, so first-wins can resolve older days to absolute and recent days to deviation. CompareScreen then takes values.minOrNull()/maxOrNull() unfiltered and normalises the chart across them.

Why reduce rather than convert

The report's option (a) — convert the import to a deviation at write time — fixes every downstream reader including unaudited ones, and I did consider it. Against it: it rewrites stored data irreversibly, needs a baseline that a fresh import-only install does not have (the reporter's own objection), and puts both platforms' baseline derivation under the byte-identical stored-data contract. Filtering keeps the newest reading intact and drops only older entries of the other kind.

Tests

The regression guard the report asked for, built from its own numbers — the 313-row 32.39…36.64 import against computed deviations inside ±0.3. It asserts the filtered window is single-scale, and pins the defect itself: unfiltered, that mean lands at 15.43 and is labelled as a deviation, because it falls below 20.

Verified

4,725 Android tests, 0 failures with --rerun-tasks --no-build-cache; SkinTempDisplayTest 10/10. The Swift decision compiled standalone and agreed with the Kotlin.

Both twins live in package/analytics code, so test (StrandAnalytics) and build-and-test cover them without app-build — which was the point of putting the filter in the repository merge rather than in MetricExplorerView.swift, as the report's own Verification section noted.