# 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.

### 2026-06-06 - Suspected iCloud Health Reconciliation On Restored Device

After HealthProbe access requests, broad HealthKit queries, and retry attempts on
the restored pre-loss reference device, the user observed that data from
2026-05-24 appeared on the device. This suggests the device may have entered a
Health/iCloud synchronization, reindexing, or aggregation phase.

Interpretation:
- the restored reference device should not be treated as a stable performance
  benchmark while this reconciliation appears active;
- snapshots from this period should be labelled as captured during suspected
  Health/iCloud reconciliation;
- the device remains important forensic evidence because HealthProbe operations
  may have surfaced or triggered latent Health database synchronization work;
- stable import performance comparisons should use another device until the
  Health UI, Health authorization UI, and repeated HealthProbe diagnostics become
  consistent again.

## 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?
