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.
A task's findings are in its Quality section, and every run is under Settings → Activity.
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. A finding on a task stays with that task. A test failure that no task owns waits in Factory under Review, where you fix it or accept it with a reason. A check that cannot run in a project, such as unit tests without a test framework, says so on its row in Quality Control.
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.
Raised
- An advisory gate
The reviewer agent- A connected scanner
Routed
Fixable
Back to the developer as rework
Everything else
Attached to the pull request
Resolved
Fixed
The change addresses it
Accepted
True, not worth acting on here. Say why.
Suppressed
A false positive or rule that does not apply. Say why.
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.