The findings worklist
A per-repository list of scan leads across scans, with occurrence history, a human archive, and a fix prompt bound to one SHA.
Open Findings in the console after you claim an install.
A scan report is one snapshot at one commit. The findings worklist is the remembered list of those leads for a repository: what was reported, on which SHAs, and what a human archived.
What it stores
Each row is a reported authorization, IDOR, or business-logic lead. A lead is not a confirmation that the issue is real or still present.
- First and last reported SHA
- Occurrence history: each scan that indexed that lead
- A human archive: dismissed or addressed, with the actor and time
- A fix prompt for a selected occurrence SHA, the same packet as on the scan report
A later scan that does not mention a lead does not mean it is fixed. Aevral does not auto-archive because a later scan omitted it.
If a lead is archived and a later scan reports it again, it shows as reported again. Old archive rows stay.
What it is not
- Not a Sentry-style open versus resolved inbox
- Not a patch generator
- Not a GitHub issue writer
- Not mixed with PR review comments
- An empty worklist means no indexed leads. That is different from a scan that reported N findings on one SHA
The GitHub Check is still the scan outcome on that commit, with a link to the report. It does not list the worklist.
Start
The worklist is part of the scan product. Open Findings in the console after you claim an install. Scan details: What a scan looks like.