performance-regression-estimatorlisted

## What It Does Reads a proposed implementation outline and the changed files, scans for known performance hazards (N+1 queries, sync-in-async, missing pagination, suspicious caching, sequential network calls, hot-path logging), and classifies each by severity and hot-path placement. The point is to catch latency and cost regressions during planning, not after a load test or a customer-facing slowdown. ## Use This When Use this in the graduated and full lanes whenever the change touches data access, request handlers, scheduled jobs, or anything with a stated latency or throughput requirement. Skip when the change is purely structural (renames, moves) and exercises no new code paths. ## Inputs - Read the proposed solution at `proposed_solution_path` first. - Read the changed-file list to scope hazards to code that is actually changing. - Read canonical module docs in `module_doc_paths` for declared latency budgets and throughput targets — a hazard on a hot path with a sub-100ms budget is much more severe than the same hazard on a daily batch job. - Read `references/perf-hazards.md` before classifying any hazard so the catalog and severity rubric stay consistent. ## Procedure 1. Enumerate code paths the change introduces/modifies (handlers, jobs, consumers, libs); mark each as hot-path or not based on canonical module docs. 2. Run `scripts/scan-perf-smells.sh <changed-files...>` to surface candidate hazards (N+1, await-in-loop, async-map without Promise.all, deep-clone-