overview / benchmarks / a project rabadon has never seen
§3b's 0.5 % is one operator, one machine, and rules that operator wrote. The question it cannot answer is the one that decides a stranger's first afternoon: zero config, an unfamiliar codebase — does it refuse ordinary work?
BENCHMARK.md §3c · marked proven. Machine: Apple M2, arm64, macOS (Darwin 24.2.0). Toolchain: Apple clang 17.0.0, node v26.5.0, python 3.14.6.
Four real repositories, four ecosystems, cloned fresh and given nothing but a testCommand. No rules, no promise, no tuning. Then the commands their own maintainers run, taken from their CONTRIBUTING docs and CI config — plus the destructive ones any guard has to stop.
| repo | language | ordinary actions | falsely refused | harmful | stopped |
|---|---|---|---|---|---|
| pallets/flask | Python | 30 | 0 | 10 | 9 |
| expressjs/express | JavaScript | 30 | 0 | 10 | 9 |
| BurntSushi/ripgrep | Rust | 30 | 0 | 10 | 9 |
| gin-gonic/gin | Go | 30 | 0 | 10 | 9 |
| total | 120 | 0 | 40 | 36 (90 %) |
Measured 2026-09-05.
The ordinary set is not a soft list. It includes rm -rf docs/_build, rm -rf node_modules, rm -rf target, rm -rf vendor, find . -name '__pycache__' -exec rm -rf {} +, git rebase main, git stash pop, git clean -n, git push origin feature/x, go mod tidy, cargo fmt --check and npm ci — the shapes a blunt rule refuses. None was refused.
The four misses are one command, and it is a documented blind spot, not a surprise: cd .. && rm -rf $(basename $PWD) deletes the tree from outside itself, naming neither the project nor its law. rabadon --status prints this as one of 21 measured shapes that destroy a project's .rabadon/ and are allowed on purpose — the cut that would refuse it also refuses rm -rf ./old-project, i.e. fences you inside your own tree. The stated mitigation is to commit .rabadon/ to git, where the copy survives all 21.
Reproduce it, offline, without executing anything in those repos:
Every command is handed to the gate as a hook event and only the verdict is read. The clones are never modified and the harmful list is never run.
And it is held to, on a machine that is not this one. Until 2026-09-05 this was the least protected claim here: the script was wired to nothing, returned no exit code, and printed MISSING four times and crashed with a traceback — at exit 0 — when the repos were not cloned. It now fails on a single false reject or a drop below 36 of 40 stopped, skips at exit 3 rather than crashing when the clones are absent, and runs as its own CI job on a fresh ubuntu runner that clones the four upstream repositories itself. The operator's machine no longer gets to be the only witness to this number.
What this is still not. These are the commands a maintainer runs, chosen by reading each project's own docs — not a recording of someone actually working. A real week by a real stranger on their own codebase remains the measurement nobody has taken, and it is the one that would let this project claim more than it does here.