Autofix and human review

Start from validated evidence

Supported improvements begin from current audit context. Guard selects a bounded candidate instead of attempting a broad cleanup.

Immediate autofix can begin from a selected finding. Scheduled improvements work incrementally and may address one critical problem in a run.

Audit context establishes audit-time scope and ordering. It is not permission to write and it may no longer match the default branch. The improvement run revalidates the candidate, repository identity, current commit, provider state, and duplicate work before choosing an action.

Choose the write boundary

• Issue only creates or reuses one durable provider issue and does not edit repository files.
• Issue plus PR/MR creates or reuses the issue first, then may open one review request when the change is current, bounded, reversible, and verifiable.

Enabling the second path does not force a patch. Product decisions, broad redesigns, migrations, major upgrades, public contract changes, and other high-blast-radius work remain issue-only or needs-human-review outcomes.

Understand possible outcomes

An improvement run can finish with:

• an issue that explains the problem and recommended action;
• an issue plus a verified pull request or merge request;
• no code change because verification failed;
• a blocked or not-applicable result;
• no new artifact because an equivalent provider artifact already exists.

Issue-only is a valid safety outcome. An opened review request is not proof that project health improved.

Review the proposed change

1. Read the source audit evidence.
2. Confirm the issue describes the same root cause.
3. Review the exact files changed.
4. Check the recorded verification evidence and limitations.
5. Confirm the branch is current enough to review and repository checks still pass.
6. Ask a qualified human to approve or reject the change.
7. Merge through the repository provider when it is safe.

Guard never pushes directly to the default branch or performs the final merge automatically.

Handle a failed proposal

Do not merge around failed verification. Read whether the failure belongs to the change, an unavailable environment, or a pre-existing baseline. Close or supersede a proposal that no longer applies, and preserve a useful issue when human work is still needed. If the source evidence has changed substantially, rerun the audit instead of trying to repair an obsolete patch.

Verify the health change

Rerun the affected audit after merge. The new report, not the existence of a pull request or merge request, shows whether the finding is resolved.

See the provider and write matrix for a concise view of external side effects.