Ship a tested privacy-guard pre-commit hook (installer + negative-test checklist line)

[PBNZ]

Problem

The standard (Author identity) explains why personal-name guard patterns must stay out of the tree — but leaves the actual guard for each repo to hand-roll. Hand-rolled guards fail silently. Real case from a scaffolding session: a pre-commit hook filtered diff noise with grep -v '^\+\+\+' (no -E); in GNU BRE, \+ is a quantifier, so the filter matched every added line and -v discarded them all — the guard passed everything, including a staged test leak. Only a deliberate negative test caught it.

Suggestion

1. Ship scripts/install-privacy-guard.ps1 (Core tier): prompts for the patterns locally, writes an untracked .git/hooks/pre-commit that scans staged additions and staged filenames, and enforces the noreply commit identity. Patterns never touch the tree; the installer script itself is clean and trackable.
2. Have the installer finish with an automatic negative test: stage a synthetic leak, assert the hook blocks it, clean up.
3. Add one line to pre-commit-checklist.md / the hook guidance: "a guard that has never failed a negative test is not yet a guard."
4. Note in the docs that the hook does not travel with clones and must be re-installed per machine.

🤖 Generated with Claude Code

[PBNZ]

Landed in #38 (squash-merged, CI green): Core ships scripts/install-privacy-guard.ps1 — untracked hook, case-insensitive literal patterns, staged-content + staged-filename + identity scanning, core.hooksPath refusal, and a mandatory negative test on every install that removes the hook on failure. Documented in the standard's Author identity and the pre-commit checklist; decided in ADR-0012; smoke-tested end-to-end in CI.