Round 2's fresh full-pool sample on Gin moved TrueMend's wrong-match rate to 40.4% — four times our own bar. Round 3 root-caused it (an engine bug plus three detector fixes plus five quarantines) back down to 5.9%. golangci-lint's 21.4% is still the round-1 number, not re-measured since, so this remains not an apples-to-apples comparison.
Our bar is <10% wrong-match. Round 1 on Gin didn't clear it either: 11.9% against golangci-lint's 21.4%, on a 59-finding judged sample — a beat on the competitor, but already above our own standard. Round 2 pulled a fresh, from-scratch full-pool sample from the same corpus and TrueMend's number moved to 40.4% — roughly four times the bar. This is what happened and why we're publishing it anyway.
What actually held
Two of three detector fixes already landed via b688fd1b were checked
against fresh instances in this corpus, not assumed. Both hold. The
third's status was not re-confirmed this round. None of the three
regressed.
What didn't happen this round
Zero new Go-specific fixes landed in this fleet sweep. The 11.9% → 40.4%
move isn't new breakage from new work — it's a much larger, unfiltered
sample exposing a category that was never touched: go_no_t_parallel /
go_no_subtests. That single category produced 1,719 raw findings — 56%
of this corpus's entire pool.
The detector is factually correct: Gin's own test suite really doesn't
call t.Parallel() or use table-driven subtests in the flagged locations.
But on Gin's suite as currently written, this is near-certainly not
worth fixing — it's a style/throughput recommendation, not a defect, and
firing it at this volume against a codebase that has never used the
pattern is a worth-fixing-axis judgment call, not a correctness bug. We
left it unfixed and untouched this round. That decision, not a new bug,
is what drove the aggregate number.
Result
TrueMend: 40.4% wrong-match, 13.5% real-rate (156 judged, fresh full-pool sample). golangci-lint: 21.4% — the round-1 number, not re-measured this round. Comparing 40.4% to a stale 21.4% isn't apples-to-apples, and we're not presenting it that way. TrueMend's 40.4% is well above our own <10% bar — round 1's 11.9% already was, too.
| Stage | Judged | TrueMend wrong-match | golangci-lint wrong-match |
|---|---|---|---|
| Round 1 (prior evidence) | 59 | 11.9% | 21.4% (head-to-head) |
| Round 2 (2026-07-28, fresh full-pool) | 156 | 40.4% | 21.4% (not re-measured) |
Round 3 — fixed, not just disclosed
The decision above didn't get made by demoting go_no_t_parallel/
go_no_subtests — it got made by finding out the 40.4% wasn't really about
that one category. Root-causing the round's worst clusters turned up an
engine bug: the per-function line-scan path was indexing each match's
position against the wrong baseline, so any detector's negative-context
check on that path silently matched nothing and suppressed nothing —
correct rules that had never actually run correctly. Fixed that, plus
three detector fixes and five quarantines of whole-construct properties
(named-return signatures, operand types) no line-scan can see. Raw
findings on this corpus: 3049 → 2184 (−865 false positives).
Round 3: TrueMend 5.9% wrong-match — under our own 10% bar. Full detail (the engine bug, the fixes, the quarantines) is in our Gin vs. Semgrep case study, which covers the same corpus and rounds from a different competitor angle.
Still open
golangci-lint has not been re-run against this fresh full-pool sample — the 21.4% in the comparison above is still the round-1 number. A fair apples-to-apples read of where Go stands against golangci-lint requires re-measuring the competitor on the same footing TrueMend was just re-measured on, not just improving TrueMend's own side.