Fusion's review can inspect an existing pull request, publish findings, and prepare bounded repair commits. What it cannot do is silently cross into merge, release, or deployment authority. The repository owner keeps the final mutation decision, and that boundary is deliberate: auto-fix should mean "repair, rerun, and present evidence," not "merge without review."
Existing work enters through review intake
A pull request already has a subject, author, branch, and change history. Fusion freezes the subject SHA and a review projection of the shared RunSpec protocol. It does not pretend the PR began as a Fusion build.
The review contract captures scope, required scanners, baseline behavior, compatibility expectations, and publication policy.
Findings need stable locations
The review engine can combine deterministic scanners with rostered model analysis. A finding should identify the file, line, severity, evidence, and suggested route. General commentary without a navigable location is harder to act on and harder to verify after repair.
Repairs remain optional and bounded
When policy allows, Fusion can prepare a repair commit for an actionable finding. The repair is tested against the frozen subject and evaluated under the same evidence spine. A fixable defect routes through an implementation patch, the protected objective gate, review, and fresh QA. The loop is bounded so an agent cannot mutate the contract until something passes.
Publishing a repair commit is not merging it. The repository owner can inspect, revise, or reject the patch.
The current repair path is narrower than the target
The standalone review baseline can execute repair only through an operator-supplied or explicitly trusted command. Model-authored repair and a rostered review tournament remain product work, not a capability to imply in current copy.
Review closes through publication, not ship
Build and review share contract and evidence structures, then diverge after proof completion. Build can become ready to ship. Review can publish or localize findings and close.
That boundary matters for GitHub App permissions. The least-privileged useful review tool does not need to own the merge button. Good automation delivers a defensible recommendation and leaves consequential repository authority with the human who owns the code.
Human authority stays explicit
The final maintainer reviews the diff, evidence, scope, and Receipt before merge. A clean repair result makes that decision better informed. It does not make the decision disappear.
Source ledger
- PR workflow, opening decisions and sections 3–4.
- Fusion MVP PRD, FR-22d.
- Fusion run lifecycle, Review tail and pillar scope.