Audit Performance

Find work that grows without a useful bound or repeats without progress. Produce an evidence-backed ledger or report, then prefer the smallest fix that preserves recovery.

Workflow

1. Trace hot paths. Find recurring syncs, polls, streams, retries, queues, scheduled jobs, filesystem walks, and request-time reads. Follow each through its production caller; ignore test-only paths.
2. Compute the amplification. State the trigger and worst-case work in concrete units: rows, queries, pages, entries, bytes, jobs, retries, or full-file rewrites. Distinguish a bounded large constant from work that grows with history, tenants, paths, or outage duration.
3. Check forward progress. For every retry, fixed-prefix batch, cutoff, or transitional poll, identify what changes before the next attempt. If nothing must change, it can loop or starve forever. Check that partial fixes do not merely delay the same work.
4. Falsify severity. Inspect existing caps, indexes, backoff, deadlines, healing owners, and caller frequency. Dismiss findings already bounded cheaply enough or continuously healing.
5. Record before fixing. If the project keeps a performance ledger, append every supported finding and important dismissal using its existing convention. Otherwise return a compact report. Include priority, trigger, impact, current owner, acceptance seam, and evidence.
6. Prioritize with the policy below. If implementation is authorized, invoke the project's test-writing workflow and prove the old behavior red at the outermost practical seam. Fix, review, and update the ledger or report with verification evidence.

Priority Policy

Rank highest when the issue can cause a user-visible freeze or error, memory/disk growth, blocked request processing, data loss, fleet-wide amplification, or a poison item that prevents later work.