Open actions from an audit score

Start with one score

Each numbered square represents the latest score for one audit group in one repository. In the example above, Dependency hygiene is selected for workspace-client with a score of 58.

The action trigger belongs to that exact square. Opening it keeps the repository and audit context attached to the next step.

Read the score in context

The metric card can show the current score and status, recent score history, the direction and size of a change, completed-run count, and the latest run date. Start by confirming the repository and audit. Then open Audit details and verify the checked commit, the main answer, findings, and limitations.

The shared zones are green at 70–100, yellow at 40–69, and red below 40. They summarize urgency; they do not explain the formula. Criteria, deductions, caps, and unscored evidence vary by audit. A score of 58 in dependency hygiene and a score of 58 in AI readiness can represent very different evidence and next work.

Use history to distinguish a persistent problem from a one-run change. Compare the revisions as well as the numbers: an old result does not automatically describe code that landed afterward.

Choose the next action

• Audit details opens the evidence and report for the selected metric.
• Re-run now requests a new assessment when the repository and audit are eligible.
• Auto-reruns opens recurring audit controls for this metric.
• Autofix opens a bounded improvement flow when Guard has a supported path from the result.

The popover is a shortcut into those workflows. It does not replace the audit evidence or human review of a proposed change.

When rerun is unavailable

Guard may disable a rerun while the same work is active, when no eligible newer revision exists, when repository access is unhealthy, or when the run is outside current account and scheduling constraints. Do not work around the control by starting unrelated jobs. Confirm the latest commit, connection state, active runs, and schedule first.

If the repository has not changed, preserving the existing result is usually more useful than creating duplicate evidence. See Audit will not rerun for a focused diagnostic path.

After an improvement

An issue or pull request is a delivery artifact, not proof that the repository is healthier. Review and merge the change through the normal provider workflow, then rerun the affected audit against the resulting commit. The new evidence—not the existence of the pull request—establishes whether the project moved toward the green zone.