A review often leaves work to do when a failed test needs an explanation, a team requirement needs checking, or a proposed fix needs another look. This week we shipped changes that keep that work connected to the commit and finding that started it.
Put your team's requirements into checks#
Pre-merge checks now cover pull request descriptions, issue references, required labels, and changed-line test coverage. You can scope a check to paths, apply it across an organization, or keep it in a repository's .proofline.yaml.
You can also write a condition in plain language: “A change to a public API handler updates api/openapi.yaml.” Proofline reads that instruction beside the pull request's title, description, and changed files. The resulting GitHub Check includes the answer, its explanation, and the files it cites.
File-defined checks come from the pull request's merge base. Removing a check in the proposed change does not exempt that change from the existing requirement. Each check can be advisory or blocking; GitHub's required status checks decide whether a blocking result prevents a merge.
An instruction that requires an external document or issue tracker stays undecided for now. The verifier cannot read those sources for these checks yet.
Configure pull request checks.
Read the failed job beside the change#
With CI failure diagnosis enabled, Proofline inspects failed GitHub Actions jobs on a reviewed pull request head. Run details shows the diagnosed jobs and retained, masked log excerpts. The review's GitHub Check lists the failures too.
Proofline compares a failed job with the same job in the latest completed workflow run at the merge base. If the same step already failed there, the review identifies it as pre-existing. It can also identify recorded runner failures, such as a full disk or a lost runner. Other causes remain unattributed when the evidence does not establish them.
You can now ask questions from the review's Changes page and open cited files there. The reviewed diff, findings, and discussion stay together as you investigate.
See what happened when an agent tried to fix it#
The finding page now includes Agent fix loop. It lists each re-verification request from a coding agent, the commit or local changes it named, Proofline's result, and the agent's note.
When the agent disputes a finding or asks for human review, its note appears at the top of the page. The note does not resolve the finding. Verification still has to establish that the correction addresses it.
That history lets you inspect an unsuccessful attempt, understand a disagreement, or continue the work from the last checked commit. Earlier evidence remains available after later reviews finish.
Review security findings across repositories#
The new Security report groups findings by OWASP Top 10 category or CWE Top 25 rank, with JSON and CSV exports. It reports the reviews and commits analyzed alongside the findings, and identifies repositories without a finished analyzer run.
For infrastructure findings with a recorded live comparison, the finding page now shows that comparison beside the cited infrastructure-as-code result. You can inspect what the change declares against the resource observed in its environment.
Start from your repository#
Code review can now start before environment setup is complete. Connect a repository, inspect its code findings, and add cloud evidence when you connect the environment it deploys to. Code findings remain labeled separately from findings supported by environment evidence.
Setup also works through Claude Code or Codex using Proofline's MCP tools. Editor integrations gained current-file reviews for saved changes, and cancelling an admitted editor review now stops the review work.
The ChatGPT plugin is on its way#
We're preparing the Proofline ChatGPT plugin so you can work with Proofline from a conversation. This week's work includes the authorization and setup flows, plus findings returned with their reviewed commits and links back to Proofline.
We'll share installation details when the plugin is available.