HealthProbe Development Log

Canonical path: HealthProbe/Doc/04-project/Development-Log.md
Created: 2026-06-06
Purpose: Preserve project context that affects decisions across agent sessions.

This is the project memory log. Use it for facts that explain why HealthProbe is being built, why a device or dataset matters, and what historical context should not be rediscovered repeatedly from chat history.

Use specialized documents for detailed technical evidence: - import timings and performance experiments: Import-Optimization-Log.md; - refactoring milestones: Refactoring-Plan.md; - current implementation status: IMPLEMENTATION_STATUS.md; - product scope and non-goals: ../01-product/Product-Specification.md.

Maintenance Rules

1. Add dated entries when context changes or when an old assumption is recovered.
2. Keep entries factual and decision-relevant.
3. Link or summarize supporting reports instead of pasting large diagnostics.
4. If a fact belongs in product scope, update product docs too.
5. If a fact belongs in performance analysis, update Import-Optimization-Log.md too.

Device And Dataset Context

2026-06-06 - Restored Pre-Loss Reference Device

The large-database test device is a restored copy of the user's Health database from before the data-loss event noticed later on the iPhone 16. It is not the untouched original device state.

Important properties: - "12 mini" is the historical/original device name used for this Health database lineage and source backup context; - the restored test device may be reported by tooling with a different hardware model or current device name, so reports should preserve both the user-facing lineage name and the technical device identifier when available; - the source backup still exists and can be restored again if needed; - the restored device has already been used for attempts to restart or force natural iCloud Health synchronization; - results from this device should be labelled as coming from a restored pre-loss-reference copy; - the device can be used for aggressive experiments when necessary, because it is not the only copy of that state; - it remains a crucial reference dataset for future two-database comparison work.

Why this matters: - HealthProbe exists partly because this kind of Health database state can become inconsistent across devices and over time; - the app must distinguish Health UI visibility, HealthKit availability, synchronization state, and HealthProbe archive state; - future multi-archive comparison should compare this restored pre-loss reference against the current iPhone 16 archive without assuming record-by-record cross-device identity.

2026-06-06 - Blood Pressure Access Changed On Restored Device

A complete first import from 2026-06-04 on the restored reference device included Blood Pressure Systolic and Diastolic: - both were authorizationStatus: granted; - both imported 5,120 samples; - both ranged from 2014-12-18T11:24:11Z to 2026-05-29T03:06:36Z.

A later retry on 2026-06-06 from the same device reported both Blood Pressure types as unavailable because HealthKit returned Authorization not determined for earliest/latest queries.

Interpretation: - this is evidence of a device / iOS HealthKit authorization or Health database state change; - it is not evidence that HealthProbe cannot import Blood Pressure; - future runs should preserve these reports as before/after context.

Product Direction Context

2026-05 to 2026-06 - Why Full Authorized Backup Matters

The original 15-type capture profile is only a v1/test subset. It is not enough to validate the database or import architecture because the real target is full authorized backup of the local HealthKit-accessible database.

Reason: - assumptions that hold on a small Health subset may fail on full profile volume; - Apple Health may aggregate, prune, stop syncing, or expose different data through UI versus HealthKit; - recovery-compatible exports need complete-enough source data, not just summary counts.

Implementation consequence: - SQLite remains the source of truth; - SwiftData must not be expanded; - import, storage, and export decisions should be validated against full-profile datasets where possible.

Open Context Questions

• How should HealthProbe label a metric that is visible in Apple Health UI but returns Authorization not determined or another HealthKit access failure?
• When two local archives exist for different devices or restored states, what comparison mode is useful without reviving the old record-by-record cross-device objective?
• Which diagnostic fields should be retained inside the archive so old reports can be reconstructed without depending on copied text?