Limit Audit

Find every candidate boundary

Search the code for truncation, slicing, page sizes, deadlines, retries, retention windows, and concurrency caps, following computed values as well as literal numbers. Say plainly what a quick search cannot catch.

Trace what actually happens at the edge

For each candidate, follow the full path from where the data is produced to where it is finally consumed.

• What kind of bound is it — rejection, truncation, sampling, pagination
• Who set it — a protocol spec, a measured resource limit, or a guess
• What survives — can the rest be reconstructed or fetched later
• What happens on interruption — does a cancelled attempt erase completed work

Classify before you touch anything

Sort each boundary into one of: a hard limit set by the protocol itself, a measured operational limit backed by real load data, a lossless boundary with working continuation, an adjustable policy, or an arbitrary cutoff nobody can justify. Then recommend keeping it, deriving it from something real, or redesigning it — never invent a policy just to close the audit.

Protect the limits that are load-bearing

The goal is not zero limits. Abuse protection, resource safety, and meaningful cancellation still matter. Replace an unjustified cutoff with the right control, not with unlimited resource use.

Make the loss visible when you cannot remove it

When a limit forces a partial result, state the total scope, what got processed, what got left out, and how someone can pick up the rest. A partial-result notice makes the loss honest — it does not excuse the boundary from being wrong.

Record what you found and verify it

Log the source location, the observed behavior, the authority behind the number, and the supporting tests, using whatever decision log the project already keeps. Only change behavior when asked to, then run the checks on both sides of the boundary — never call an unreviewed limit safe.