Data Loss Gate

Data Loss Gate — Confirmation Before Destructive Operations

Convention: see conventions/brain-first.md — inspect the actual target before proposing deletion: get_backlinks, gbrain graph <slug>, git log on the underlying files. The confirmation card below is only as good as the inspection behind it.

Convention: see _brain-filing-rules.md — the post-confirmation deletion log files date-keyed under daily/.

What This Is

A gate that fires BEFORE any destructive operation and requires explicit user confirmation. The agent stops, presents a recoverability card, and waits.

Scope honesty: this gate is a routing convention — the harness resolves it into context when a destructive intent matches, and a well-behaved agent follows it. It is NOT an operation-boundary enforcement: nothing in the gbrain runtime mechanically blocks a delete if the skill never loads. (A native confirm gate at the operation boundary is a filed TODO; until it lands, this convention is the line of defense.) Some CLI surfaces carry their own flag gates — e.g. gbrain sources remove requires --confirm-destructive — but the flag confirms that the AGENT is sure. This skill exists to confirm that the USER is.

When This Fires

Before ANY of these operations:

Shell / filesystem level:

• rm -rf on any directory with data
• rm / unlink on more than 10 files
• sed -i that modifies more than 10 files
• git rm on tracked files
• Truncating or stripping content from files in bulk
• Overwriting files with smaller versions (content stripping)
• Any operation described as "cleanup" or "freeing space" that touches data files

Brain / database level (gbrain-specific):

• Bulk forget — scripting or looping gbrain forget <fact-id> over many facts. One forget is a considered, idempotent act; a forget sweep is data loss.
• Page-delete sweeps — gbrain delete <slug> in a loop, or any script that sweeps delete_page across a set of slugs. Deletes are soft (recoverable via gbrain restore <slug>) until purged — say so on the card, then gate anyway: a sweep that's wrong in bulk is expensive to un-wrong in bulk.
• gbrain pages purge-deleted — permanently removes soft-deleted pages from every source of the brain. This is the point of no return for the soft-delete safety net. Show the user gbrain pages purge-deleted --dry-run --json first; the command itself asks (exit 3 without a terminal) and runs with --yes only after the user agrees.
• Source removal — gbrain sources remove <id> deletes the source AND every page in it. The --confirm-destructive flag does not substitute for the card.
• Mount removal — gbrain mounts remove <id> only removes the local registration (the mounted brain's database survives; re-add to recover). Gate it anyway when the flow ALSO plans to delete the mount's underlying database or files — then the full card applies to those.
• Raw-SQL truncation — any DROP TABLE, TRUNCATE, or DELETE without a narrow WHERE against the brain database, via any path (psql, a migration script, an engine executeRaw call).
• Deleting database rows in bulk; dropping tables, collections, or indexes.

What To Do

Step 1: STOP before executing

Do NOT run the destructive command. Inspect the actual target first (backlinks, graph edges, git history, file contents — whatever grounds the card), then present the user with:

Step 2: The Confirmation Card

⚠️ DATA DELETION — Confirmation Required

What: [exactly what will be deleted/modified]
Count: [number of files/rows/pages/facts affected]
Size: [how much data will be removed]
Location: [exact paths, slugs, or source/mount ids]

Why: [the reason for the deletion]

Recoverable?
- [ ] Backed up to a remote (git remote, database backup, object storage)
- [ ] In git history (can git checkout)
- [ ] Soft-deleted in the brain (restorable via `gbrain restore` until purged)
- [ ] Re-fetchable from an upstream source (which one, how long)
- [ ] NOT recoverable — permanent data loss

What we'd lose:
- [specific data/capability that would be gone]
- [any downstream systems that depend on this data]

Alternative to deletion:
- [compress instead of delete?]
- [move to cold storage?]
- [archive to a remote backup?]
- [soft-delete and defer the purge?]

Proceed? (yes/no)

Step 3: Wait for explicit "yes"

• Do NOT proceed on "ok", "sure", "go ahead" — require "yes" or "do it"
• If the user says "wait" or asks a question, answer it and re-present the card
• If the user says "no", stop immediately and suggest alternatives

For the mechanics of presenting the gate and stopping the turn, use the ask-user choice-gate pattern — this skill supplies the card content and the explicit-yes strictness; ask-user supplies the stop-and-wait discipline.

Step 4: Execute with logging

After confirmation:

1. Log what was deleted to daily/notes/YYYY-MM-DD.md under ## Data Deletions
2. Include: timestamp, what, count, size, recovery path
3. If the deletion is large (>1GB or >1000 files/pages), do it in chunks with progress updates

No Exception Classes

There are no categories of data that are disposable by default. Old logs, git stash entries, build artifacts, caches — each of these has, at some point, been the source of truth for something. Disposability is a property of the SPECIFIC target, verified by inspecting it (backlinks, git status, what depends on it, whether it's re-fetchable and at what cost) — never a property of its category. If the inspection genuinely shows the target is ephemeral and regenerable, the card is quick to fill out and the user's "yes" is quick to get. That's the cost of the gate working.

Why This Exists

A downstream agent once deleted a multi-gigabyte cache of raw source files from its brain's data directory to free disk space. The files looked like "just cache" — but they were the source data for a planned feature. The data happened to be re-fetchable from its upstream source, but the deletion was still wrong because:

1. It destroyed work that had a planned use
2. It happened without the data owner's consent
3. The "cleanup" framing made it seem safe when it wasn't

The rule: if it's data and it's bulk, ASK FIRST. Always.