+# 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:

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

+| Project memory, recovered context, reference devices/datasets | [`04-project/Development-Log.md`](04-project/Development-Log.md) |

+- [`04-project/Development-Log.md`](04-project/Development-Log.md)

+  Project memory log for recovered context, reference devices/datasets, and

+  decision-relevant history that should survive agent handoffs.

+