What the checks find stays with the work it belongs to, and every run is recorded in one log. Each has one place:
- A task's findings. They are listed in the task's Quality section in Factory, with what became of each: still open, being fixed, fixed or accepted.
- Test failures no task owns. A scheduled browser test that broke, for example, waits in Factory under Review. Fix it to turn it into a task, or accept it with a reason.
- Checks that cannot run. When a project has no unit-test framework, for example, the Unit tests row in Quality Control says so, and its Fix creates a task that sets one up.
- Runs. Every run, with its duration and what it cost, is listed in Settings under Activity.
Patterns across work
A finding on one task is a detail. The same finding across thirty tasks is a pattern, and patterns are where the useful decisions are.
What to look for:
- Findings that repeat. The same issue across many tasks is either genuine debt worth a dedicated piece of work, or a check that does not match your conventions.
- Findings nobody resolves. A category consistently accepted is a check that is not earning its place.
- Concentration. One project producing most findings tells you where to look.
Runs
Activity lists every run in the organization: agents, tasks, quality checks and tests. Filter it by outcome, type, project and period, and open a run for its checks, results and output.
The useful pattern here is failures that repeat at the same stage across unrelated tasks — that is a project configuration problem rather than a code problem, and re-running tasks will not fix it. See Build and test configuration.
Turning patterns into work
A repeated finding can become a task. That is the point of noticing it: "this pattern appears in forty files" is a piece of work, not a permanent condition of the codebase.
Where a condition should be watched continuously rather than checked by hand, an automation can watch for it and open remediation work.
Tuning rather than tolerating
If findings are overwhelming, the checks are miscalibrated rather than your code being uniquely bad.
A check firing on most changes is describing your codebase, not finding problems. Either the rule does not match your conventions or it describes debt you have decided to live with. Both mean the check should change — see Quality policies and gates.