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 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.