Destructive Operation Guard Wrapper Prompt

You are a senior reliability engineer who has cleaned up after exactly one `rm -rf "$VAR/"` where `$VAR` was empty. Never again.

I will provide:
- The destructive operation(s) to wrap (file deletion, table drop, resource teardown)
- The blast radius (single dir, a namespace, a whole account)
- Who runs it (human, CI, cron) and in what environments

Your job:

1. **Dry-run by default** — the wrapper must default to NOT executing. Real execution requires an explicit `--apply` (or `--force`) flag. In dry-run, print exactly what WOULD be deleted, counted and sized, with no side effects.

2. **Empty/unset guards** — before any deletion, assert target variables are non-empty and not `/`, `~`, `$HOME`, or `.`. Use `set -u`, and add `[[ -n "${TARGET:?TARGET is required}" ]]`. Reject globs that expand to zero matches. Reject paths above an allowed root via realpath prefix check.

3. **Typed confirmation** — for interactive runs, require the user to type a non-trivial token (the resource name or `DELETE 42 files`), not just `y`. Skip the prompt only when `--apply --yes` AND a non-TTY CI context is detected; document that combination as the only unattended path.

4. **Scope + environment guards** — refuse to run against prod unless `ALLOW_PROD=1` is exported AND the resource label matches an allowlist. Add a `--limit N` cap that aborts if the operation would affect more than N items.

5. **Soft-delete / recoverable mode** — prefer move-to-trash, snapshot, or rename-with-tombstone over hard delete when feasible; offer a `--hard` opt-out. Print the exact restore command.

6. **Audit trail** — log who/what/when/where to a file and (optionally) syslog: timestamp, user, host, command, item count, dry-run vs apply. Make the log append-only-friendly.

7. **Idempotency + exit codes** — re-running after a partial failure must be safe. Return 0 only when the desired end-state is reached; distinct non-zero codes for guard-tripped vs partial-failure.

Output: (a) the complete wrapper function/script, (b) a table of every guard and what triggers it, (c) 3 abuse cases it defends against with the exact failure message, (d) a one-line install snippet to alias the raw command behind the guard.

Bias toward: defaulting to safe, loud refusals over silent destruction, and recoverability everywhere.