{ "findings": [ { "severity": "Important", "file": "scripts/health/migrate_sprint7c_f_medication_schema.py", "line": 180, "issue": "safe_prepare() does not require source, backup, migrated, and restore_proof to resolve to four distinct paths. If --migrated and --restore-proof name the same initially absent path, the restore proof is created successfully and then overwritten by the migrated candidate. The report still claims an independent restore proof, invalidating the copy-first rollback evidence.", "remediation": "After resolving all four paths, fail closed unless they are pairwise distinct, including same-inode and symlink-alias checks. Preserve the restore proof as an immutable separate file and verify its hash again before returning the report." }, { "severity": "Important", "file": "scripts/health/health_dashboard_action_worker.py", "line": 1069, "issue": "The preview revision for an administration bound to a planned event hashes only the prescription and the immutable planned row. Consuming that plan by inserting an administration does not change either object, so the same preview remains valid. A later request with a different time or dose bypasses the exact duplicate query and can record another administration against the already-consumed plan.", "remediation": "Include the derived plan-consumption state in the preview revision and recheck it in the same BEGIN IMMEDIATE transaction. Enforce at the database layer that a planned event has at most one effective administration or missed event, with corrections handled through an explicit version lineage." }, { "severity": "Important", "file": "database/schema.sql", "line": 265, "issue": "The retained UNIQUE(datum, medication_name, event_type) constraint prevents two legitimate structured administrations of the same medication on one day, even when occurred_at, dose, or planned event differ. duplicate_confirmed cannot override this constraint. It also prevents recording multiple distinct corrections for the same medication on the same correction date.", "remediation": "Use a copy-first schema design in which structured events are uniquely identified by immutable event identity rather than the legacy day/name/status tuple. Preserve legacy rows and V4 compatibility, but ensure the structured write target permits distinct same-day events and add regression tests for twice-daily administrations and multiple independent corrections." }, { "severity": "Important", "file": "scripts/health/dashboard_v5/medication_schema.py", "line": 98, "issue": "Corrections are not a sustainable append-only version history: ux_medication_correction_origin permits only one correction per original event, while the validation trigger and worker prohibit correcting a correction event. If the first correction is itself wrong, no further append-only correction can supersede it without mutating or deleting history.", "remediation": "Model correction lineage with a stable root event and monotonically increasing immutable versions. Permit a new correction of the latest effective version, reject references to non-latest versions and actual cycles transactionally, and derive the effective event from the latest version without changing prior rows." } ], "verdict": "CHANGES_REQUESTED: four Important database-correctness issues remain. The focused Sprint file compiled successfully, dashboard-v5-record.js passed node --check, and no V4 file diff was detected. The pytest suite could not be rerun because pytest is not installed in the available Python environments; no repository files were edited." }