docs: enforce_admins is now TRUE — the push guard's notes said the opposite

[wshallwshall]

enforce_admins was enabled on MEFORORG/MessageFoundry main on 2026-07-28 (verified from the protection endpoint, not the write response). A direct push to main is now refused server-side, and gh pr merge --admin no longer works.

push_guard.py's header and its refusal message both stated the opposite:

"enforce_admins is false, so the owner bypasses it. Nothing else would have stopped this."

Accurate when written, exactly backwards now — and it's the claim someone reads while deciding whether the hook still matters.

Why the hook stays

It's defence-in-depth rather than the only guard, and it still earns its place: it fails fast and locally with an explanation instead of after a round-trip, and it covers cla-signatures, which branch protection does not.

The header records why the reasoning inverted

That's the reusable part. It used to argue enforce_admins=true was deliberately deferred: an intermittent harness-monitor failure was blocking consecutive PRs, and removing the admin override while a flake can strand a merge trades an accidental-push risk for a cannot-ship risk.

That failure turned out to be a livelock, not a flake — so the premise dissolved rather than the trade-off being re-argued. The cannot-ship risk is real and now accepted, with the revert command recorded in the note.

Verification

Comments only — no logic touched. 8 tests pass, and the guard still exits 1 on a push to main and 0 on a feature branch.

Worth noting how I checked that: my first attempt piped stdout to Select-String and reported exit 0 for a push it had just REFUSED — the same "an exit code read through a pipe belongs to the pipe" trap already recorded for the leak scanner. Re-measured without the pipe.

🤖 Generated with Claude Code