Plan → execute → reflect: execution-grounded confirmation

Severity policy is one half of the stack. The other half is the research method: plan a probe, execute it under a safety envelope, then reflect with hard oracles. That loop lives in tcsf/exploit/confirmation_loop.py.

Safety before HTTP

• TargetEnvironment.in_scope(url) — out-of-scope requests never leave
• destructive_payload_blocked — research-mode write blocks (DROP / DELETE / …)
• Planner / executor / reflector are separable stages — each can fail closed

Hard oracles in validate_exploit_impact

• SQLi — syntax markers + boolean body-oracle vs baseline
• XSS — payload reflection without HTML-encoding
• BOLA / IDOR — validate_bola_response rejects generic nginx/404 bodies

Memory changes the next probe

Trajectory helpers (filter_fp_payloads, record_successful_probe, top_payloads_for_category) bias future attempts. Successful paths attach exploit_verified evidence via attach_exploit_verified_evidence. Unverified chains stay hypothesis or medium — the gate and the loop are one system.