# HealthManager Read-only Adapter Design

## Why Health differs from Finance

Finance already passed a local read-only HTTP smoke gate. Health is more sensitive because the runtime may contain medical history, source documents, extracted text, clinician report material, tracker exports, and database content. Phase 6A therefore introduces only a safe status probe, not a full live adapter.

## Local HealthManager inventory

Code-level inspection found a script/pipeline repository with README, workflow documentation, database schema, cron scripts, and dashboard/report scripts. The repository documents that productive data is stored outside Git and that Git contains code, documentation, and schema only.

Observed code-level components:

- pipeline scripts under `scripts/health/`
- cron/sync scripts under `scripts/cron/`
- workflow documentation under `docs/`
- skill/runbook material under `skills/`
- a schema-only database directory
- no safe HTTP status API equivalent to FinanceManager was identified in this phase

No productive health database, PDFs, reports, tracker exports, OCR files, or source documents were opened.

## Adapter modes

- `mock`: default, synthetic snapshot only.
- `disabled`: safe degraded snapshot with no runtime access.
- `local_probe`: explicit opt-in using `HEALTH_RUNTIME_BASE`; metadata-only local probe.

## Probe behaviour

`local_probe` checks only local metadata:

- runtime directory exists
- bounded file count
- extension count
- latest metadata modification time
- freshness category
- synthetic review count from safe marker extensions only

The probe never outputs the configured path and never reads file contents.

## Gates before richer Health integration

Before any future Health details are shown, a separate gate must approve data classification, endpoint/source inventory, sanitizer mappings, 4-eyes review requirements, and explicit UI redaction rules.

## Phase 6B inventory decision

The safe inventory matrix confirms that the current `local_probe` should remain metadata-only. Runtime directories, backup markers, cron markers, and pipeline markers can be considered only as existence/freshness/count signals. Reports, database rows, OCR, PDFs, tracker exports, and logs remain forbidden as adapter inputs.

No new Health UI or content integration is approved by this phase. Future work should first create a HealthManager-owned safe status marker/API that emits only the approved contract fields.

## Phase 6C safe marker decision

`safe_marker` is now an explicit adapter mode for a HealthManager-owned safe status marker. It reads exactly one configured marker file, validates `schemas/health-safe-status-marker.schema.json`, applies the Health sanitizer, and maps only enum/count metadata into the Health `ModuleSnapshot`.

Default remains `mock`; `make verify` and GitHub Actions do not require any marker or Health runtime. The optional smoke is `make smoke-health-safe-marker` and uses a synthetic temporary marker only.