Operations aggregates findings and runs across the organization, rather than per task. Find it under Operations, with Findings and Runs views.
Why an aggregate view
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.
Per-task views answer "is this change good?". The operations view answers "what is systematically true about our codebase and our configuration?".
Findings
Every finding raised across projects, filterable by severity, project and type.
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 or suppressed is a check that is not earning its place.
- Concentration. One project producing most findings tells you where to look.
Runs
Every verification run, with its checks and results.
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, Sentinel can watch for it and open remediation work.
Tuning rather than tolerating
If the operations view is 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.