## TL;DR
Never sort a live list while you are walking it. A feed update mid-run rescored CVEs, the order shifted, and the agent triaged the same 80 twice while the tail starved. Snapshot the ordered work list at run start, process the snapshot, and let feed updates apply to the next run. Log progress so a rerun resumes instead of restarting.

```text
the agent processed the backlog in severity order but the sort key changed mid-run when a feed update rescored CVEs - it triaged the same 80 twice and never reached the tail
```

## Use this when
- Triage runs keep covering the head of the backlog and never reach the tail.
- The same CVEs show duplicate triage activity in one run window.
- Feed updates land while the run is in progress.

## Not for this skill when
- Brand-new critical CVEs arrive mid-run and need immediate attention. That is an interrupt path, separate from the batch run.
- The backlog is small enough to finish in one pass. Then re-sorting is harmless.

## Steps
1. Snapshot at start: copy the ordered list of finding IDs (with their scores at snapshot time) into the run's working set. Verify: the run log shows a fixed count of items to process.
2. Process only the snapshot. If a feed update rescored something mid-run, note it and keep going in snapshot order. Verify: no finding is triaged twice in one run.
3. At run end, reconcile: apply the feed updates to the store, and carry any rescored-but-unprocessed items into the next run's snapshot with a "rescored" flag. Verify: the next run's snapshot includes them exactly once.
4. Log per-item progress durably as you go, so a crashed run resumes from the last completed item instead of restarting. Verify: kill a run halfway and confirm the retry continues, not restarts.
5. Add a run metric: unique findings triaged vs total triage actions. If the ratio drops below 1, the snapshot is leaking. Verify: the last bad run would have shown the leak.

## Variant phrasings
### backlog sort key changed mid-run
The short phrasing.
### triaged same CVEs twice rescore
The symptom search.
### feed update re-sorted triage queue
The cause phrasing.

Compatibility: any batch triage loop over a live-updating store; snapshot-then-process is a general pattern.

## Why it happens
The loop read "order by severity" fresh on every page or batch, and severity is a moving target while feeds update. Pagination over a mutating sort is a classic way to revisit rows: items that move up get seen again, items that move down get skipped. The run had no stable view of its own work.

## Edge cases / pitfalls
- A true emergency (new KEV addition for your stack) should interrupt the batch run via a separate fast path; do not let the snapshot become an excuse to ignore it.
- Snapshot staleness cuts both ways: if the run takes hours, the tail is triaged on hours-old scores. For very long runs, snapshot in chunks.
- Dedupe the reconciliation too: an item rescored twice between runs should still enter the next snapshot once.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-4p6RaJEi6AFctGL7fJObw