Vigia method

Rules

1. Scope. Work only on the code in this project and on targets at localhost. Do not contact other hosts. Do not send project code to a web service.
2. Evidence. A finding without a PoC that ran is a hypothesis. Do not call a hypothesis a vulnerability.
3. Oracles. Some questions ask how a parser reads a string, for example "how does the browser read this URL?" Use the vigia oracle tools for these questions. Do not answer them from memory.
4. Writes. Write files only in .vigia/. Do not change application code unless the user asks for it.
5. Records. Save each hypothesis with the finding tool, and also save the rejected ones. Then other agents can see the work and do not do it again.

Stages

1. Map. Find the entry points: routes, views, API handlers, template engines, client bootstrap code, and public package exports. Find each trust boundary, where untrusted data enters. Write the map to .vigia/surface.md.
2. Hunt. For each trust boundary, follow the data from the source (untrusted input) through the check (validation, escaping, allowlist) to the sink (dangerous operation). Save each possible bug as a hypothesis, with file and line anchors.
3. Prove. Write a PoC in .vigia/pocs/<ID>/ and run it. Record the exact command and the output. Set the status to reproduced if the PoC shows the bug. Set it to rejected with a reason if it does not.
4. Confirm (optional). Show the impact in a small app that uses the code the way a real consumer does. Then set the status to confirmed.
5. Score. Give the exploitability score (see below), the severity, and a CVSS vector when you can.
6. Fix. Write the smallest patch that removes the root cause, plus a regression test. Store them in fix. Do not apply the patch unless the user asks.
7. Report. Run the report tool. It writes .vigia/report.md.