Review an Autofix safely

Confirm the run you are reviewing

Start with the target, not the proposed change. Confirm the repository, default branch, audited commit, completion date, and Autofix action. If the PR is based on another revision, stop and reconcile the mismatch before reviewing code.

Read the Autofix outcome

The headline and narrative are the quickest summary, but they are not approval evidence. Check that the selected candidate still matches the source audit finding and that the result says whether Guard opened a PR, reused existing work, created only an issue, or stopped for human review.

Follow the report, issue, and PR

Each artifact answers a different question:

• The report records the run outcome, verification, limitations, and next action.
• The issue preserves the problem, impact, evidence, and durable review thread.
• The pull request contains the proposed code change when a bounded fix was safe.

An issue-only result is valid. Guard should not manufacture a pull request when the change is broad, ambiguous, duplicate, stale, or cannot be verified credibly.

Review the actual diff

Open the provider review request and compare every changed file with the issue and audit evidence. Confirm that the patch is narrow, reversible, and free of unrelated cleanup. Check base and head branches, dependency or lockfile movement, configuration effects, and any behavior outside the selected candidate.

Verify, decide, and rerun

Read the exact verification result and its limitations. A passing targeted check is useful evidence, but it does not replace the repository's required test, security, deployment, or approval gates.

1. Run any additional checks required by the repository.
2. Approve, request changes, or close the PR through the repository provider.
3. Merge only after a qualified human accepts the change and its remaining risk.
4. Rerun the affected audit on the merged revision.

An open issue or pull request does not change the audit score. The score can move only after the fix is merged and a new audit confirms the resulting state.

Monitor Autofix resolution

The activity line answers how much Autofix work was created. It does not say whether that work helped. Read it together with the outcome rings: a merged PR is an accepted code change, a PR closed without merge is a rejected or superseded proposal, and an open PR is still waiting for a decision.

The issue ring uses the provider's resolution reason:

• Completed means the user marked the Autofix issue as done.
• Not planned records an explicit decision not to apply it.
• Closed (no reason) is closed work without a structured reason.
• Still open remains in the human review backlog.

Volume and resolution are different signals. A busy Autofix line can coexist with a growing review backlog; use the outcome rings to confirm that people are actually merging, closing, or completing the work.

Understand automatic pause

Guard warns when any one of these conditions is reached: 5 open PRs, 10 open issues, or a 14-day-old item. If the backlog reaches 10 open PRs, 20 open issues, or a 30-day-old item, Guard pauses Autofix automatically so it does not keep adding unattended artifacts.

The pause does not close or merge existing work. Review or close the old items first. Autofix does not resume by itself when the counts fall: a user must choose Re-enable autofix, after which Guard starts the improvement loop again from a clean backlog state.