1184898069/large-data-safety-review

Large Data Safety Review

Review the complete data path for bounded production behavior. Report evidence-backed findings, confirmed safe paths, missing evidence, and tested or untested limits.

Operating Rules

• Read-only by default. Do not modify code, dependencies, databases, production settings, or external systems.
• Do not install dependencies.
• Never treat missing evidence as proof of safety. Mark the affected layer Unverified.
• Do not claim a supported scale without runtime, load-test, query-plan, or equivalent evidence.
• Treat pattern matches as candidates, not findings. Read the surrounding data flow before reporting.
• Prefer the user scope or current diff. Keep discovery, reading, commands, and output bounded.

Workflow

1. Establish scope

Read the request, repository instructions, named files, current diff, and direct producers and consumers. State reviewed, excluded, and missing layers.

2. Build the scale profile

Record current volume, design limit, request frequency, concurrency, growth, item size, interaction targets, and resource limits. If values are absent, label diagnostic assumptions separately from confirmed values.

Use these diagnostic probes only when user evidence is missing:

• 10,000,000 stored rows.
• 100,000 matching rows.
• 100 concurrent interactive requests.
• Page size 100, hard maximum 200.
• 100,000 logical table rows with bounded DOM rows.
• 1,000,000 export or batch rows.
• 10x growth.

3. Trace the data path

Trace:

Data source -> query/data access -> service/job -> API/serialization -> state management -> page/table/export

State which layers are supported by evidence.

4. Review each layer

Use references/review-checklist.md for the cross-stack review.

Load references/vue2-axios-vxe-table.md only when the path contains Vue, axios, vxe-table, browser state, or data-heavy table rendering.

Load references/dotnet-webapi-efcore.md only when the path contains ASP.NET WebAPI, EF Core, LINQ, controllers, services, repositories, exports, or background jobs.

Do not load every reference by default.

Check storage/query scope, materialization, projection, indexes, stable pagination, payload size, cancellation, timeouts, bounded concurrency, backpressure, idempotency, retries, state copies, computed work, DOM size, loading states, and degradation.

5. Validate candidate findings

For every candidate:

1. Identify the growing input or concurrency dimension.
2. Confirm where filtering, projection, paging, buffering, or rendering occurs.
3. Check existing hard limits and whether they are tested.
4. Trace cancellation, timeout, retry, and error propagation.
5. Record exact file and line evidence when code is available.
6. Reject the candidate if the context proves the path is bounded.

6. Classify evidence and severity

Evidence states:

• Confirmed: direct code, SQL, configuration, test, runtime, or design evidence.
• Probable: strong path evidence with one missing upstream or downstream artifact.
• Unverified: necessary material is unavailable.

Severities:

• P0: confirmed data damage, production unavailability, or uncontrolled resource exhaustion on a reachable path.
• P1: likely timeout, OOM, database overload, severe interaction failure, or incorrect results at known or diagnostic scale.
• P2: meaningful degradation as volume or concurrency grows, with current headroom or an alternate path.
• P3: missing limits, observability, tests, or maintainability evidence without a demonstrated severe failure.

Do not assign P0 or P1 from diagnostic assumptions alone. Put severe but unsupported risks under high-priority verification.

7. Write the report

Load references/output-contract.md and follow it exactly.

Each finding must include:

• Severity and evidence state.
• Layer and stable root-cause code.
• Evidence location.
• Trigger scale.
• Impact.
• Minimal remediation.
• Verification method.

List confirmed safe paths only when evidence supports them.

Repository and Output Limits

• Enumerate at most 100,000 paths as metadata; narrow by directory and extension above that.
• Scan at most 20,000 source files or 500 MiB of text per content pass, whichever comes first.
• Retain at most 500 candidate matches; aggregate the rest and record the truncated count.
• Deeply read at most 200 candidate files per pass.
• Use a 60 seconds default command timeout; narrow the scope after a timeout.
• Expand at most 50 findings and 5 representative evidence locations per root cause.
• Skip dependencies, generated output, archives, binaries, build directories, and large minified files.
• Report every exclusion and truncation with original count, retained count, and reason.

Missing Evidence and Failures

• Frontend only: review the frontend and produce an Unverified backend/API/database contract.
• Backend only: review the backend and mark consumer rendering and interaction Unverified.
• Oversized repository: narrow from diff, routes, clients, queries, exports, and render entry points.
• Command timeout: reduce the batch or path scope instead of repeatedly increasing timeout.
• Documentation conflicts with code: prefer code, tests, query plans, and runtime evidence; report documentation drift.
• Sensitive material: do not repeat secrets or records; use a redacted location description.