finding-discipline

# Finding Discipline ## Overview **The Iron Law: No `[CONFIRMED]` without proof.** A finding is a claim about real, demonstrated impact — not a status code, a reflected string, or a hunch. This is the offensive equivalent of test-driven development: the proof is the test, and the finding does not exist until it passes. **Violating the letter of this rule is violating its spirit.** ## The three tiers - **`[CONFIRMED]`** — impact demonstrated AND grounded in an evidence artifact that exists on disk. - **`[POSSIBLE]`** — reachable but the class proof bar is not yet met. Keep digging; do not report as real. - **`[INFO]`** — true but no security impact at the claimed severity. ## The proof bar (per class) A status code is not impact. See `skills/references/finding-evidence-standards.md`: SSRF needs the internal response; IDOR needs *another principal's* data; RCE needs command output; XSS needs script execution; open redirect needs an external destination. ## Required mechanical gate Before any finding is recorded or reported: 1. Set the structured proof signal and run `python skills/vulnerability-analysis/scripts/validate_findings.py --findings f.json --evidence ./evidence` — it rejects ungrounded findings and per-class false positives. 2. Pass it through the **REQUIRED** `finding-validator` agent (PASS / KILL / DOWNGRADE). 3. Only a `[CONFIRMED]` survivor goes in the report. Severity must match what was demonstrated (CVSS honest). See `skills/references/finding-...