Start with a clear contract

What are we repairing?

In Try a repair, each task is a curated Python project snapshot with a maintenance request, its starting files, examples, and explicit requirements. The examples show the required behavior. The source viewer shows the exact code the repair starts from.

Requirements cover both the requested fix and behavior that must keep working, such as ordering, error handling, or leaving the caller's data unchanged. File labels show which source files the model may change.

This public app accepts the listed task IDs. It does not accept repository URLs, code uploads, or shell commands.

A real request, a bounded attempt

What happens when I generate a patch?

First, the coordinator checks the run allowance and executes checks on the starting code. It then sends the maintenance request, allowed source, public examples, and requirements to the model. The model returns proposed file changes and a short summary.

The coordinator applies those changes only to the allowed files and runs the checks again. Progress comes from recorded events: starting checks, repairing, checking, and preparing evidence. The model's explanation is shown separately from what the checks actually observed.

Checks the repair cannot rewrite

Who decides whether the change passed?

The check definitions and expected results are controlled by the application, outside the model's editable source. Each check calls the code with a specified input and compares the observed outcome with the requirement. Additional checks can exercise compatibility cases beyond the task's public examples.

Here, “independent” means the proposed code does not control its check definitions or the recorded verdict. It does not mean a second model votes on the patch. The check runner records outputs, exceptions, logs, and operation IDs.

When an attempt fails, feedback can guide another attempt within the same run limits. PatchProof retains the best checked attempt and preserves the others for review. A failed or interrupted run remains in the history.

Know what the result means

A passing check is evidence with a scope.

All listed checks passed

The selected patch passed the declared checks. A human still reviews whether the change should be used.

Checks failed

The run did not produce an accepted patch. Open the failed checks to see the expected and observed results.

Needs review

The evidence is incomplete or the run stopped. Do not treat the retained patch as verified.

Execution error

A problem in execution prevented a normal decision. Review the recorded activity and partial results.

Passing a finite set of checks does not establish correctness for every possible input. There is no automatic merge or deployment of the generated patch.

Review the work, not just a badge

What can I inspect in a run?

Download evidence saves the original inputs, candidate changes, check results, logs, and accounting in one bundle. With the recorded source checkout and runtime, a maintainer can run the replay command shown in Run details. Replay executes fresh checks without asking the model to generate the patch again.

The walkthrough and video explain saved real runs. Browsing them does not start a new model call; Generate patch starts a new run.

Compare approaches fairly

Why are there three repair approaches?

The comparison view checks whether the runs used the same source, policy, runtime, and resource limits. It shows total usage across attempts, including unsuccessful work. Provider cost estimates are labeled; unknown billing and CPU values stay unmeasured.

These curated demonstrations explain the workflow. A few successful examples do not establish a benchmark advantage over another approach.