Four deterministic, offline tools, one job each: audit the persistence hooks hiding in a repo, pin the GitHub Actions that can be retargeted after review, scan the text an agent is about to read for injected instructions, and keep the receipts (history, diffs, and blame) when something changes. This board tracks their findings on our own factory in near real time, publishes the proof benchmarks, and keeps the program's problem ledger honest in public.
| Repo | Head | actionpin | Pinned | hookcheck | Risky / inventoried | Checked |
|---|
hookcheck REVIEW across the factory is the calibrated state: every repo's publish path downloads one binary over HTTPS (the mcp-publisher tool), which hookcheck correctly inventories as one RISKY finding held below the top verdict. The exposure is recorded as accepted risk in the program's morning report.
Solid, by the program's own bar, requires a validation round with zero BLOCKER and zero unexplained REAL problems on the final binaries. When no round has cleared that bar, this board says NOT SOLID, in those words. The current round and verdict stand in the program state section above, parsed from the committed program record.
The full ledger is a committed file in this repo, ledger/problems.md: the public ledger of record, updated by the validation process as problems close. The counters above are parsed from that file by the pipeline on every run; they are never typed into this page or its data files by hand. Round verdict tables recorded inside the ledger:
Every tool is a static, offline analyzer with a fixed rule set. Same input, same verdict: the validation program runs each target three times and hashes the output. No model is consulted at scan time, so a result can be re-run and argued with.
Findings are checked against source by a human-grade read before they enter the ledger: 2,785 actionpin findings verified line by line (100 percent accurate), 1,265 hookcheck findings presence-verified, every COMPROMISED verdict of the mega-corpus hand-read (30 of 30 were false alarms at the time, and the calibration fixes they forced are in the ledger).
The wave's standing rule: if a tool still has problems, it gets updates until it is solid, and only then does marketing get its numbers. Every number on this page traces to a data file generated from a named source: the npm registry, the GitHub API, the validation ledger, or the scheduled scan itself.
Nothing on this page is hand-exported. Every 15 minutes the pipeline re-reads npm, re-scans the watchlist, re-parses the committed ledger and program records in this repo, and re-runs a tool's full test suite from its release tag whenever the tool's version changes. Each section carries its own stamp: last scan for the feed and grid, the ledger file's last commit time for the counters, the tested version and time on each tool card, the pack date on proofs. The one human step left in the whole system: the validation process commits ledger and proof-pack updates as its work closes; everything downstream is automatic. The full loop is documented in SELF-UPDATE.md in this repo.