Reproduce · Fix · Prove
Open an issue. Get a pull request that fixes the bug and proves the fix.
First it makes your bug happen — on your code, in a locked box with no way out to the internet. Then it writes the fix. Then it runs the tests on the code before and after, and shows you what they printed. If it cannot reproduce your bug, it opens nothing — you get a question back, not a patch to review.
Install on GitHubGrants access to the repositories you pick, and nothing else.
You hand over
acme/checkout#41
“Totals are wrong when a coupon is applied.”
It runs
sealed container
Your code, your tests, no network. Destroyed afterwards.
You get back
pull request + proof
The fix, and the commands that show it works.
It proves three things, in this order
The bug is real.
It reproduces the failure on your code before it writes a line of the fix. No reproduction, no pull request.
The fix works.
It writes a test that fails because of the bug, then shows that same test passing once the fix is in.
Nothing else broke.
It runs your own test suite on the code before the fix and the code after, and shows you both results.
What lands in your pull request
Five sections, always all five, always in this order. Written from what the run actually did.
- The bugYour report, quoted, so the claim being tested is on the page.
- The failing testThe command that reproduces it — registered before the fix agent existed, so it cannot have been written to suit the fix.
- Base red, fix greenA table of commits, exit codes and the symptom found in the output. Each line is a file you can open.
- The diffEvery file touched, and the full patch.
- The tier reachedHow far the evidence actually goes — including what was not measured.
A description that drops the tier when the tier is awkward is a description you have to check by hand, which is the job this is supposed to do for you.
Every point is an exit code, not an opinion
A run is scored out of 103. Points come from commands this engine ran and kept the output of. Here is a real one.
+40 the reported symptom was reproduced on the base commit
+30 a failing test the agent wrote, passing after the fix
+20 your own suite ran green on both commits
+0 the agent said it was confident
90/103 evidence, not testimony
Note the fourth line. The agent’s own confidence is worth nothing. It is stored and shown to you anyway, because you may want to read it — but no verdict here rests on anything the model said about itself.
How a run goes
You pick an issue and press Start
You choose which repositories to connect, and which bug to work on. You are never asked for a personal access token.
It reproduces the bug — or it stops
On your code, in a container with no network at all, not even DNS. If it cannot make your bug happen, it stops here and asks you what it is missing. It does not guess at a fix for a bug it never saw.
It writes the fix, then checks it twice
Once, that the reproduction now passes — the reported bug is gone. Again, that your own test suite still passes on the code before and after — nothing else went with it.
You watch, then you decide
Every command, exit code and file streams to you as it happens, and is kept afterwards. It opens the pull request. You merge it, or you do not.
Four things it will not do
It will not fix what it cannot reproduce
No reproduction means no pull request — not a smaller one, not a hedged one. A bug nobody can make happen is a question, and you get the question back.
It will not call one green test a fix
A passing test proves that test passes. Your whole suite, on the code before and the code after, is what shows the fix did not cost you something else.
It will not take the model’s word for anything
What the agent says about its own work is kept and shown to you, and counts towards no verdict. Only exit codes and stored output do.
It will not merge
It opens the pull request and stops. Every decision after that is yours, and the evidence is sitting there to make it with.
Where your code runs, and what it can reach
On repositories you pick, one at a time, in a container that is destroyed when the run ends. Installing grants access to those repositories and nothing else.
Your credentials are never in there with the agent. The container holds no model key and no GitHub token. The loop runs outside it and passes tool calls in, so the sandbox needs no way out to the network and is given none.
Every container is probed from the inside to prove the seal held, and the run says so in its own log rather than asking you to assume it.
The four words this page leans on
- Base commit
- Your code exactly as it is today, before anything is changed. The bug has to happen here first, or the run stops.
- Sealed container
- A throwaway machine holding your code and nothing else — no internet, no DNS, no keys. It is destroyed when the run ends.
- Exit code
- The number a command leaves behind when it finishes. Zero means it passed. It is a fact, and it is what the score is built from.
- Tier
- How far the proof actually got — reproduced, fixed, suite green. Stated plainly in the pull request, including when it is low.
Point it at one bug and read the evidence.
If it cannot prove the fix, you will know, because it will say so in the pull request — or open nothing at all.