Bugs.

Perfloop looks for supported inputs or sequences that produce the wrong result, state or effect. It proves a fix against a stated assertion about what the code must do.

What it looks for

Examples include leaked resources, lost wakeups, deadlocks and data races. It also looks for wrong numeric results, confused value kinds, ignored failures and ranges that do not match the data they describe. The expected behavior must come from the project's contract, such as its documentation, tests or supported interface. A surprising implementation is not by itself a bug.

How it proves a change

A Case states the assertion, its scope and its assumptions. Repair proof must show the assertion failing on the original code and passing after the change, under the same conditions. A test can supply that proof; some questions need controlled failures, concurrent histories or model checking. The repository's checks must also pass, and an independent verifier checks whether the proof answers the Case's question.

What you receive

A pull request carries the change and its proof, including the regression test when one is required. A result better reported as an issue can be proposed as an issue instead. Your repo's publication controls and contribution rules still apply. The Case records an unproven or disproved hypothesis too. Perfloop cannot approve, merge or deploy.

Limits

Proof covers the stated assertion and the conditions it checked. A passing test does not establish that the whole program is bug-free, or that every concurrent schedule is safe. Existing checks guard against regressions but do not replace proof of the repair. Available work follows your plan, repository settings, Usage and Case limits.

Use the MCP server to submit a finding or branch. Read the loop reference for Case evidence and results.

Also in this section: Quickstart, Performance, Security, The loop, Case states, Pull requests, Steering and learning, Initiatives, Autonomy and limits, Members, and The MCP server.