## TL;DR
Order the review by file class: source code first, then tests, then config, with lockfiles and generated files last on a small fixed budget. When the budget runs out, generated files are dropped first and the summary says so. Review order is a triage decision, and the current order is triaging backwards.

## The problem

```text
review agent failed to prioritize files: reviewed lockfiles before source files: how to fix
```

## When to use
- Reviews run out of budget on lockfiles or generated files
- Source files go unreviewed while dependency diffs get full attention
- The finding list is dominated by dependency noise
- Large generated diffs crowd out real code review

## When not to use
- The PR is a dependency update and the lockfile is the actual review target (invert the priority for those)
- The agent has no budget limit and reviews everything anyway (ordering still helps, but nothing is lost)
- Lockfile findings caught a real supply-chain issue (that is the system working)

## Steps

### 1. Classify every changed file at enumeration time
Tag each file as source, test, config, or generated/lockfile using path patterns (lockfile names, generated markers, vendor paths).

Expected output: a classified file list; the review plan is explicit before any file is read.

### 2. Sort the review order: source, tests, config, generated last
Feed files to the reviewer in priority order. Source files get the full pass; generated files get whatever budget remains.

Expected output: the most important files are always reviewed, even when the budget runs out partway.

### 3. Give generated files a fixed small budget
A lockfile gets a diff-size sanity check and a changed-dependency summary, not a line-by-line review. Cap it at a fixed fraction of the total budget.

Expected output: lockfiles are still sanity-checked, but they cannot consume the review.

### 4. On budget exhaustion, drop generated files first and say so
If the budget runs out, stop at the generated class and note the skipped files in the summary. Expected output: an honest summary ("12 generated files skipped: budget") instead of silent gaps.

### 5. Special-case dependency-update PRs
When the PR touches only lockfiles and manifests, the lockfile becomes the review target and gets the full pass - changed versions, yanked releases, and license shifts. Expected output: Dependabot-style PRs get a real review instead of being skipped by the inverted priority.

## Tool compatibility
- Path-pattern classification: lockfile names per ecosystem (package-lock.json, yarn.lock, Cargo.lock, go.sum, Gemfile.lock, poetry.lock).
- Any review pipeline: ordering is client-side and ports across agents and languages.
- Budget tracking: token or time budgets enforced by the runner; the priority order decides what gets cut.

## Variant phrasings

### review budget spent on generated files
Same fix. Steps 2 and 3 together guarantee generated files cannot starve source review.

### package-lock.json dominated the review
The classic instance. Classify it as generated, cap its budget, and move on to src/.

### agent ignored src/ to review yarn.lock
Check whether the file enumeration was alphabetical or diff-order; either way, step 2's priority sort overrides it.

## Why it happens
File enumeration defaults to alphabetical or diff order, and lockfiles sort early or are simply enormous. Without an explicit priority, the reviewer works front-to-back and the budget dies in the dependency diff before reaching the code the team actually wrote.

## Edge cases
- Monorepos with generated code checked in as source: tune the generated patterns per package; a global pattern will misfire.
- Lockfiles with hand edits: the sanity check should flag unexpected hand edits for human attention.
- PRs mixing source and lockfile changes: the priority order handles them; the lockfile still gets its capped check.
- Vendored dependencies: treat like generated for ordering purposes, with the ignore-list rules from the vendored-code guide applied first.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pRjOuu9Spp5-ekH_e5Eplg