Archive. These are our earlier blind code reads, from September and October 2026. Trenyx now runs planted-bug tests: how that works.
Where the bug catalogue comes from.
Each read is written up in full: the plan written and hashed before a line of the target was read, what held, what broke, and what the maintainer did about it. Two kinds of entry: a blind read, where the code is read at one pinned commit against a plan hashed first, and a matrix run, where catalogue defects are planted into a clean checkout and the project's own suite is run against each. The label on each entry says which. These are the load-bearing proof behind the method. If you want the method itself, start with how to verify AI-generated code.
Why this matters for the monthly run. The bugs we plant in your code are chosen from what these reads found going wrong in real AI-written software. Start with the method: Your tests pass. That's the problem.
toolhive: an OAuth client secret landed in the state file in clear, fixed in 0.50.0
A pre-registered blind read of a Go runtime that puts one authentication, authorization and egress layer in front of MCP servers. Four of eight claims held with the mechanism cited: one middleware chain on every transport, an authorizer on tool calls rather than listings, a secrets provider that refuses to start without the OS keyring, fail-closed egress. One could not be settled from the code. One did not hold: two OAuth callbacks re-saved the run configuration after the client secret had been resolved to plaintext in place, so it landed in the local state file in clear. Reported privately as a GitHub advisory; fixed in 0.50.0; the maintainers published GHSA-pm52-m6xg-c3g9 with the reporter credited five days after the report.
verify-009 · blind read · team workspace / Rust · maintainer-fixedmacro: channel access lingered thirty seconds after removal. Cut to ten the next day.
A pre-registered blind read of a team workspace that puts chat, mail, documents, calls, a CRM and AI agents behind one permission model. Six of eight claims held with the mechanism cited, one is documented behaviour, one could not be settled from the code, and one security finding, reported privately, was narrowed by the team the next day and shipped to production two days after the report.
verify-008 · blind read · bulletin board system / PHP · maintainer-fixed · advisory publishedbinkterm-php: a message could drive the reader's terminal, fixed in an evening
A pre-registered blind read of a multi-protocol BBS around a FidoNet mailer. Seven of eight claims held: one authorization path behind every door, DB-keyed file lookups, a row-locked credits ledger, 315 admin routes gated. One did not: a message body carrying raw terminal escape sequences reached any Telnet or SSH reader's terminal untouched, while the project's own PacketBBS renderer already stripped them. Reported privately as a GitHub advisory; the maintainer had a fix committed forty-two minutes after the report, shipped 1.10.5 that evening, and published the advisory with credit two days later.
verify-007 · static read, pre-protocol · restaurant ordering / TypeScript · maintainer-fixed (duplicate)kitchenasty: any customer could read any booking, and someone else found it first
A static read of a self-hosted restaurant ordering and reservation system, 65 of its last 100 commits agent-authored. One route let any signed-in customer read any booking with the customer's name, email and phone. Reported privately; it was a duplicate of a report filed six weeks earlier, and the fix shipped in 0.3.1 the evening our email arrived. The three correctness gaps were new: the maintainer confirmed all three and opened them as issues. Not pre-registered, and the entry says so.
verify-006 · blind read · building fault detection / Rust + SQL + Python · maintainer-fixedopen-fdd: two rule flavors, two answers, fixed in a day
A pre-registered blind read of a fault-detection platform that publishes its 62 rules in two "parity-matched" flavors. Two of the pairs answered the same rule id differently, in a tolerance and an occupancy threshold, both outside the project's own parity harness. Reported publicly at 18:47; the maintainer replied at 18:52, shipped the fix that evening in 3.3.41, and added both rules to the harness.
verify-005 · matrix run · data pipelines / Python · maintainer-confirmedanalitiq-engine: 3,632 green tests, six gaps, all six reproduced
A pre-registered blind pass on a "never lose data" sync engine, blind-to-published in a day. The suite caught 14 of 20 planted defects; the six escapes were test gaps, two of them silent re-breaks of bugs the project had already fixed. The maintainers reproduced all six with control mutations and corrected two of our severities upward. The fix existed; the fence didn't.
verify-004 · matrix run · booking / reservations · maintainer-fixedpayload-reserve: a default install let any customer take over any account
Pre-registered blind pass on a Payload booking plugin. Its suite caught 11 of 13 planted defects, but the default standalone install left collection access wide open: any logged-in customer could read, change and delete every other customer's booking, and set another customer's password to log in as them. Reported privately; the maintainer fixed all three findings in v4.1.1 the same cycle, then audited himself and shipped 4.1.2, and closed a second batch in 4.1.3, one of them by configuration with the residual documented. The withheld exploit now ships as the regression test, green against the fix.
verify-003 · matrix run · payments / double-entry · EXEMPLARYledgerly: the strongest test suite we've measured
A pre-registered blind pass on a Stripe→journal engine. 810/810 green, and a planted-defect matrix caught 14 of 16 injected money-bugs, including every balanced-but-wrong account mutation. The two escapes were one benign test gap, disclosed publicly and gratefully. Shipped code correct.
verify-002 · matrix run · agent authorization / Go · maintainer-confirmedkontext: a fail-open outage path in an AI-agent security guard
Hash-anchored blind pass on a Go policy guard. 7 of 11 planted defects caught: a suite that tests its core; the method found seams, not holes. The maintainers reproduced the reported raw-input matching gap (kontext#477), which is Trenyx's first maintainer confirmation.
verify-001 · matrix run · algorithmic trading / Python · 8 confirmed defectstrading-bot: 1,921 tests green, eight defects in the money path
Pre-registered pass on an AI-built Python trading system. Its green suite caught only 5 of 11 planted money-bugs (lookahead, a mis-anchored trailing stop, an ignored kill switch), and eight real defects were confirmed and disclosed (issue #99).
Each read was reported to the maintainer privately first and published after they fixed it or cleared it. The pace is set by disclosure, not by the calendar.
The honesty is mechanical, not a promise.
Before reading any implementation, we write the attack plan from the public README alone, hash it (SHA-256), and post the hash to a public timestamp. That external clock is the thing you verify: it proves the plan was fixed while we were still blind, so the findings can't have been reverse-engineered from whatever we happened to find. Every read here was run that way except one, and its page says so. Nothing about the result rests on taking our word for the order of events.