Context
Parent epic #10945 calls for deployment-pipeline integration coverage that is stronger than heartbeat checks. Backup and wipe-detection primitives have existed as adjacent work, but the deployed Docker integration stack still needs an end-to-end proof across Memory Core storage surfaces.
Duplicate sweep before filing:
gh issue list --search "backup restore wipe Memory Core Chroma graph" found #10945 only.- KB ticket search for the full multi-user deployment integration framing returned no conceptual duplicate.
- Adjacent primitives include #10844/#10854; this ticket is the deployed-stack integration proof.
The Problem
Memory Core health can be green while data durability is broken. The recent wake/SQLite incident and prior backup/wipe work show that the real product risk is not just process liveness; it is whether Chroma memory data and the better-sqlite Native Edge Graph can be backed up, detected after a wipe/collapse, restored, and queried again.
Without a deployed integration test, these pieces can drift independently.
The Architectural Reality
Relevant surfaces:
ai/deploy/docker-compose.test.yml and integration fixtures for the deployed test stack.- Memory Core Chroma collection data for raw memories/session summaries.
- Memory Core better-sqlite graph database for Native Edge Graph topology.
- Existing backup/wipe-detection primitives from #10844/#10854 lineage.
- Healthcheck and integrity surfaces that should distinguish liveness from data-readiness.
The Fix
Add a deployed-stack integration proof that seeds representative Memory Core data, snapshots it, simulates a destructive wipe/collapse in isolated test data, restores from backup, and verifies both semantic retrieval and graph topology/count integrity.
The test must use isolated Docker/tmp volumes and must not touch developer or production Memory Core data.
Contract Ledger Matrix
| Target Surface |
Source of Authority |
Proposed Behavior |
Fallback |
Docs |
Evidence |
| Chroma Memory Core data |
#10945 durability lane |
Seeded memories/summaries survive backup -> wipe -> restore |
If summaries are unavailable, raw memories are first-pass minimum with explicit follow-up |
Deployment recovery docs if touched |
Query after restore returns seeded data |
| better-sqlite Native Edge Graph |
#10944 storage reality and graph substrate |
Graph nodes/edges survive backup -> wipe -> restore |
If graph backup API is not public, expose test-only script or document missing substrate |
MemoryCore/SharedDeployment recovery docs |
Graph count/topology after restore matches pre-wipe baseline |
| Wipe detection |
Prior wipe-detection lineage |
Detects destructive collapse before restore is declared healthy |
Health-only checks must not count as durability proof |
Healthcheck docs if touched |
Integration assertion fails on wiped state before restore |
Acceptance Criteria
Out of Scope
- Designing a production backup product UI.
- Running destructive tests against any shared live Memory Core database.
- Solving every backup format optimization.
Related
Parent: #10945
Adjacent: #10844, #10854, #10944, #9999
Origin Session ID: c02fbf4e-870c-44c0-ba7e-e9ffacce094b
Retrieval Hint: query_raw_memories(query="Memory Core backup restore wipe detection Chroma better-sqlite graph deployed integration")
Context
Parent epic #10945 calls for deployment-pipeline integration coverage that is stronger than heartbeat checks. Backup and wipe-detection primitives have existed as adjacent work, but the deployed Docker integration stack still needs an end-to-end proof across Memory Core storage surfaces.
Duplicate sweep before filing:
gh issue list --search "backup restore wipe Memory Core Chroma graph"found #10945 only.The Problem
Memory Core health can be green while data durability is broken. The recent wake/SQLite incident and prior backup/wipe work show that the real product risk is not just process liveness; it is whether Chroma memory data and the better-sqlite Native Edge Graph can be backed up, detected after a wipe/collapse, restored, and queried again.
Without a deployed integration test, these pieces can drift independently.
The Architectural Reality
Relevant surfaces:
ai/deploy/docker-compose.test.ymland integration fixtures for the deployed test stack.The Fix
Add a deployed-stack integration proof that seeds representative Memory Core data, snapshots it, simulates a destructive wipe/collapse in isolated test data, restores from backup, and verifies both semantic retrieval and graph topology/count integrity.
The test must use isolated Docker/tmp volumes and must not touch developer or production Memory Core data.
Contract Ledger Matrix
Acceptance Criteria
Out of Scope
Related
Parent: #10945 Adjacent: #10844, #10854, #10944, #9999
Origin Session ID: c02fbf4e-870c-44c0-ba7e-e9ffacce094b
Retrieval Hint:
query_raw_memories(query="Memory Core backup restore wipe detection Chroma better-sqlite graph deployed integration")