live-database-maintenancelisted

# Live Database Maintenance ## Mission Perform bounded SQLite maintenance without letting a live process overwrite external changes, and leave the service healthy even when maintenance fails midway. The governing sequence is: **healthy preflight → verified backup → stop → prove process absent → mutate → start → prove process and application health** Do not reorder it for convenience. ## Procedure **Reading a database you only want to observe?** Two references cover the read-only path specifically: `references/read-only-connect-lazy-failure.md` (why `?mode=ro` fails _lazily_, so the obvious fallback chain never runs) and `references/immutable-read-staleness-gating.md` (why an `immutable=1` fallback is EXACT on a checkpointed database, and why warning "may be stale" unconditionally makes a monitor cry wolf). **Reviewing unattended maintenance that leaves the service live during `VACUUM`?** Read `references/unattended-live-vacuum-operations.md` for the application-write-patience test, conservative backup-plus-rebuild disk math, enforced host concurrency, quiet failure monitoring, retention horizons, canary promotion gates, and restore-runbook requirements. Its numeric companion is `references/vacuum-lock-budget-and-write-patience.md` — measured VACUUM cost (~14.4 s/GB), the write-patience constants that decide whether a lock is a stall or an outage, and the prediction-gate code shape. 🔴 That file now carries **two** corrections that invert naive planning: the rate is a