overview / benchmarks / the ledger
rabadon usage --days 30 aggregates the local spool (~/.rabadon/spool/). It excludes its own drills, demos and self-tests at emit — 3,495 events in this window — so a tool that counts its own test runs as catches never happens here. Measured 2026-07-31, over the 30 days before it: 59 projects, one machine, real work. Those days have aged out of the ledger, so the tables in this section can no longer be re-derived; rabadon usage --days 30 today prints the 30 days before today.
BENCHMARK.md §3 · 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.
| view | actions gated | caught before happening | would have caught (watch) | checks failed | loops stopped |
|---|---|---|---|---|---|
| all projects (30 days) | 15,188 | 61 | 68 | 314 | 2 |
Biggest signal, by project:
| project | actions gated | caught before happening | checks failed | loops stopped |
|---|---|---|---|---|
| (withheld) | 4,196 | 43 | 107 | 2 |
| rabadon | 3,640 | 12 | 112 | 0 |
| (home) | 2,162 | 3 | 27 | 0 |
What was caught on (withheld) (verbatim rule ids from the ledger): push-gate 14x (code edited after the last passing test run), no-rm-rf-outside-project 9x, no-wrangler-deploy 6x, generated-web-html 5x, ctest-tail-hides-verdict 3x, loop-stop 2x, test-tamper 2x (assertions being removed from test_style.cpp while the suite was red), golden-reference 1x, no-force-push-main 1x.
This page used to carry one number called repairs accepted, and it was 0, and that was reported as honesty. It was worse than a wrong number: it was one bucket holding four different events, because REPAIR_OK is emitted by the push gate when a suite goes green, by the gate when a new rule is written, and by the repair path whether or not any test file was hash-locked while the fix was re-checked. Counting those together means the headline can grow without a single line of code ever being repaired.
Split by what actually happened:
| bucket | 30 days |
|---|---|
| repairs held — fix re-checked with test files hash-locked | 2 |
| repairs unverified — nothing was locked, so nothing witnessed it | 3 |
| push gates passed — a suite ran green, nothing was repaired | 0 |
| rules written — law was authored, nothing was repaired | 1 |
The three that used to read as "repairs accepted" are all unverified, all on (withheld). The number that sells the product — a fix proven against test files that provably did not move — reads 2, both on expressjs/express, and both on planned breakage. On unplanned breakage the count is 0, and this page will keep printing it either way. That second number is the one to watch; the first only proves the loop runs end to end.
Command: RABADON_NOTIFY=0 rabadon usage --days 30.
Note: the bench harness writes to an ISOLATED spool (RABADON_DIR per run), so bench drills do not inflate this ledger. The stable facts this page rests on: node/native parity held while the Node gate existed, (withheld) was the largest real signal on 2026-07-31, and repairs-held is 2 on planned breakage and 0 on unplanned breakage.
push-gate · test-tamper · loop-stop