Skip to content

MedTracker 0.6 release notes

These notes describe merged work targeted to 0.6. They do not announce a release, beta readiness or production deployment. Release PR #2381 remains held.

Why we are moving to Rust

The main goal for 0.6 is lower operating RAM so MedTracker can run on more modest hardware. The local comparison supports that direction for the tested workload; it does not establish production capacity or a general language advantage. Read Moving MedTracker from Rails to Rust: memory, latency and trade-offs for the story, measured benefits and development trade-offs, or the technical benchmark report for methods, limits and evidence.

Before installing

MedTracker runs as a Rust application using Loco 1.2, Tera and PostgreSQL 18. Install it with a new empty database and create fresh accounts. Rails passwords, passkeys, authenticator enrolments, sessions and recovery tokens are not imported. There is no Rails schema adoption, credential conversion or reverse migration. This release documentation describes a fresh installation; it does not define a live cutover or Rails recovery plan. See the fresh Rust installation notes.

Rust supports versioned encrypted portable export and import as documented in the portable-data contract. That support does not prove that every Rails export can be restored. The Rails fixtures are frozen synthetic examples; they do not establish database-backed export selection or cover every Rails record and history combination. Rust rejects older v1/v2 bundles with non-empty obsolete person-location links, and rejects v1/v2 history where a dose's original storage location differs from the medicine's current location. The broader compatibility inventory remains in #2702; it is not a requirement to plan or perform a Rails cutover for this release.

PR #3029 adds checks for incomplete retained prescription history. Existing snapshots whose completeness is unknown remain blocked from adoption and fresh dose recording. The change does not recover or certify their history; no recovery procedure is promised. Profile JSON/ZIP restoration is separate scope tracked by #2513.

Merged changes

  • Account signup, invitations, password and passkey sign-in, optional TOTP, recovery and session controls use native Better Auth. Passkey-only users add a password before enabling TOTP. Recovery codes complete the second sign-in step; they do not sign in alone.
  • Household administration includes member controls, invitation sending status, bulk access changes and security history. Sending status does not prove inbox delivery. Household membership alone does not define authority over a person's treatment plan.
  • Account-owned dose-history reading is delivered (#2982; first-release history issue #2685 is closed). This does not mean person-owned shared treatment plans are complete.
  • Care edits use current self/eligible guardian authority rather than legacy Manage grants (#2883). Household-bound OAuth consent uses the selected household, binds approval to the displayed household and rechecks access; mobile OAuth remains account-bound (#2885). These merged checks do not prove a live ZITADEL configuration or physical passkey works.
  • Dose and treatment forms use validated typed commands. Malformed dose retries retain conflict responses instead of changing them into validation errors. Stock deduction and clinical history remain part of the recorded operation.
  • Deleting a storage location is rejected while medication or historical doses reference it. Empty, unreferenced locations can be deleted without cascading through care records. Optional medication locations remain unfinished.
  • Rust-native encrypted portability supports version 3 without obsolete person location memberships. Older v1/v2 bundles containing those obsolete links are rejected. Medication storage locations and historical taken-from locations remain distinct. This is not a profile ZIP restore feature.
  • Root Loco server, worker and scheduler images support linux/amd64 and linux/arm64. The root-Loco workflow checks both architectures, scheduler execution and transferred image integrity before publication. It publishes Loco images from main and supports release-specific image publication. PR #3028 archived the Rails application and removed the separate Rails publisher. The scratch image has no shell; configured native scheduler tasks execute directly. See image operations.

Still in progress

The 0.6 milestone remains open. Person-owned shared treatment plans and cross-household sharing remain unfinished (#2684 and #2976); household administration does not grant authority to change another person's plan. Live provider and real-passkey acceptance remain tracked by #1889. Optional medication locations remain paused for the owner's UI audit. Physical phone-camera checking (#2524) is follow-up fix-forward work; simulated camera input does not prove physical-device acceptance. Accessibility work is tracked separately under #2709.

The owner's release and deployment decisions are separate from these notes. Image publication and production deployment are separate actions.