Release status and compatibility
Health.md has independently versioned products. A version number or successful connection does not qualify every topology.
Current status
Section titled “Current status”| Component | Release identity | Current support state | Qualification boundary |
|---|---|---|---|
| iPhone, iPad, Mac, and Apple Watch apps | v<version> |
App Store product | Each release note must name tested Apple OS versions. macOS 27 remains not certified until the RC and public-build physical matrix is retained. |
Bundled Mac healthmd-mcp |
Same v<version> as the Mac app |
Production component | Uses encrypted Mac context and the Mac app’s authenticated iPhone connection. It is not the standalone CLI and has no separate 1.0 milestone. |
Standalone healthmd and healthmd mcp serve |
healthmd-cli/v<version> |
0.1.0-alpha.7 is an explicitly unqualified preview |
No CLI/mobile pair is qualified for stable 1.0 yet. Published alpha.7 has 19 MCP tools; current development has 21. |
| Website | Commit deployment | Documentation | Describes released behavior separately from development behavior. |
There is no committed date for standalone CLI 1.0. Stable status requires the exact retained macOS, Linux, Windows, iPhone, Android, LAN, and Tailscale matrix—not just automated tests or a pairing smoke check.
Machine-readable checks
Section titled “Machine-readable checks”Call healthmd_doctor before automation and healthmd_capabilities when choosing tools.
- The bundled Mac endpoint reports app/helper version, production-component status, running macOS, macOS 27 qualification state, encrypted owner-day/byte totals, connected iPhone version/protocol, and the history-authorization contract.
- The standalone preview reports its exact package version,
preview_unqualified,cli_1_0_qualified: false, negotiated source version/build/OS when supplied, and OS 27 history authorization state. limited_historymeans earlier Apple Health data is unknown, not absent.api_unavailablemeans the runtime cannot verify the boundary. Neither should be rewritten as “complete history.”
Machine-readable status is evidence about the running components. It does not replace retained release qualification.
Notifications
Section titled “Notifications”Use the versioned sources that match the product:
- Apple apps: GitHub releases tagged
v<version>and App Store update notes. Apple releases retain the repository-wide “Latest” release. - Standalone CLI: GitHub releases tagged
healthmd-cli/v<version>. CLI releases deliberately usemake_latest=false; do not use/releases/latestto discover them. - All repository releases: GitHub Releases Atom feed. Filter by tag prefix if you only want Apple or CLI updates.
- Source changes: repository commits are development evidence, not release availability.
Every automation/OS release note must state: exact app/helper/CLI version, release channel, supported/qualified OS builds, compatible mobile build/protocol, history-boundary behavior, tool count, and known pending physical gates.
macOS 27
Section titled “macOS 27”Preparation and automated checks may run before release, but “certified for macOS 27” is allowed only after:
- the candidate is built from committed, pushed source;
- signing, nested helpers, notarization, Keychain, encrypted context, bookmarks, loopback MCP, iPhone LAN/Nearby/Tailscale, durable jobs, sleep/wake, and upgrade paths pass on the RC;
- the critical matrix is repeated on Apple’s public macOS 27 build;
- a health-free evidence record identifies exact OS/app/build/artifact hashes.
Until then, readiness reports certified_for_macos_27: false.
Choosing a topology
Section titled “Choosing a topology”Use the bundled Mac MCP for routine local analysis and offline/repeated queries from encrypted context. Use the standalone preview only when you need direct cross-platform scripting, fresh foreground-phone reads, canonical extraction, or durable archival jobs and accept its preview qualification state. The two can coexist, but they do not share trust, credentials, jobs, or cached health data.