Fix every open finding in one commit#
On a pull request review, choose Fix all, or comment @proofline fix all on the pull request. Proofline takes up to 10 open findings from the newest review and gathers a validated fix for each one. It combines the fixes that do not overlap and validates the combined patch again in a sandbox. It then writes one commit to the pull request branch or opens a stacked pull request, depending on the repository's fix target. The commit carries a Proofline-Finding trailer for each finding it fixes. You need write access to the repository, and fix generation must be enabled for the organization.
The Combined fix section lists each finding with its result. A finding that was left out shows why, for example because its fix overlaps another included fix or belongs outside the repository. If the combined patch fails validation, or the pull request head moves before the write, Proofline writes nothing.
After you push a fix, the next review re-verifies the earlier findings. When a finding is still present, or Proofline could not verify the fix, it replies once on that finding's GitHub thread and names the commit it checked. The Check title counts the re-verified findings by result, and the finding page shows a Re-verification history.
Run finishing recipes on a pull request#
Finishing recipes propose focused changes to an open pull request. To run one, mention Proofline in a pull request comment with run recipe and the recipe name, such as run recipe unit_tests. The built-in recipes add tests, add doc comments to changed public symbols, or simplify changed code without changing its interface. lint_fixes stays unavailable while the deployment runs no linter packs. Proofline replies with a link to the proposal and its validation results. Running a recipe does not apply the change or merge the pull request, so you review the proposal before you ask for it to be applied.
Administrators can add organization recipes under Organization → Finishing recipes. A recipe has instructions, the files it may change, optional path and language limits, and the checks it must pass: build, tests or analyzers. Proofline refuses a proposed change outside the allowed files. For example, a release_notes recipe can add an entry while it changes only docs/release-notes/*.md. Each revision is kept, and new runs use the newest one.
Read a review in order#
Each pull request review now has a Walkthrough that sorts the changed files into reading groups, with one line per file. Migrations, infrastructure, delivery workflows and authentication come first. Tests, documentation, and generated, vendored and lock files come last. The Check summary shows the same groups, and the Check details list each changed file with its line counts and open findings.
The Changes view now has a resizable file tree that also works from the keyboard. Selecting a file scrolls to its first diff, and source links open the exact reviewed revision. Files that cannot be previewed show an empty state in the diff pane.
A pull request's history page has a Base branch section. It shows whether the pull request merges into its base, which head and base commits Proofline checked, and each conflicting path. Each path names its conflict class and the resolution that class allows. For example, a lockfile is regenerated with its package manager, a migration is never renumbered, and a person chooses how to resolve a semantic conflict. With write access, choose Check now to check again.
Check pull request titles and review without posting#
Under a repository's Checks tab, administrators can add checks that test each reviewed pull request's title against a regular expression. Each check reports as its own GitHub Check, named Proofline check / followed by the check's name. An Advisory check always concludes neutral. A Blocking check fails when the title does not match. To block merges with it, add its Check as a required status check in your GitHub rules, because Proofline does not change them. A check applies from the next reviewed head, so a title edit without a new commit does not run it again.
Turn on Shadow mode under Organization → Reviews → Automation to run reviews without posting anything to GitHub. Results stay in Proofline, and no Check, comment or pull request review appears. Each repository can follow the organization or turn shadow mode on or off. A review that completed in shadow mode stays unpublished after you turn it off, so run a new review to post results.
The same page adds Flag stale doc comments. It reports an unchanged doc comment that still documents a parameter the pull request removed from a public Python, JavaScript, TypeScript, Java or Rust function or method. While the setting is on, a change that removes lines from a Go file leaves code review incomplete, and the Check names the cause.
Review without posting to GitHub.
Research a question and discuss reviews in Discord#
To research a question about a pull request, mention Proofline in a comment, then write research and the question. Research reads the pull request's pinned code and the recorded environment evidence. It does not run code. The pull request's Research section shows what the run examined, what it found and what remains unknown. A research candidate does not change the deployment verdict. A person with write access can publish a candidate as a GitHub review comment after a confirmation. Administrators set credit and time limits for each run under Organization → Reviews → Models.
Administrators can now connect a Discord server under Organization → Connections. On a review, Discuss in Discord starts a thread in the chosen channel. In that thread, run /proofline ask with your question. Answers come from the review's recorded commits and evidence, and they do not change the review, its findings or a merge gate. Questions in the console, Slack and Discord count toward one hourly limit.
Administrators can also let a manual deep review ask the author about missing intent. Proofline asks on the Check or directly through Slack, Discord or a pull request comment, and it continues with recorded assumptions when the wait ends. The feature is experimental: question selection is uncalibrated, so it can ask unnecessary questions or miss useful ones.
Read research and publish a candidate.
Enable experimental clarification questions.
Deprovision people with directory sync#
An organization administrator can now create the OIDC connection under Organization → Admin → Single sign-on. Enter the identity provider's issuer URL, client ID and client secret, and choose the subject claim. A Microsoft Entra ID connection can match on the object ID (oid) instead of sub.
On the same tab, a GitHub organization owner can connect the identity provider's SCIM client. When the identity provider deactivates a person, Proofline revokes their single sign-on link, their single sign-on sessions and their API tokens in that organization. Directory sync removes access only, and GitHub membership still decides who can enter. Proofline matches people on the OIDC subject sent as externalId, never on user name or email. Matching people looks up a subject, and Recent changes lists the latest 50 accepted writes.
Outside collaborators on an imported repository now see its organization in the organization selector, labeled Outside collaborator. They see only the repositories, pull requests, reviews and findings that GitHub lets them read. Organization settings, environments, audit history, billing and token issuance stay closed to them.
Deprovision people with directory sync (SCIM).
Connect AWS from the browser and group environments by account#
AWS setup now starts with the target account ID and installation region. AWS console (recommended) opens CloudFormation with the template parameters filled in. Infrastructure code generates the role for Terraform, SST v3 or Pulumi TypeScript, and AWS CLI gives a script that refuses the wrong account. Proofline derives the role ARN from the account, so you no longer copy it back after installation. The connection page has separate Setup, Settings and Diagnostics tabs.
When discovery finds repositories that deploy to the same AWS account, administrators see Suggested by AWS account on Organization → Environments. A suggestion creates an environment or adds repositories to the environment that already uses the account. Each repository joins as Delivery, which reviews its deployments, or as Code-only, which adds its code as context.
Setup on Home now asks its Installation questions as a conversation. You can select an earlier answer to change it and continue from that point. A changed answer does not undo a saved configuration or a cloud operation. Choose manually keeps the manual setup available.