How Repro proves a bug before it fixes it
Reproduce first, verify after, and a person merges. A walk through the six stages of the Repro pipeline.
This post is a draft for the team to review. It isn't final yet.
Repro is built on one rule: a warning has to be proven before anything gets fixed. It reproduces every scanner warning in a sandbox, fixes only what it proves, and leaves the final call to a person.
Here is the whole pipeline, one stage at a time.
Ingest → Detect → Reproduce → Diagnose → Repair → Verify → a person merges1. Ingest
Repro clones the target into a fresh workspace, pinned to one commit.
2. Detect
Deterministic scanners produce the findings. No model decides what counts as a finding.
3. Reproduce
This is the proof step. For each finding, Repro re-runs its reproduction command in a sandbox and keeps only what shows the problem. A warning that can’t be reproduced doesn’t move on to be fixed.
4. Diagnose
The findings that survived are grouped by root cause, and Repro proposes a fix per group rather than per finding.
5. Repair
Repro edits files through sandboxed tools. The diff comes from git, so what you review is exactly what changed on disk.
6. Verify
The tests run and the reproduction runs again. On top of that, an adversarial check tries to break the fix. Then a person decides whether to merge.
The shape of it
Read top to bottom, the pipeline has two halves:
- Prove the problem: Ingest, Detect and Reproduce. By the end of Reproduce, every remaining finding has been shown to be real in a sandbox.
- Prove the fix: Diagnose, Repair and Verify. By the end of Verify, the fix has passed the tests and the re-run reproduction, survived an adversarial check, and is waiting for a person.
Repro never merges its own work. That’s the point of “proof, not promises”: it hands over evidence, and a person makes the decision.
More on Repro: the case study, the code on GitHub, and the Devpost page.