review-gatelisted

# Review Gate **This is exloom's one enforced mechanism — the rest of exloom is guidance.** When the gate is turned on, a `PreToolUse` hook run by the Claude Code harness — not by the model — *physically blocks* a `git push` or PR (shell **and** GitHub MCP) until the tier's evidence is in `.claude/reviews/<branch>.md`. That is the difference between *hoping* review happened and *knowing* it did, and it is the part of exloom you cannot reproduce by prompting. **One gate, at push.** Earlier versions also blocked completion claims with a `Stop` hook, froze the working tree during review, and gated the first source edit on an approved plan. All of that is gone. The `Stop` hook matched natural-language phrases, which drifts with every model release; the freeze and plan gates interrupted work far more often than they caught anything. Blocking the push is the one point where stopping is worth more than it costs. Enforcement is text-based command/tool matching plus the checklist's git checks: it catches the common `git push` / `gh pr create` forms and the listed GitHub MCP tools. A deliberately obfuscated shell command or a raw API call can still evade it, and a benign command that literally contains the words `git push` can occasionally be over-blocked (bypass with `EXLOOM_REVIEW_SKIP=1`, or rephrase). It is a cooperating-team gate, not an adversarial security boundary. ## Why this exists Consider a large, multi-batch refactor that passed every review it was given — per-batch c