# Blast Radius Review Lens

Review operational scripts for **change safety, risk containment, and reversibility**.

## What to Look For

### Targeting & Scoping
- Wrong or ambient context: relying on current kubectl context, AWS profile, gcloud project
- Missing explicit flags: `--namespace`, `--context`, `--region`, `--project`
- No environment gates: prod operations without `CONFIRM_PROD=1` or `--env prod`
- Hardcoded production targets without verification

### Destructive Operations
- `rm -rf`, `DROP TABLE`, `docker system prune` without confirmation
- Empty variable expansion: `rm -rf $DIR/` when DIR could be empty (use `${DIR:?}`)
- Bulk deletes without limits or batching
- Operations that cannot be undone without backup/snapshot first

### Missing Dry-Run Mode
- Scripts that modify state without `--dry-run` or `--check` flag
- No preview before execution (`kubectl diff`, `terraform plan`)
- Destructive defaults (should require explicit `--apply` or `--force`)

### Rollback & Recovery
- No backup/snapshot before risky changes
- Missing rollback instructions or automation
- Note: Nix/NixOS has generation rollback - verify scripts use `nixos-rebuild` properly
- Database migrations without down/rollback path

### Pre-flight Checks
- Missing connectivity/auth verification before bulk operations
- No target verification (`kubectl config current-context`, `aws sts get-caller-identity`)
- Missing dependency checks (required tools, permissions, disk space)

### Bulk Operations
- All-at-once without batching or progressive rollout
- No pause/resume capability for long-running operations
- Missing locking to prevent concurrent runs (`flock`)

## Output Format

```
[BLAST] <severity:HIGH|MED|LOW> <file:line>
Issue: <what could go wrong>
Scope: <single file | service | host | fleet | cluster>
Suggest: <add dry-run, confirmation, backup, scoping, etc.>
Evidence: <destructive command or pattern identified>
```

## Mitigations That Reduce Severity

If these are present, consider downgrading:
- Explicit backup/snapshot step immediately prior
- Dry-run/plan output with explicit apply gate
- Narrow scope (specific namespace, labeled resources)
- Confirmation prompt for interactive use
- Running on ephemeral/test resources

## Guidelines

- **HIGH** = data loss or outage, broad scope, no recovery path
- **MED** = risky operation without safety nets, narrow scope
- **LOW** = missing best practice, ephemeral/test targets
- Focus on *implications*: what's the worst case? Can we recover?
- Context matters: `rm -rf /tmp/cache` is LOW, `rm -rf /data/$VAR` is HIGH
- Consider: unattended (cron/CI) operations need stricter gates
- Nix/NixOS: acknowledge generation rollback when applicable
