Limit Preflight

Find the difference between a necessary boundary and a number somebody guessed. A scanner finds candidates. It cannot decide whether a limit is justified.

Establish the scope

Read the repository instructions and inspect the requested code or diff. Find the project's existing limit checks, inventories, and decision records before running anything. Use documented commands when available; do not assume a particular package manager, scanner, directory structure, or ledger format.

Without a scanner, perform a code-grounded manual review. Search for truncation, slicing, maximum sizes, result caps, deadlines, retries, retention, eviction, pagination, batch sizes, and concurrency controls. Follow variables and computed values as well as numeric literals. State what the search cannot detect.

For a diff, prioritize new and changed behavior, but report an existing failed check that prevents a truthful result. For a repository audit, prioritize likely data loss, silent omissions, destructive retention, and incomplete recovery. Do not silently present a sample as a complete audit.

Generated code, tests, fixtures, migrations, and dependencies may explain a boundary. They are evidence, not automatically independent policy decisions.

Trace the behavior

For each candidate, inspect the full path from producer through storage or transport to the caller and final consumer.

1. What is bounded? Distinguish rejection, truncation, omission, sampling,

summarization, clamping, pagination, batching, eviction, attempt termination, and concurrency. Identify what the person or calling agent actually receives.

1. Who sets the boundary? Look for an applicable protocol specification,

provider capability, platform or security constraint, explicit caller policy, or operational measurement. A literal, comment, configuration option, existing test, or industry convention is not sufficient authority on its own.

1. What survives? Prove that chunks can be reconstructed or that continuation

reaches the remainder. Check stable source versions, ordering, cursors, deduplication, and retry semantics. A partial-result notice makes loss visible; it does not justify losing the data.

1. What happens at interruption? For timeouts, retries, and leases, check

cancellation, owned-child cleanup, persisted state, safe retry or resume, and visible recovery. Ending one attempt must not silently erase durable work.

1. What proves it? Inspect behavioral tests on both sides of the boundary.

Test completeness and recovery, not just that a constant has the expected value. Check related producers and consumers before declaring a fix complete.

Identical numbers need not share one policy. Different numbers may accidentally implement the same policy. Trace their authority before consolidating them.

Decide, or identify the missing decision

Classify each investigated boundary as one of:

• An authoritative hard limit imposed by the actual protocol or platform.
• A measured operational limit supported by relevant load or reliability data.
• A lossless boundary with working reconstruction or continuation.
• An explicit caller policy or adjustable soft default.
• A UI projection that leaves complete underlying data accessible.
• Temporary debt with a named owner and an exit condition.
• An arbitrary cutoff without sufficient justification.

Recommend retaining, deriving, removing, or redesigning the boundary. If the acceptable loss or intended behavior is ambiguous, state the exact decision needed and realistic options. Do not invent policy to make the audit pass.

Removing every bound is not the goal. Preserve abuse protection, resource safety, protocol requirements, and meaningful cancellation. Replace an unjustified cutoff with the right control, not unbounded resource consumption.

Record and verify

Use the repository's existing decision format if it has one. Record the source location and revision, observed behavior, authority, loss and completeness, visibility, continuation or recovery, recommendation, and supporting tests. Do not admit new behavior into a baseline merely to silence CI.

Only implement changes when the user has requested them. After an authorized change, run the relevant checks and behavioral tests, including downstream consumers. Report verified findings separately from unreviewed candidates.

Finish with the scope covered, commands and results, justified retained limits, actionable defects, unresolved decisions, and remaining detector blind spots. Keep the report concise enough to use; attach a detailed inventory separately when the task requires one. Never call an unreviewed boundary safe.