audit

ranger — Cross-Language Bug-Hunting Skill

How It Works

One skill, one fixed 5-phase pipeline (recon → scanner → boundary-tracer [conditional] → adversary → exit-gate). What changes is which part of the request drives it:

• Full sweep — no category or candidate named: every hazard taxonomy gets scanned.
• Targeted scan — the request names one hazard category (e.g. "unhandled promises"): the same pipeline runs, scoped to that category.
• Verify one candidate — the request hands ranger an already-identified bug: adversary runs directly against it, skipping the sweep.
• Post-remediation check — the request asks whether prior findings are resolved: exit-gate re-reads the code from scratch and confirms.

There is no ranger/scan or ranger/verify to invoke separately — one skill directory (skills/audit/), the request itself determines which phase does the work.

---

Pipeline

workspace → recon → scanner → [boundary-tracer?] → adversary → exit-gate → finding-report@1

1. Recon — builds verified manifest: live files, dead files, entry points, language.
2. Scan — loads language-specific hazard reference, runs grep patterns against live files only, emits candidate@1 list.
3. Boundary Tracer (conditional) — traces field survival for T7 and T10 candidates. Skipped for all other taxonomies.
4. Adversary — reads actual code, traces control flow, and refutes candidates. Batched by crate/module to evaluate multiple candidate signals in one pass, minimizing subagent overhead. Confirms when a concrete failing scenario can be stated; emits plausible when no refutation exists but reachability depends on state outside the code (config, an external caller, environment).
5. Exit Gate — after remediation, re-reads code from scratch, checks all confirmed findings are gone, scans for sibling gaps, verifies compile and tests. Plausible findings pass through to the verdict for human review, never as remediation targets. Escalates to human when retry_count exceeds 3.