The 7-phase FSM

Strict order, only two legal back-edges, every transition validated server-side. State persisted on disk so any run can resume.

RECON → AUTH → HUNT → CHAIN → VERIFY → GRADE → REPORT
                                          ↓ (HOLD)
                                        HUNT (targeted)

                                            ↓ (user)
                                         EXPLORE → CHAIN → VERIFY → GRADE → REPORT

1. RECON

Input: target domain · Agent: recon-agent · Output: attack_surface.json

Subdomain enumeration with subfinder, live-host probing with httpx, archived URL crawl from Wayback / OTX / crt.sh, tech-stack fingerprinting from response headers + body bodies, nuclei templates for known-CVE coverage, JS endpoint extraction. All optional dependencies; missing tools degrade gracefully.

2. AUTH

Input: user-provided creds (optional) · Agent: orchestrator · Output: auth.json

4-tier signup automation:

API POST: detect signup endpoint, POST with temp email.
Browser auto-signup: stealth Chromium (patchright) with CAPTCHA solving via CapSolver.
Assisted manual: temp email + user fills the form, agent polls for verification.
Token capture: user pastes cookies / tokens from an existing session.

If --no-auth is passed, this phase is skipped entirely and hunters test unauthenticated only.

3. HUNT

Input: attack surface · Agents: hunter-agent × N (parallel waves) · Output: handoff-wN-aN.json, merged into findings.jsonl

Wave policy:

Wave 1: all CRITICAL + HIGH surfaces in parallel
Wave 2+: requeues first, then lead_surface_ids, then remaining MEDIUM, then LOW
Minimum 2 waves, target 4, maximum 6

Each hunter is spawned with run_in_background: true (Claude Code) and assigned exactly one surface. The orchestrator waits for all hunters in a wave to complete, then reconciles their handoffs deterministically.

4. CHAIN

Input: raw findings · Agent: chain-builder · Output: chains.md

The chain-builder looks for A→B exploit chains that elevate severity. For example: info-leak finding A reveals a victim ID; IDOR finding B uses that ID to extract PII. Combined, this is high-severity; individually each is medium. No HTTP access in this phase, only file reads.

5. VERIFY

Input: findings + chains · Agents: three verifiers, sequentially · Output: three round JSONs

Brutalist (max skepticism): re-runs every PoC; default answer is "this isn't real, prove me wrong". Kills hallucinated findings.
Balanced: looks for false negatives the brutalist rejected too aggressively. Catches severity under-correction.
Final: fresh HTTP requests with fresh context on only the survivors. Last confirmation before grading.

Findings survive only if all three rounds agree.

6. GRADE

Input: verified findings · Agent: grader · Output: grade.json

5-axis scoring: impact (0-30), proof quality (0-25), severity accuracy (0-15), chain potential (0-15), report quality (0-15). Total drives the verdict:

SUBMIT: total ≥ 40 and at least one finding is MEDIUM+
HOLD: 20-39 (sends back to a targeted HUNT round with feedback)
SKIP: less than 20

7. REPORT

Input: graded SUBMITs · Agent: report-writer · Output: report.md

Submission-ready report under 600 words. Title formula: [Bug Class] in [Endpoint/Feature] allows [role] to [impact] [scope]. Concrete PoC, exact CVSS, never theoretical language.

EXPLORE (optional)

Triggered by user request after REPORT. Runs new HUNT waves against untested or partially-tested surfaces, then feeds back into CHAIN → VERIFY → GRADE → REPORT. The report is amended in-place.