/data-loss-gate

name: data-loss-gate
version: 1.0.0
description: >
  Confirmation gate before any bulk delete, cleanup, or destructive operation
  that could result in data loss — shell-level (rm -rf, git rm, bulk sed) or
  brain-level (bulk forget, delete sweeps, purge-deleted, source removal,
  raw-SQL truncation). Presents a recoverability card and requires an explicit
  "yes" from the user before proceeding. Routing convention, not an
  operation-boundary enforcement.
triggers:
  - "bulk delete"
  - "wipe the"
  - "rm -rf"
  - "purge the"
  - "truncate"
  - "free up space"
  - "bulk forget"
  - "remove the source"
  - "drop the table"
mutating: true
writes_pages: true
writes_to:
  - daily/
upstream: data-loss-gate@fc834ee
# Brain-first applies in its inspection form: before deleting brain pages,
# check backlinks / graph dependencies (get_backlinks, graph) so the card's
# "what we'd lose" section is grounded in the actual target, not guesses.
brain_first: true

Data Loss Gate — Confirmation Before Destructive Operations

> **Convention:** see [conventions/brain-first.md](../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](../_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 delete --purge`** — skips the 72-hour soft delete and removes the

page at once with its chunks, versions, takes, timeline, links, raw data and the facts filed on it. `gbrain restore` cannot undo it. Every purge needs the user's explicit go for that purge: a request to "scrub the repo", "clean up the files" or "remove it from Git" is not a go to purge database pages. After the go, purge one page at a time (never a parallel `xargs` or a background loop), confirm each one is gone (`gbrain get <slug> --include-deleted` reports `page_not_found`) before the next, and stop the batch at the first refusal. A purge batch that was stopped (SIGTERM, a write freeze, a timeout) stays stopped: report what finished and ask again before relaunching it.

• **`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. It keeps a file committed at the source's last synced commit or at HEAD (the page waits or goes database-only), unless a person's delete of the page never removed the file (e.g. another page shared it).

• **Source removal** — `gbrain sources remove <id>` deletes the source AND

every page in it. The `--confirm-destructive` flag does not substitute for the card. A managed removal deletes pages in committed batches: one that stops early (`write_pending`) has already deleted some, so say so and rerun it to finish.

• **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,