[ryanbr]

The bug

Reported from the field: the Fitness Age readiness card shows every input satisfied — "Resting heart rate: 7 of last 7 nights", age/sex Set, activity 7 of 7 — yet the card reads "No Data" and never produces a value. Meanwhile Vitality / Body Age computes fine (54 / 48). Age and sex confirmed set in the profile, so it's not a coverage or profile gap.

Root cause

The engine gated Fitness Age on fa7 = dailies — this recompute pass's freshly scored nights. A recompute only re‑scores a night whose raw HR still lives in the DB (if (hr.size < MIN_HR_SAMPLES) continue), but the computed daily rows (and their resting‑HR) persist after the raw streams age out. The readiness card, by contrast, counts the persisted / merged daily history.

So the two disagree: the card counts the full persisted week ("7 of 7"), the engine's dailies sees fewer than 4 resting‑HR nights → assessReadiness returns NOT_READY → Fitness Age is never written. Vitality survives the same sparse fa7 because VitalityEngine needs only 3 of any input (sleep / HRV / steps), which is exactly why Body Age shows but Fitness Age doesn't.

Fix

Gate + compute Fitness Age from the same merged last‑7 the card and dashboard read (repo.daysMerged on Android, repo.dailyMetrics(fromDay:toDay:) union on iOS), kept separate from fa7 so Vitality (which already computes) is untouched.

Monotonic‑safe: the merged view can only yield ≥ the resting‑HR nights dailies had, using valid values — so it can never make Fitness Age compute less often. Worst case it's a no‑op; best case it computes.

Also adds a strap‑log line (Android) recording the resting‑HR‑night count the engine actually sees for the gate, so any remaining divergence from the card's "N of last 7" is provable from an export.

Honest caveat / validation

The recompute deletes+reinserts computed rows mid‑pass, so there's a chance the merged read reflects the same narrowed window and the fix is a no‑op for this exact case. That's what the diagnostic is for. To validate: after this ships and a recompute runs, does Fitness Age populate? If not, the strap‑log fitnessAge gate … rhrNights=N line pinpoints whether the persisted store itself is being pruned (a deeper follow‑up).

Verification

• Android :app:compileFullDebugKotlin passes locally.
• iOS reviewed by hand (Charts/Compression can't build on WSL): repo.dailyMetrics(fromDay:toDay:) is async (non‑throwing), in scope with oldestDay/newestDay; fa7/faRHRs retained for Vitality; removed faActiveStrains/faMeanActiveStrain have zero remaining refs.

[ryanbr]

Update — root cause refined + hardened (after "original noop worked").

The Fitness Age block is byte-identical to upstream NoopApp/noop, so the code isn't inherently broken. With the readiness card showing 7/7 nights, the real cause is: the engine gates on computed-only dailies, but the user's resting HR comes (partly) from imported daily aggregates (Apple Health / Health Connect) that only the merged view carries — so the card counts them and the engine doesn't.

Two downsides from the first cut are fixed here:

• No-op risk: the merged read now happens before the recompute's own delete/evict (was after), and the gate is the union of pre-rewrite persisted history ∪ this pass's fresh scores (by day) — so an RHR night counts whether it survives in the store, was just scored, or came from an import.
• Unbounded Android read: now windowed to the recompute range.

Vitality stays on dailies (already computes) — untouched. Android :app:compileFullDebugKotlin passes; iOS hand-reviewed.