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

Another 2026-06-06 report from the restored device later imported both Blood
Pressure Systolic and Diastolic successfully, `5,124` samples each. After the
device unfroze enough for Settings to open, Blood Pressure appeared not
authorized there, even though the user had selected all types in the HealthProbe
authorization prompt.

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;
- it is not evidence that HealthProbe changed Health data, because the app only
  requests read access and runs read-only queries;
- future runs should preserve these reports as before/after context.

### 2026-06-06 - Restored Device Instability After Health Access

After HealthProbe access requests, broad HealthKit queries, and retry attempts on
the restored pre-loss reference device, the user observed that entries dated
2026-05-24 appeared on the device. This was later clarified as fresh data coming
from an Apple Watch paired on 2026-05-24 in an attempt to unstuck Health
synchronization, not as evidence that old data was pulled from or pushed to
iCloud by HealthProbe activity.

Interpretation:
- the restored reference device should not be treated as a stable performance
  benchmark while the Health UI, Health authorization UI, and HealthKit query
  behavior remain unstable;
- snapshots from this period should be labelled as captured during restored
  device instability and Apple Watch pairing/sync-repair experiments;
- the device remains important forensic evidence because HealthProbe operations
  may surface latent Health database or authorization issues;
- 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?
