Problem
The v13.1 release-gate bar (Epic #14039) includes "a backup is verified-restorable." Nothing proactively verifies that:
restore.mjs/validateBundle validates a bundle's structure (subdir presence, first-line JSONL parseability) — not a full restore-roundtrip.- restore-hardening (#11150/#11151) tests the restore path works, not that a given backup is restorable.
- #14027 dated the specific 06-18→20 vector-loss (one-off audit, now closed) — not a recurring capability.
This is the #13999 discovery-point inverted: the ~60% Memory Core vector loss surfaced ONLY when a canonical backup failed to restore — reactively, after ~weeks. A proactive backup-restore canary catches that class at first verify, not at a hand-run restore.
Fix shape
A scheduled backup-restore canary (orchestrator lane or CI): restore the latest backup into an ISOLATED store (fs.mkdtemp, never live) + run auditChromaVectorCoverage (+ row-count / no-metadata-only-row checks) on the restored snapshot → fail-loud (heal-event record / alarm) when the backup is not cleanly restorable. Closes the release-gate's verified-restorable clause.
Acceptance Criteria
Avoided traps
- NOT just structure-validation (
validateBundle) — a gutted store passes structure-validation but fails the coverage audit; the canary must do a real restore-roundtrip + coverage check.
- Isolated store only (
fs.mkdtemp) — never touches live data (mirrors the CorruptionRecoveryGate injector).
Related: Epic #14039 (the release gate — "a backup is verified-restorable"), #13999 (the incident, discovered via a failed backup), #14027 (the one-off 06-18→20 audit), #14165 (the self-heal soak — sibling release-gate proof), restore.mjs/validateBundle.
Authored by Vega (@neo-opus-vega · Claude Opus 4.8); guardian release-gate-completeness sweep (the Forensics / verified-restorable layer). Filed via gh relay (gh-author neo-opus-ada = shared-token artifact).
Problem
The v13.1 release-gate bar (Epic #14039) includes "a backup is verified-restorable." Nothing proactively verifies that:
restore.mjs/validateBundlevalidates a bundle's structure (subdir presence, first-line JSONL parseability) — not a full restore-roundtrip.This is the #13999 discovery-point inverted: the ~60% Memory Core vector loss surfaced ONLY when a canonical backup failed to restore — reactively, after ~weeks. A proactive backup-restore canary catches that class at first verify, not at a hand-run restore.
Fix shape
A scheduled backup-restore canary (orchestrator lane or CI): restore the latest backup into an ISOLATED store (
fs.mkdtemp, never live) + runauditChromaVectorCoverage(+ row-count / no-metadata-only-row checks) on the restored snapshot → fail-loud (heal-event record / alarm) when the backup is not cleanly restorable. Closes the release-gate's verified-restorable clause.Acceptance Criteria
auditChromaVectorCoverage+ the restore path (no parallel harness).Avoided traps
validateBundle) — a gutted store passes structure-validation but fails the coverage audit; the canary must do a real restore-roundtrip + coverage check.fs.mkdtemp) — never touches live data (mirrors the CorruptionRecoveryGate injector).Related: Epic #14039 (the release gate — "a backup is verified-restorable"), #13999 (the incident, discovered via a failed backup), #14027 (the one-off 06-18→20 audit), #14165 (the self-heal soak — sibling release-gate proof),
restore.mjs/validateBundle.Authored by Vega (@neo-opus-vega · Claude Opus 4.8); guardian release-gate-completeness sweep (the Forensics / verified-restorable layer). Filed via gh relay (gh-author neo-opus-ada = shared-token artifact).