safety: close four classifier coverage gaps

[trungutt]

Why

The shell-safety classifier reports unknown — losing the blast-radius label and category tag it would otherwise expose — for a set of commands that are unambiguously destructive, and under-reports the blast radius on two docker commands where a critical flag is present but appears in a non-canonical position. Permissive safety modes end up asking for confirmation without saying why, and (for the flag-order cases) miss that the user is asking to delete named volumes.

Four independent gaps, one commit each:

1. Flag-order variants for docker system prune --volumes and docker compose down -v

Destructive patterns are matched contiguously. docker system prune --volumes (HIGH) does not cover docker system prune -f --volumes because -f sits between the two anchor tokens, so the command falls back to bare docker system prune (MEDIUM) even though the --volumes flag is present and named volumes will be wiped.

The same shape recurs on compose: docker compose down --volumes (HIGH) does not cover docker compose down --remove-orphans -v or docker compose down -v --remove-orphans.

Fix: enumerate the observed flag orderings for -f / -a / -af / -fa / -v / --volumes / --remove-orphans.

2. PowerShell destructive patterns

The taxonomy is Unix-only. Windows users running the shell tool in PowerShell produce destructive commands (Remove-Item -Path <path> -Recurse -Force, Clear-Content) that classify as unknown. Add fs-delete and fs-overwrite entries for the PowerShell equivalents, covering positional/-Path/trailing-path forms and both -Recurse -Force and -Force -Recurse orderings.

3. Destructive SQL, app-CLI, and key-value patterns

Destructive intent frequently arrives via a wrapper — docker exec <ctr> …, kubectl exec …, an SSH login — that hides the dangerous verb inside the inner command. Because the existing taxonomy only inspects the outer shell verb, real data-loss commands (DROP DATABASE, TRUNCATE TABLE, redis-cli FLUSHALL, n8n db:reset, rails db:reset, bench new-site --force, …) come back as unknown.

Add pattern groups that fire on the destructive verb wherever it appears, so wrapping through docker exec / kubectl exec / ssh inherits the classification automatically:

• SQL DDL/DML: drop database, drop schema, drop table, truncate table, delete from (covers mysql -e, psql -c, sqlite3 db "…", mariadb -e).
• App-framework resets: n8n db:reset, n8n user-management:reset, bench new-site --force, bench drop-site, rails db:drop / db:reset / db:schema:load, manage.py flush, prisma migrate reset, sequelize db:drop.
• Key-value flushes: redis-cli flushall, redis-cli flushdb.

4. Whitespace anchor for shell-metachar patterns

The destructive-pattern regex prefix is (?:^|.*\b), which fires on any word boundary. That's the right anchor for alphanumeric verbs (rm, docker), but wrong for patterns whose leading token is itself a shell metacharacter — >, <, |, &, ;. A word boundary sits between any word char and the metachar, so:

• --email <EMAIL> --firstName Admin matched the truncate pattern > <file> via the l> boundary inside a redacted placeholder. This is the only case that reproduced on master; the placeholder shape (word-char, >, space) is what defeats the \b anchor.

Anchor shell-metacharacter patterns on \s instead: a real redirect, pipe, or chain operator is preceded by whitespace (or start of line) after normalizeCommand collapses runs to single spaces. Verbal patterns keep the \b anchor.

Notes for the reviewer

Each commit is standalone and lands one gap. Regression tests are colocated in safety_test.go in each commit.

[Sayt-0]

Solid direction: each gap is real, the commits are atomic, and the whitespace-anchor fix removes a confirmed false positive. Two behavior changes need attention before merge, and roughly half of the new pattern entries are already covered by existing ones.

Verified behavior deltas (master vs this branch):

command	master	this PR	restricted mode impact
grep "drop table users" -r .	safe	destructive / high	ALLOW to DENY
git log --grep "delete from cart"	safe	destructive / medium	ALLOW to DENY
rg "DELETE FROM users"	safe	destructive / medium	ALLOW to DENY
run 1> /tmp/out.log	destructive / medium	unknown	none (ask either way)
docker exec ... --email <EMAIL> ...	destructive / medium (FP)	unknown	none

Blocking:

• The unanchored SQL patterns flip safe-listed read-only searches to destructive (table above). Since destructive matching wins over the safe list, any grep/rg/git log --grep whose argument contains SQL text now prompts under balanced and is denied under restricted. This trade-off may be acceptable (precedent: grep "rm foo" already matches rm <single-file>), but it is a silent behavior change for a common agent workflow and deserves an explicit decision, a note in the taxonomy, and regression tests either way.

Non-blocking but worth fixing in the same pass:

• 6 of the 9 new docker entries are already covered by existing patterns (details inline); the pattern language's ... wildcard can replace the enumeration entirely.
• Remove-Item "C:\Program Files\..." -Recurse -Force classifies LOW because <path> compiles to \S+ and cannot span a quoted path with spaces (details inline).
• redis-cli -h host FLUSHALL and bench new-site <site> --force fall back to unknown (details inline).

Notes:

• Two claims in the PR description do not reproduce on master: git commit -m "feat: 1>0 check" never matched (the truncate pattern requires a space after >), and docker compose down -v --remove-orphans was already HIGH via docker compose down -v (the compiled suffix (?:$|\b.*) accepts trailing content). Worth correcting so the taxonomy history stays accurate.
• The \s anchor drops fd-number redirects (1> file, 2> file) from the truncate pattern. Gating is unchanged (destructive and unknown gate identically), and the 2> /dev/null false positive disappears, so this looks like an acceptable trade; a sentence in the commit message or pattern notes would make it deliberate.