Manage the Autofix backlog and pauses

Why Guard watches the backlog

Recurring Autofix is useful only when people review its outputs. Open issues and pull or merge requests can otherwise accumulate, duplicate decisions, and make the next safe candidate harder to identify. Guard monitors the repository’s improvement backlog and warns or pauses before automation creates more clutter.

Warning thresholds

The warning state begins when the repository reaches any of these conditions:

• 5 open pull or merge requests;
• 10 open issues;
• an oldest open item that has waited 14 days.

The banner shows the live counts, the oldest-item date when available, and how close the repository is to an automatic pause. Open the provider links and decide which artifacts should be reviewed, closed, superseded, or kept.

Automatic pause thresholds

Autofix pauses when any threshold reaches 10 open pull or merge requests, 20 open issues, or 30 days for the oldest open item. The pause records the date and backlog snapshot that caused it. Existing issues and review requests remain on GitHub or GitLab; Guard does not close or merge them automatically.

A separate repository-inactivity pause can turn off scheduled audit reruns and Autofixes for a quiet repository while leaving manual audits available. New commits can be detected while automation remains paused until someone explicitly resumes it.

Work through the queue

Start with the oldest and highest-risk artifacts. For each item, compare it with the current default branch, read the linked audit evidence, review verification, and choose to merge, request changes, close, or supersede it. Closing obsolete work is part of keeping the queue trustworthy.

Do not re-enable automation merely to clear the banner. The provider queue should first represent work the team still intends to review.

Re-enable safely

After reducing or resolving the backlog, use Re-enable Autofix on the paused job. For an inactivity pause, use Resume automation on the repository. Then verify the intended schedules and write modes because a pause can cover more than one recurring action.

The next run revalidates current repository and provider state. It should not assume that the candidate selected before the pause still applies.