OSSQ

Through 2025 and 2026 maintainers were buried in AI-generated contributions and answered with policy. curl ended its bug bounty after fabricated reports; QEMU, NetBSD, Gentoo and Zig banned AI contributions outright; modelcontextprotocol/python-sdk's CONTRIBUTING now says it in as many words — 'If your agent is auto-filing PRs against our open issues, stop.' So an agent that opens pull requests is the exact pattern being banned, and building one would be building the problem. The question worth answering is the one immediately before it: across the handful of repositories you actually know something about, which of several hundred open issues are worth a human's afternoon, and what are that repo's rules before you touch it?

OSSQ reads, ranks, and stops. It walks a twelve-repo watchlist, drops everything that is a pull request, already assigned, contested by an open PR or carrying a label the repo's own policy says is off-limits, scores what survives against eight signals, and writes CANDIDATES.md with the arithmetic shown for every entry. A human reads that file and decides. The boundary is enforced in a module rather than a promise: nothing in the codebase may call fetch or spawn `gh` except through src/guard.ts, which forces the method, restricts the host, counts every call so a test can assert a code path touched the network zero times, and refuses `gh api` with field flags unless `-X GET` is explicit. Each repo's rules are typed, validated data — lane, PR policy, claiming-comment rule, disclosure requirement, auto-close triggers, source URL and the date a human last read it — and the published playbook is generated from that file so the docs cannot promise something the scanner is not doing.

The brief asked for an agent that would land one or two open-source contributions a month, starting with modelcontextprotocol/inspector, and the first sprint killed that plan by reading the CONTRIBUTING files it named. inspector accepts issues, not pull requests: design and implementation are done by the maintainers, and the rule applies even to org members with write access — if you have already built a fix locally, they want the prompt you used, not the diff. vercel/ai says the most helpful contribution is often a high-quality issue and credits the issue author with co-authorship on the eventual fix. PrefectHQ/fastmcp heads a section 'The best contribution is a great issue' and names claiming comments as the most common noise it receives. Four of the twelve policies came back materially stricter than the brief assumed.

That reframed the whole project. The thing being built was not a contributor; it was the step before one — a triage engine whose output is a file a person reads. And once the deliverable is a file, the most important property is that it stays a file. Through 2025 and 2026 maintainers were being buried in automated contributions and responded with outright bans, so an agent with write access to GitHub is the exact shape of the problem. The write path was therefore closed in code before the scanner was written: one module every request routes through, methods forced, hosts restricted, `gh` on a read-only allowlist that knows `gh api -f` is secretly a POST.

Everything after that was the difference between what the documentation says and what the API does. GitHub's issues endpoint returns pull requests as issues — 1,430 of 2,287 items in a full run — so the first implementation's one-page-per-repo fetch produced three usable candidates from vercel/ai; paginating toward a target of real issues took the run from 332 to 604. Freshness had been computed from when the queue first saw an issue, which made a five-month-old bug read as surfaced this week. The documented zero-auth atom fallback is dead, 406 on every repo tested. Then the scorer was pointed at itself and two of its eight signals turned out to award almost everybody the same points, including the heaviest one in the system, because its keyword list contained the words 'tool', 'prompt' and 'resource' inside a set of MCP repositories.

It ends where it was always going to end. The engine picked modelcontextprotocol/typescript-sdk#2619, that project's CONTRIBUTING exempts straightforward bug fixes with tests from the issue-first step, the bug was reproduced from source and fixed with tests written failing first, and their client suite went from 785 to 794 passing with no regressions. The patch sits in a gitignored drafts folder. Submitting it is a person's job, and the guard makes it not a choice.

A single pass, one direction. `ossq scan` loads watchlist.json through a typed schema that validates each repo's policy and checks how old its verified-on date is, then paginates each repo's issues toward a target of non-PR items, dropping anything assigned, contested by a confirmed open PR, or labelled in a way that repo's own policy says gets a contribution auto-closed. What survives is normalised into one candidate shape, scored by eight signals, then capped — ten total, three slots reserved for the issue lane, no more than two per repo — and written out as CANDIDATES.md plus a run artifact and a one-line ledger entry.

Every network call leaves through src/guard.ts, which asserts the method and host, counts the call, and forces GET regardless of what the caller passed. Behind it sits a governor that paces core requests, backs off, and reserves the last hundred units of budget, and an on-disk ETag cache where a corrupt entry is treated as a miss rather than an error. Core REST is the primary path with the search API as a narrow supplement that degrades instead of throwing, an inversion that came out of measurement: search tripped a secondary limit after about three calls while core sat at 4,997 of 5,000.

The two side surfaces read the stored queue and nothing else. `ossq queue` renders it in the terminal; segment/ccline.mjs renders it as a ccline statusline segment that reads one local file, never touches the network in its render path, and is asserted fail-soft in CI — garbage on stdin must exit 0 with an empty stderr. PLAYBOOK.md is generated from the same watchlist the scanner filters on, and CI regenerates it and fails on any diff.

The audit started with the target repositories rather than with the code, and the first thing it broke was the brief's own locked decision. modelcontextprotocol/inspector — named as the entry repo, with merged pull requests as the goal — accepts no pull requests from anyone outside the maintainer team, explicitly including org members who happen to have write access. Two more of the five named targets say outright that a high-quality issue beats a patch. Reading twelve live CONTRIBUTING files also turned up one that spells its label `good-first-issue` with hyphens, so the obvious query for `good first issue` silently finds nothing there. The second half of the audit was pointing the finished scanner at live GitHub, where three confident assumptions died in one run: the REST issues endpoint hands back pull requests as issues, freshness was being computed from when the queue first saw an issue rather than when it was opened, and the documented zero-auth `issues.atom` fallback returns HTTP 406 on every repo tested while `releases.atom` on the same repos still returns 200. The unit tests passed the whole time, because they parse a synthetic fixture.

Freshness now measures from `createdAt` alone; computing it from `max(firstSeenAt, createdAt)` had made the first run describe a five-month-old issue as surfaced within the last week. One page per repo produced three candidates from vercel/ai, so pagination now walks toward a target count of non-PR issues — that change alone took a full run from 332 to 604 candidates. The first live queue was seven candidates from a single repo, because most signals are repo-level and ties broke alphabetically, so a cap of two per repo went in. The rate-limit measurement was reading a 304 replay of its own earlier response, comparing the budget against a cached copy of itself. PLAYBOOK.md generation was stamping staleness marks into the file it generated, which made the drift test calendar-sensitive instead of drift-sensitive. `RepoScan.error` was declared and never populated, so a repo whose fetch failed reported zero kept — indistinguishable from a repo with nothing worth keeping. The last defect surfaced on the first public push: CI asserts the ccline statusline segment is fail-soft, and it failed immediately, because a static import of a peer dependency that exists only as a local symlink is an uncatchable resolution failure that exits 1 with a stack trace. The segment had only ever been fail-soft on the one machine where its dependency was installed.

Every figure in the project came from an instrument rather than an estimate, and the instrument kept disagreeing with the documentation. GitHub's issues endpoint returned 1,430 pull requests among 2,287 fetched items — 63% of the output is noise. A cold scan of the twelve-repo watchlist costs 76 core requests and takes 58 seconds; the identical scan repeated six minutes later cost nothing, because every response came back 304 Not Modified, which is what makes a weekly re-scan effectively free. `search/issues` tripped a secondary rate limit after roughly three calls spaced four seconds apart while core REST sat at 4,997 of 5,000 — that measurement inverted the architecture to core-first. GitHub's own `/rate_limit` endpoint turned out to be a lagging view: it reported 4,810 remaining and did not move across a dozen real requests while the `x-ratelimit-*` headers on those same responses decremented correctly, so budget is read from headers. Then the scorer was measured against its own pool and two of its eight signals turned out to be constants wearing a weight: 'few comments' awarded full marks to 81% of candidates, and the MCP keyword list contained 'tool', 'prompt' and 'resource' — words in nearly every issue in an MCP repo — so the heaviest signal in the system fired almost universally. Regrading the first took it to 48%; replacing the second with wire-protocol vocabulary (`tools/call`, `_meta`, `streamable http`, `jsonrpc`) changed what leads the queue from 'Log exceptions in tool calls' to actual protocol bugs. Neither dead signal is visible from the top ten, where everything scores high by construction, which is why the measurement script runs over the whole pool.