/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 purge-deleted`** — permanently removes soft-deleted pages. This is

the point of no return for the soft-delete safety net.

• **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](../ask-user/SKILL.md) 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

##