Why this page exists
A code review is worth whatever its findings are worth, and the honest way to test a finding is to hand it to the person who wrote the code and watch what they do with it. Between late February and late April 2026, our founder published seventeen deep reviews of small open source projects on his personal blog, under the series title Review Bomb, and each review was paired with a pull request to the project it examined. Fifteen of those seventeen maintainers merged at least one of those changes into their own repository.
That is an external grade on the way we read code, awarded by people with no reason to be generous about their own projects. This page collects the record, including the two projects that did not end in a merge.
A note on whose work this is. The series belongs to Wes Shoffner and lives on his personal site rather than on ours, and the projects reviewed belong to their maintainers. None of them are our work, none of them are clients, and none of them are being offered here as a portfolio. What we are claiming is narrower: the method used in those reviews is the method our audits use, and because the maintainers' decisions happened in public on GitHub, anyone can check whether the findings held up.
The method
The series worked to a selection bar that was written down before any project was picked, and it stayed fixed across all seventeen. A candidate had to sit between five and one hundred fifty stars, so that somebody had noticed it but it had not yet broken through. It had to have been pushed within the previous three months, because a review of an abandoned repository helps nobody. It could not be a fork. It had to solve a real problem rather than serve as a tutorial or a code dump. It had to show care in the form of a real README, a consistent commit history, and usually some tests or releases. And it had to be the work of one person or a small team, since a company-backed project is a different kind of story.
The ordering of the work mattered as much as the selection. Every project was read first, then contributed to, and only then written about, which means no review was ever published without its author having already put the finding in front of the maintainer and accepted whatever answer came back. Where a maintainer disagreed, the disagreement went into the article.
Two working rules shaped what the contributions looked like. The first is that in someone else's repository you fix the code to satisfy the lint rather than suppressing the lint, so no contribution in this series carries an #[allow(...)] or an eslint-disable added to quiet a warning it could not otherwise clear. The second is that every contribution was built and manually exercised before the pull request was opened, which is why the pull requests in the table below mostly landed without a maintainer having to explain how to run the project.
The record
Every row below links to the published review on wshoffner.dev, and every outcome is the state of the pull request on GitHub as of August 7, 2026.
| Project | What it is | What the review found | Outcome |
|---|---|---|---|
| ec | Terminal three-way git mergetool (Go) | The conflict pane labels were deliberately stubbed to an empty string because git merge-file --diff3 bakes temp file paths into its labels, while the real branch names were still available upstream of that step | PR #12 merged 2026-02-28 |
| rss-funnel | RSS feed transformation proxy (Rust) | Two open issues: a requested CSS injection filter that nobody had built, and a query parameter parser that could not read structured YAML values | PR #172 merged 2026-02-28. A second PR was closed by the maintainer, who wanted a more concise encoding scheme than raw YAML in URLs |
| iloom-cli | CLI that runs parallel coding agents in isolated git worktrees (TypeScript) | Terminal launching assumed macOS, so the core workflow was broken on Linux, WSL, and headless hosts, which are the natural deployment targets for a tool that orchestrates autonomous agents | PR #796 merged 2026-03-01 |
| tokf | Command output compressor for LLM context (Rust) | An open request for a go test filter that the bundled filter library did not cover | PR #246 merged 2026-03-04 |
| tango | Benchmarking harness crate (Rust) | The pluggable Metric trait had shipped with a single wall clock implementation, leaving per-thread CPU time unbuilt months after the maintainer had said it was unblocked | PR #72 merged 2026-03-05 |
| crit | Local review tool for agent-written diffs (Go and vanilla JS) | Comment templates were on the roadmap, and the first implementation stored them in localStorage, which does not survive crit's habit of launching on a random port each session | PR #28 merged 2026-03-10, after a rework addressing seven design points from the maintainer |
| hud | Async Rust profiler with an eBPF backend | The blocking pool filter had no test coverage despite four releases spent fixing it, and get_cpu_id() in the kernel-side program always returned zero because the helper it needed is re-exported under #[doc(hidden)] and never appears in the generated docs | PRs #4 and #5 merged 2026-03-18 |
| greywall | Container-free sandbox for AI coding agents (Go) | Learned profiles could be listed and shown but not edited, so changing one meant finding the JSON file by hand and validating it by eye | PR #64 merged 2026-03-27 |
| parm | Binary package manager for GitHub Releases (Go) | The install script wrote its PATH entry in bash and zsh syntax only, so fish users finished the install without the bin directory on their PATH | PR #51 merged 2026-03-27 |
| cubic | CLI virtual machine manager built on QEMU and KVM (Rust) | File transfers ran at roughly 2 MB/s because the SFTP library blocks on an acknowledgment for every write and never pipelines, which the reported symptom did not make obvious | PR #311 merged 2026-03-29 |
| Concryptor | Multi-threaded file encryption CLI (Rust) | CONTRIBUTING asked contributors to run clippy and rustfmt, but CI only ran the test suite, and seven lints plus widespread formatting drift had accumulated behind that gap | PR #10 merged 2026-04-02 |
| Nora | Single binary artifact registry for seven package protocols (Rust) | Two registries were missing from the metrics and health code, an existing test asserted the buggy behavior, and the garbage collector decided which blobs were orphans by reading Docker manifests alone | PRs #97, #108 and #109 merged 2026-04-05 and 2026-04-06 |
| blackwall | eBPF firewall with an LLM-driven honeypot (Rust) | The deep packet inspection handler added 15.0 to a suspicion score that the behavioral engine keeps on a 0.0 to 1.0 scale, which put trusted promotion out of reach for any address that tripped a single detection | PR #3 closed 2026-04-07. The maintainer had independently found the same bug during a v2 rewrite and closed the PR to avoid conflicting with the new core, crediting the catch |
| unifly | UniFi controller CLI and TUI (Rust) | NAT policies had no update path, so changing a single field meant deleting the rule and respecifying all of them | PR #10 merged 2026-04-09 |
| xray | Docker and OCI image inspector TUI (Rust) | The README listed unit tests as a planned improvement and the image parser had none | PR #19 merged 2026-04-13 |
| gittop | Git history TUI in the style of htop (Go) | stats.go holds 548 lines of pure data functions, all of them testable without a git repository, and none of them tested | PR #6 open, awaiting review |
| TermBeam | Terminal sharing to a phone browser over a QR code (Node.js) | An outside report had already named two timing-unsafe password comparisons, and a third instance of the same bug class was still sitting in the Bearer header path | PR #204 merged 2026-04-23 |
That comes to eighteen pull requests merged into fifteen repositories, plus one finding confirmed and fixed by its maintainer without a merge, plus one review still waiting on its maintainer.
The two that did not merge
Both exceptions are worth stating plainly, because a record with no losses in it is a record somebody has been editing.
The blackwall pull request was closed rather than merged. The maintainer had been midway through a substantial rewrite when the review landed, had found the same scale mismatch on his own, and closed the pull request so it would not conflict with the new core he was about to ship. He credited the catch publicly, and his v2.0.0 release followed within hours. The finding was correct and the fix reached the users; it simply arrived through his hands rather than ours, which is a perfectly ordinary outcome when you review a project that is being actively rebuilt.
The gittop pull request is open. It adds 22 test cases for the pure data functions behind the tool's statistics tabs, and it has had no review activity yet. We list it as pending rather than counting it either way.
What this evidences
The reason we publish this record is that it answers a question every prospective audit client is entitled to ask, which is whether our findings survive contact with the people who know the system best.
Maintainers are the harshest available reviewers of a claim about their own code, since they know why a function was written the way it was, they know which of your observations is a misreading of a deliberate decision, and they have no obligation to be polite about the difference. Fifteen of them merged anyway, several of them the same day, one of them only after seven rounds of design feedback, and one of them after a lint failure that CI caught and the contributor could not reproduce locally. In none of the seventeen cases did a maintainer come back to say that a reported bug was not a bug.
The findings themselves are the more useful part of the evidence, because they cluster in ways that show up again in commercial audits. Several were gaps that a test suite was actively concealing, as in the registry whose test asserted the wrong label and passed happily for it, or the profiler function that survived four bug-fix releases without ever acquiring a test. Several were latent rather than live, waiting on a condition that had not occurred yet, which is the category that ordinary usage will never surface and only reading finds. And one, TermBeam, was a case of a second reader finding a third instance of a bug that a first reader had already reported twice, which is the plainest argument we can offer for why a second set of eyes on a codebase is not redundant.
None of this involves proprietary tooling or a certification. It is careful reading, done against real code, with the results submitted to somebody in a position to reject them.
Where to check
Every claim on this page is checkable without asking us. The reviews are published at wshoffner.dev, each one linked in the table above, and each pull request number links back to a public GitHub repository where the merge, the closure, or the pending review can be read directly along with the maintainer's own comments.
If you want the same kind of reading applied to your own codebase or your own site, the services page describes what an engagement looks like, and the free scan is a reasonable place to start if the question is about how a site behaves for automated readers rather than about code.