Contribution gating and trust ledgers

Require a prior issue, cap concurrent contributions per author, auto-close unresponsive threads. These work precisely because they filter on behaviour a drive-by or a bot will not supply: issue-first kills roughly 90% of drive-by pull requests because prompt-and-forget contributors never come back, and a per-contributor concurrency cap kills the ten-agent swarm at the gate. Stale-bot auto-closing is automation fighting automation.

Incoming work is classified rather than labelled: is this well-specified enough to dispatch now, does it need a specification first, or does it need a human decision? Two nominally identical feature requests can route differently — one dispatched to a coding agent, the other returned as a short product document because it overlapped in-flight work. The classification step is kept deliberately non-autonomous where prompt injection is the risk: somebody is going to inject something.

Reputation ledgers where existing members vouch newcomers in and sloppy contributors are denounced out — enforced by CI rather than by convention — with quality reported up sharply and volume retained. On the hiring side the same impulse: a tracked record of what someone built and whether they can defend it, replacing the credential. Oral defences after every project; the repository as the new resume.

Also: Ghostty’s checked-in vouch ledger enforced in CI; Gemini CLI; and the reported incident of 60M tokens and roughly $30k of inference consumed on a $30 plan.

Assay’s trust gate is a roster of trusted identities consulted before acting on any issue, pull request or comment, with unblessed content quarantined: surfaced, never executed. Judgment-based routing is the intake role’s core function — every inbound item exits as a brief, a bug, a finding, a human-decision issue, or rejected — and that classification is deliberately not autonomous, which is the injection argument arrived at independently. The human-decision label, with its rule that only a human may close it, is the “needs a human decision” lane made structural. See desk roles for where this sits in the pipeline.

The roster is binary where the vouch ledger is two-sided: there is no denounce list, so a bad actor is re-evaluated fresh on each encounter rather than carrying a recorded history. The roster is local configuration rather than a checked-in, reviewable artifact, so it federates across repositories by convention rather than by mechanism — a single checked-in ledger consumed by several repositories is the upgrade this evidence points at. And the routing verdict is held in the desk’s head: recording each triage decision as a structured label plus a one-line rationale on the issue would give both an audit trail and, after a couple of weeks, the dataset needed to judge whether the lane decision could ever be delegated. All three are designed and unbuilt.

The assessment checklist on the hiring side — verify, cite, defend, name where the machine erred — is Assay’s evidence-row culture restated as teaching. That suggests the verification discipline generalizes to how humans should be trained to supervise agents, rather than being only a repository convention.

• Whether the platform-native per-contributor pull-request cap ships, and what maintainers report after it does — that is the first platform-level admission that the front door is the control point.
• Whether any project other than Ghostty runs a two-sided vouch/denounce ledger, and whether denounce is ever actually exercised.
• Whether “prompts are the new PRs” gets a real implementation: a project that accepts intent and context as the contribution and generates the diff itself.