Break Points

Overview

A findings list is complete but not ordered in a way that makes "where do I start" obvious from scanning it. Break Points solves that specific problem: it's the same underlying findings, narrowed to the ten most consequential and ranked by how much they actually matter to production — not by how the analyzer happened to generate them.

It exists because severity alone is a poor guide to where to start. A missing retry is a missing retry whether it sits on a read-only lookup or a step that charges a card — same severity, very different consequence. Break Points ranks by Production Impact Tier instead, which accounts for what a finding is actually connected to.

What question it answers

"If I can only fix ten things today, which ten, and in what order?" Not every problem the analyzer found — that's the full findings list — but a shortlist, already ranked, of where the workflow is most likely to actually break in production.

How to read it

Each Break Point carries:

• rank — position 1 through 10, or fewer if the workflow has fewer than 10 qualifying findings. Rank 1 is the highest tier, then highest confidence, of everything in the workflow.
• nodeIds / nodeNames — which node, or chain of nodes, the risk sits on. A risk tied to a path rather than a single step can list more than one node.
• riskType — the category of failure mode, distinct from the finding's scoring category.
• consequence — the likely real-world outcome if this pattern fires in production, in plain language.
• fix — the concrete recommendation, and for expression-related findings, an expressionFixes block showing the broken expression and its corrected form.
• productionImpactTier and confidence — the two numbers the rank is actually sorted by.

One detail worth knowing: findings whose fix is identical regardless of which node triggered them — a missing timeout, a missing token cap, a missing audit log, and a handful of other rule types that recur the same way everywhere — are consolidated into a single Break Point listing every affected node, rather than appearing once per node. This keeps the top 10 from being dominated by ten copies of the same fix on ten different nodes. The tradeoff is that a single rank can undersell how widespread an issue is, so check the nodeNames array, not just the rank position, to see the true blast radius.

Example: rank 1 might be a single agent node with write-capable tools and no iteration limit — critical tier, high confidence — outranking a finding that's technically critical severity in isolation but sits on a read-only, low-traffic path and so carries a lower production impact tier.

How to decide what to do

Work the list in order, but don't stop at 10 without checking coverage.

1. Start at rank 1 and work down. The ranking already did the prioritization; re-sorting by intuition usually just re-derives what the tier system already accounted for.
2. Check nodeNames on a consolidated Break Point before marking it done — fixing it on one node doesn't clear the others listed alongside it.
3. If every fix in the top 10 looks feasible in one session, do them before moving to the rest of the findings list. Break Points are, by construction, the ten highest-leverage items.
4. A workflow with fewer than 10 findings still gets a complete list — a shorter list isn't anything being hidden, it's that there weren't more findings to rank.
5. Break Points is a subset, not the whole report. If all 10 are cleared and the Executive Summary still shows elevated risk, go back to the full findings list — something outside the top 10 may still need attention.

Related reading

• Overview — how Production Impact Tier differs from severity and how it's calculated
• Executive Summary — primaryBottleneck is always Break Point #1
• Reliability — the category with the largest rule set and the most high/critical-tier findings, so it tends to dominate this list