OPS-05 · SEC. 03 Operations & DevOps

Destructive Cleanup Blast-Radius Check

Force a recoverability check before any delete, drop, or force-push touches real state.

FORMAT: loop
DIFFICULTY: advanced
TIME: 6 min
TOOLS: universal
MODELS: any
COPIES: 0 so far

When to use this

You're about to run a command that destroys data or history (`rm -rf`, `DROP TABLE`, `git branch -D`, `git worktree remove --force`, `git push --force`) where a mistake isn't fixable by just re-running the last command.

The pattern

Pastes as plain text

Before running any command that deletes, drops, force-overwrites, or
otherwise destroys data or history (including but not limited to `rm -rf`,
`DROP TABLE`/`TRUNCATE`, `git branch -D`, `git worktree remove --force`,
`git push --force`, or a migration that removes a column), stop and run
this check instead of the command:

1. Name the exact command and its target.
2. Answer: is this recoverable if it turns out to be wrong, and how?
   - Recoverable (e.g. reflog, trash, a known backup exists): name the
     specific recovery path.
   - Not recoverable (e.g. no backup, force-push overwrites shared history,
     production data with no snapshot): say so plainly.
3. For anything touching a shared or production surface (a shared branch,
   a shared database, anything other people rely on), treat it as NOT
   RECOVERABLE regardless of technical reversibility. The blast radius
   includes other people, not just data. When in doubt about whether
   something is shared, treat it as shared.
4. Regardless of recoverability, stop, state the recovery path or its
   absence, and ask for explicit confirmation before running the command.
   Recovery information informs the decision; it is never authorization.

Real example output

Command: DROP TABLE staging_import_backup;
Target: staging_import_backup table, Supabase project "masjidos-staging"

Recoverability: RECOVERABLE. Point-in-time recovery is enabled on this
project with a 7-day window, and this table hasn't been written to in 11
days; a PITR restore to any point in the last week would bring it back if
needed. Also confirmed no other table has a foreign key into it.

Stopping: this is recoverable, but still destructive. Awaiting your explicit
confirmation before dropping staging_import_backup.

---

Command: git push --force origin main
Target: main branch, shared remote

Recoverability: NOT RECOVERABLE by policy: this touches a shared branch.
Reflog technically covers it locally, but two other people have main
checked out, and a force-push would silently rewrite their history too.

Stopping. Do not run this without your explicit confirmation, and
recommend `git push --force-with-lease` at minimum if you do confirm.

Why it works

Naming the recovery path before running the command turns "is this safe" into a specific, checkable answer instead of a gut feeling. Treating anything shared as not-recoverable by policy, even when it's technically reversible, accounts for the actual risk: other people's state, not just yours.

Related patterns

OPS-12Rollback Readiness CheckBefore you deploy, confirm you can actually roll back, not just that the deploy itself is clean.OPS-10Pre-Push, Pre-Merge Approval GateStop an agent from pushing or merging without your explicit go-ahead, every time.OPS-07Parallel Worktree Risk AuditSweep every worktree before touching any of them, and label each safe or risky.