Documentation

Checks, runs and findings

Reviewing a verification run, categorising its findings, and deciding on the appropriate action.

A check is a single verification. A run is one execution of the checks in a policy against a change. A finding is something a check reported.

Locate them under Quality β†’ Runs and Quality β†’ Findings.

Viewing a run

A run displays each check, its result, and its output. If a task fails verification, the run reveals the reason.

Read it from top to bottom. The first failing check is usually the root cause β€” subsequent failures are often secondary effects. A build failure followed by twelve test failures represents one underlying issue, not thirteen separate ones.

Findings

Findings originate from reviewer agents, scanners, and advisory gates. Each entry details what was discovered, where, and its severity.

Their lifecycle:

  1. Raised by a check or a reviewer.
  2. Routed β€” fixable findings are sent back to the developer agent for rework; the rest are attached to the pull request.
  3. Resolved β€” fixed, accepted, or suppressed.

Categorising

For each finding, the key question is not "is this accurate?" but "does this affect the next steps?"

  • Fix now β€” covering correctness, security, or any issue that would otherwise fail review.
  • Accept β€” valid but not worth addressing immediately. Record the rationale.
  • Suppress β€” a false positive, or a rule that does not apply to this code.

Suppress findings deliberately and with a clear reason. An unexplained suppression is indistinguishable from hiding an inconvenient truth, and six months later, no one will know the difference.

When there are too many findings

Volume indicates a problem with configuration, not code quality.

If a check triggers on most changes, it is not identifying issues β€” it is reflecting your codebase. Either the rule does not align with your practices, or it describes technical debt you have chosen to retain. In either case, the check is poorly configured.

Findings and gates

A finding from an advisory gate provides information. The same finding from a blocking gate halts the task. The finding remains the same; the policy determines the outcome.

This is the adjustment to make when a check is correct but overly strict: change its severity instead of removing it. See Quality policies and gates.