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.
Find them under Quality → Runs and Quality → Findings.
Reading a run
A run shows each check, its result, and its output. When a task fails verification, the run is where you find out why.
Read it top down. The first failing check is usually the real one — later failures are often consequences. A build failure followed by twelve test failures is one problem, not thirteen.
Findings
Findings come from reviewer agents, scanners and advisory gates. Each carries what was found, where, and how serious it is.
Their lifecycle:
- Raised by a check or a reviewer.
- Routed — fixable findings go back to the developer agent as rework; the rest attach to the pull request.
- Resolved — fixed, accepted, or suppressed.
Triaging
The question for each finding is not "is this true?" but "does this change what happens next?"
- Fix now — correctness, security, anything that would fail review anyway.
- Accept — true but not worth acting on here. Record why.
- Suppress — a false positive, or a rule that does not apply to this code.
Suppress deliberately and with a reason. An unexplained suppression is indistinguishable from someone silencing an inconvenient truth, and six months later nobody can tell which it was.
When there are too many findings
Volume is a signal about configuration, not about code quality.
A check firing on most changes is not finding problems — it is describing your codebase. Either the rule does not match your conventions, or it describes debt you have decided to live with. Both mean the check is the wrong shape.
Findings and gates
A finding from an advisory gate is information. The same finding from a blocking gate stops the task. The finding is identical; the policy decides what it costs.
That is the lever to reach for when a check is right but too aggressive: change its severity rather than removing it. See Quality policies and gates.