Understand improvement outcomes

Read the outcome before the artifacts

An improvement run can complete successfully without opening a pull request. The outcome explains what Guard established about the current candidate, write policy, duplicate state, and verification. Provider links are supporting artifacts; their absence is not automatically a failed run.

Issue-only

Guard creates or reuses an issue when the configured mode does not permit repository edits or when owner judgment is the safest next step. The issue should explain the source evidence, current revalidation, affected scope, impact, proposed direction, verification plan, and known limitations. It remains a manual work item until someone resolves or closes it.

Issue-only is expected for broad, risky, ambiguous, or policy-sensitive changes. It preserves a durable decision thread without pretending that autonomous code would be safe.

Issue plus review request

A pull request or merge request means Guard found one current, duplicate-free, bounded candidate, made a focused change on a branch, and recorded credible verification. It does not mean the change is approved or that repository health already improved. Read the linked issue, diff, checks, limitations, and any repository-owner guidance before merging.

Guard leaves the review request open. A person and the provider’s normal protections decide whether it lands.

Existing or already resolved work

If an open issue or review request already covers the same root cause, Guard reuses or links it instead of creating clutter. If the default branch already resolves the evidence, the run can report already resolved or no actionable fix. A merged request from earlier work can also explain why no new artifact appears.

These outcomes are useful evidence that the queue was revalidated rather than replayed blindly.

Blocked, needs review, or verification failed

Needs human review means current state, safety, verification, or a product decision is ambiguous. Verification failed means the proposed change could not be shown safe against the usable baseline, so it was not pushed as an autonomous review request. Report only or an invalid-input outcome means provider writes were not authorized or the required source context could not be trusted.

Read limitations for the exact cause. Do not turn on broader write behavior just to force a green-looking outcome.

No candidate or no action

The source finding may be stale, too risky, outside the runbook’s current scope, or not reproducible. Some catalog entries are also published as guided or planned workflows that currently produce diagnostic/report output rather than code changes. Their page states that maturity explicitly.

When evidence is stale, rerun the audit. When ownership or design is the blocker, resolve the issue with the responsible person. When the improvement was merged, close the loop with a fresh audit of the resulting commit.