The scorecard

Every item from “What the research says to build next.” Estimated effort vs. actual delivery.

Eight shipped in v2.0. The ninth — PR comment integration — required a new module and landed in v2.5. Every estimate was in the right ballpark. The research did its job.

What we shipped beyond the list

The nine items were the research-backed minimum. What actually shipped across ten versions:

The research told us what to build. Production told us what else we needed.

The calibration arc

The first blog post documented a P1 precision of 0%. The verification gate brought it to 70%. But the real story is the calibration shift across the eval baseline — from v13 (early pipeline) to v20 (current).

P0+P1 collapsed from 62% to 30%. Not because the pipeline finds fewer bugs — because it stopped over-promoting. P2 became the center of gravity. The two remaining P1s are real, both with code-path evidence.

The alarm fatigue research was right. Every false P1 that reaches a developer is a withdrawal from a finite trust account. The verification gate, the 0.8 precision threshold, the severity-weighted convergence — they exist to protect that account.

The adversarial audit

Tree-sitter scope detection (v2.9) was the last major feature. Before shipping, it went through five rounds of adversarial multi-LLM code review. Eight independent models. Each round: generate intake document, feed to web LLMs that have never seen the code, synthesize findings, fix, repeat.

The pipeline reviewing its own code. Mode 3 behavior validating Mode 3 enforcement. The bugs were real — Rust generic type extraction, C++ qualified identifiers, Python decorator handling, TSX grammar mapping. None were found by the original author or the original review session.

What we killed

Four proposals, each researched and unanimously rejected. Saying no is a feature.

Every killed proposal was plausible. Some were requested. All would have made the system worse. The hardest engineering decisions are the ones where you already have working code and someone asks you to add more.

The numbers

Nearly 1:1 ratio of test code to source code. Every design invariant has structural enforcement, not just documentation. The eval harness runs against golden fixtures created from production triage data.

What's left

One item: Sentence-BERT for the dedup module. It's parked. The lead model handles dedup better than the dedup module ever did — zero catches across four production runs, while the lead correctly identified all 75 duplicates during triage. The module stays wired in as cheap insurance. If it ever fires, something interesting happened.

The roadmap is empty because the pipeline is feature-complete. Not because we ran out of ideas — because we killed the ones that didn't earn their complexity.

Theory, then execution

The theory post asked what the literature says about what we already built. This post answers: we built what the literature recommended. Every item. Then kept going until production stopped asking for more.

The thesis — Mode 3 behavior enforced structurally, not instructionally — is implemented, tested, and validated by the same adversarial multi-model process it was designed to enable. Ten design invariants, each preventing a validated failure mode. Forty-eight research sessions confirming the architecture was sound before we wrote a line of v2.0.

Persist the state, not the conversation.