feat(secret-scan): gitleaks CI job + PreToolUse secret-deny hook

[samo-agent]

Summary

• Deliverable 1: .github/workflows/secret-scan.yml — a dedicated gitleaks job that runs on every PR and push to main, fails hard on any secret hit. .gitleaks.toml extends the built-in ruleset with Cloudflare cfut_ tokens; test-fixture paths are allowlisted so fake tokens in the hook test file don't self-trip the scanner.
• Deliverable 2: tools/hooks/secret-deny.py — a Claude Code PreToolUse hook that denies Write/Edit tool calls whose content contains known token prefixes (cfut_ ghp_ glpat- sk- AKIA), PEM private-key headers, or high-entropy (>3.5 bits Shannon entropy) values assigned to *TOKEN/*KEY/*SECRET/*PASSWORD variables. tools/hooks/settings.snippet.json is the manager-review snippet — it is NOT auto-applied to any live settings.
• TDD: RED commit dd65d0f contains 17 failing pipe-tests (hook file absent); GREEN commit f27196a adds all artifacts → 17/17 pass, full suite 1278/1278.

Root-cause (incident reference)

A Cloudflare token leaked into an agent log this session. Both deliverables address two distinct failure modes: CI catches secrets already committed; the hook prevents them ever reaching a git commit step in the first place.

How a planted fake secret would trip the gitleaks job

1. Add a file anywhere in the repo containing e.g. GH_TOKEN=ghp_TestTokenABCDEFGHIJKLMNOPQRSTUVWXYZ12 (36 alphanum after ghp_).
2. The built-in github-pat gitleaks rule fires; the job exits non-zero; the CI check fails with an inline annotation on the offending line.
3. The secret must be removed (or the commit squashed/reverted) before the check can pass.
4. The .gitleaks.toml allowlist entry cfut_fake / ghp_fake / etc. ensures test-fixture strings in test/secret-deny-hook.test.ts are exempted — real tokens (without the fake literal) are still caught.

Pipe-test results (smoke evidence)

Payload	Expected	Result
Write with cfut_realtoken1234567890abc	deny	{"permissionDecision":"deny","reason":"Secret token prefix detected: 'cfut_realt'..."}
Write with -----BEGIN RSA PRIVATE KEY-----	deny	{"permissionDecision":"deny","reason":"PEM private-key block detected..."}
Edit new_string with DB_PASSWORD = "xK9m..." (entropy=4.95)	deny	{"permissionDecision":"deny","reason":"High-entropy value (entropy=4.95 bits, len=31)..."}
Write with clean README prose	allow	{"permissionDecision":"allow"}
Bash tool with token-like string	allow	{"permissionDecision":"allow"}

Client deployment notes

Gitleaks CI job — copy .github/workflows/secret-scan.yml and .gitleaks.toml verbatim into the client repo. The persona's engineer step should include this copy in its first commit on any new client repo it bootstraps. No secrets or env vars required (public repo, personal account; no GITLEAKS_LICENSE needed).

PreToolUse hook — the persona's Claude Code settings file (managed by the samo-agent bootstrap) should merge the hooks.PreToolUse block from tools/hooks/settings.snippet.json, with the path pointing to the deployed copy of secret-deny.py. This applies the deny guard to every Write/Edit call the persona makes, regardless of which client project it is working on.

What is intentionally NOT in this MR

• Branch protection rule changes (flagged for Nik, governance decision).
• Auto-application of the hook to any live ~/.claude/settings.json — manager reviews the snippet and applies manually.

🤖 Generated with Claude Code