auditor:re-audit

auditor-skill — Fix Review / Re-Audit

Arguments: $ARGUMENTS

Re-audit a codebase after a fix round. Input: a prior audit_<n>/REPORT.md (arg 1) and the current tree; the delta range is base..head (arg 2, default main..HEAD — the fix commits). Read OUTPUT-RULES.md first (severity 1-10, the Rule 5b gate). This is a Zenith/Certora-style fix-review, not a fresh audit — it reuses the prior report as the baseline and reports what changed.

Steps

1. Load the baseline. Parse the prior report's findings (id, severity, file:line, root-cause, Rule 5b block). Pin both commits: the prior report's audited commit and the current head.

2. Classify every prior finding. For each prior finding, read the current code at the (possibly moved) location and assign one of six states. Every non-open status must cite the remediation commit/PR hash that changed it (git log --oneline / the PR the fix landed in), not merely the current file:line — the reader must be able to point at what fixed it, not just where the code now sits.

   • FIXED — the vulnerable path is gone. Re-run Rule 5b on the fix: confirm the fix actually closes the reachability/bound the finding claimed — a cosmetic or incomplete patch is not FIXED. Cite the fixing commit/PR hash and file:line.
   • PARTIALLY-FIXED — the fix closes some of the reachability/bound but a residual path survives (one call site patched, an edge input still breaks it, the guard added is necessary-but-insufficient). Re-run Rule 5b on the residual path and carry a severity for what remains. Cite both the fixing commit/PR hash and the surviving file:line.
   • STILL-OPEN — the finding survives unchanged (or was never touched). Carry its severity forward.
   • REGRESSED — the fix introduced a new problem, or a previously-fixed issue returned, or the "fix" made it worse. Treat as a fresh finding through the full Rule 5b gate; a security check deleted in a fix commit is a CRITICAL regression (git-blame it, cite the commit).
   • ACKNOWLEDGED — the client accepts the risk and has not changed the code (won't-fix / risk-accepted). The code still contains the vulnerable path, so severity is unchanged — do not score it as resolved; record it as an accepted-risk item.
   • DISPUTED — the client contests the finding's validity/severity and the code is unchanged. Record the dispute as the client's position, then state our independent re-derivation verdict (upheld / downgraded / withdrawn) from the code — the report keeps our verdict, not the client's assertion, as the ruling.