what-are-the-bottleneckslisted

# What Are the Bottlenecks? Find the limiting constraint, not the longest list of defects. Move from system goal to critical flow to evidence, then descend only into details capable of changing the diagnosis. ## Core rules - Treat a bottleneck as a constraint on a stated goal under a stated scenario and horizon. Never call something a bottleneck in the abstract. - Separate observed facts, user claims, inferences, assumptions, and unknowns. - Distinguish `current constraint`, `emerging constraint`, `risk`, `symptom`, and `unknown`. Not every flaw limits throughput or outcomes. - Prefer repository evidence, measurements, traces, user behavior, budgets, queues, failure history, and dependency limits over generic best-practice checklists. - Audit the measurement system before trusting it. Contradictory, missing, sampled, or ambiguously labeled observations can make diagnostic capability the immediate constraint. - Inspect broadly before drilling down. Do not begin with code quality when demand, distribution, compliance, data, ownership, or unit economics may be the real constraint. - Rank bottlenecks relative to each other. A top-ten list with ten critical items is not a diagnosis. - Recommend the cheapest decisive test before an expensive redesign. - Do not optimize a non-constraint. Explain which downstream constraint is likely to appear if the current one is relieved. - Preserve read-only scope unless the user asks for changes. Do not run load tests, paid calls, destructive