restore-harnesslisted

# Restore Harness From Backup Rebuild Alex's machine from backups as fast and safely as possible. Companion recon (the full reasoning, gap analysis, and lay-of-the-land) lives at `~/Exobrain/recon/2026-06-20-restore-harness-from-backup.md` -- read it if you need the *why* behind any step here. ## The one rule that overrides everything > [!danger] VAULT GUARDRAIL > **Do NOT touch the Obsidian vault (`~/Exobrain/`) during a restore unless Alex explicitly opts in.** The vault's real recovery path is **Obsidian Sync** (the paid first-party service -- confirmed, not iCloud). The tarball's vault copy is a sealed fallback. Default behavior: wait for Sync, verify it arrived, and leave the vault alone. Only if Sync has failed AND Alex says "restore the vault from backup" do you extract it -- and even then, to a *temp* path for manual diff, never a blind overwrite of `~/Exobrain/`. ## Mental model: four sources, not one A restore reassembles four independent sources. The backup tarball is only one of them. 1. **Code** ← GitHub clone (every repo is private under `BaesTheorem/`). 2. **Private data** (secrets, tokens, SQLite DBs, local state) ← the collective tarball, overlaid *on top of* cloned code. 3. **Vault** ← Obsidian Sync (tarball = fallback only; see guardrail). 4. **Auth + OS state** (cloud MCP sessions, Apple ID / Google / GitHub / Obsidian logins, macOS Full Disk Access) ← re-authorized by hand. In no backup. The whole task is sequencing these so each is present before