Hook a Permission Layer onto Dangerous Tools

PROJECT CONTEXT:
My agent can execute shell commands and edit any file, and one bad completion could rm the wrong directory. Harness analyses show the answer is a hook layer: programmable interception before dangerous calls, with deterministic rules the model cannot negotiate with.

GOAL:
Build a pre-execution hook layer: deterministic danger rules, approval escalation, protected paths, and hook-based extensibility.

REQUIREMENTS:
- A pre-tool-use hook point in the dispatch path where rules run before execution
- Deterministic danger rules: destructive command patterns, protected paths, secret files
- Three verdicts: allow, require-approval, block - each with a reason
- Protected-path enforcement for writes (env files, credentials, system paths, .git internals)
- Hook configurability so projects can add rules without forking the harness

CONSTRAINTS:
- Rules are code/config, never prompt text - the model can request, not overrule
- Blocks return structured refusals that keep the loop alive

DEFINITION OF DONE:
- rm -rf variants, force-push, and bulk-delete patterns require approval or block
- Writes to .env, key files, and outside-workspace paths are blocked with reasons
- A blocked call produces an honest model-visible refusal and the task adapts
- A project-level hook config adds a custom rule without harness code changes

COMMON FAILURES TO AVOID:
- Safety rules living in the system prompt where clever phrasing routes around them
- Pattern rules so naive that rm -rf ./ passes because the pattern expected rm -rf /
- Hooks that crash the loop instead of returning verdicts
- No project extensibility, so real deployments disable the layer entirely