Improvements: how Guard turns audit evidence into reviewable autofixes

What improvements are

Guard uses improvements when an audit or product signal points to a concrete next step. The goal is not to clear a backlog in one pass. It is to move one part of the repository toward the green zone with enough evidence for a reviewer to trust the work.

Each run starts from Guard's product context: repository access, current audit results when they exist, the selected improvement, the output mode, and the limits attached to that runbook.

Available autofixes

This menu is deliberately smaller than the runbook repository. It lists published improvements that are available in Guard today, while draft rows stay out of the public landing surface.

Evidence boundary

An improvement run may read current repository files, task input, previous Guard context, and GitHub issue or pull-request history. That evidence shapes what the run can attempt, but current repository state still wins.

How the loop works

1. 1

   Start from a known surface

   Guard resolves the selected improvement, repository target, runbook, and any paired audit surface.

2. 2

   Re-check the current state

   The run validates repository access and current files before trusting earlier evidence.

3. 3

   Select one bounded candidate

   The run picks a small piece of work that can be explained and reviewed.

4. 4

   Produce reviewable output

   Guard records a report and may open a GitHub issue or pull request depending on the runbook and selected mode.

5. 5

   Rerun audits later

   The next audit verifies the new repository revision and decides whether health actually improved.

Outputs and review

Improvements produce ordinary review artifacts. A GitHub issue fits when the next step needs product, security, or architecture judgment. A pull request fits when the change is small and the verification path is clear. A report-only result still matters when the run discovers that access, consent, or evidence is not enough for a safe change.

Issue

A decision artifact that records evidence, context, and a proposed next step.

Pull request

A bounded code or test change that a human reviews and merges.

Report

The durable record of what Guard inspected, what it attempted, and where it stopped.

Availability rule

The runbooks repository can contain ideas, draft actions, and future catalog rows. The landing menu follows the product surface: only published, usable actions appear here.

Maintained health

The improvement loop keeps audit findings from turning into a static backlog. Guard finds risk, proposes the smallest useful change, records the review trail, and reruns audits against the updated repository. The maintained outcome is the green zone, not a higher count of opened pull requests.