Dev, main, and prod all point at the same Redis and the same Postgres on Ballpark Genius. That’s not a design decision I’m proud of, it’s a decision made by “there’s only one of me and eleven of these projects.” It works fine right up until an agent decides redis-cli FLUSHALL is a reasonable way to test a cache bug in a worktree that isn’t prod.

So I wrote a PreToolUse hook. It sits in front of every Bash call and denies anything that looks destructive against those two: redis-cli DEL/FLUSHALL/SET/HSET/EXPIRE/RENAME, and psql DROP/DELETE/TRUNCATE/UPDATE/anything with ALTER ... DROP|RENAME. Read-only and additive operations pass right through. It’s not a “no touching the database” hook, it’s a “no overwriting production by accident” hook (there’s a difference, and the difference is the whole point).

Measure twice, cut once, except an agent that’s very confident about a redis-cli one-liner doesn’t measure at all, it just cuts, and it pairs with a hook that already blocked killing or restarting the dev servers, and a step in this project’s architecture-check skill that makes me, or an agent reading the skill, state a blast-radius verdict before writing code that touches shared infra. Three separate nets for the same failure mode. I’ve watched it slip through at least once each way, and none of those times was actually the AI’s fault, for what it’s worth, it was mine, for building the shared Redis in the first place.

The honest reason I built this w/ a hook instead of a note in CLAUDE.md: instructions are advisory, hooks are not. I’d rather over-trust a shell script than a language model’s reading comprehension when the blast radius is “the database everyone’s using.” Cheers, Redis, you’ve earned a good night’s sleep.