bug-bounty-reportinglisted

# Bug Bounty Reporting ## Paramount Points Verbatim; keep internal: > 1. **Concise** - Triagers need simple language, no mince words. Straight to the point reports. Every word create cognitive burden > 2. **Triagers are lazy** - They need ELI5 steps and easy to understand reports; reproduction must be done for the fastest and easiest to understand triaging possible. > 3. **Do not talk like a Robot** - LLM written report patterns discourages triagers. Write reprots like a human would do. ## Status Rules | Status | Required evidence | |---|---| | `draft` | Exact final PoC lacks full-live evidence | | `full-live` | Exact final PoC produced uncut end-to-end evidence | | `submission-ready` | Frozen full-live snapshot passed independent review | ## Workflow Give the triager the easiest, most seamless triage experience possible. They already have the report open and a VM to run things in, so don't make them transfer files and reconstruct state by hand. Give the team an easy triage and remediation-retest experience. They have to hand the bug to devs (who often work without a proxy) and later confirm their fix works. A re-runnable POC lets them do both. Yes, this can eat into retest payouts, but Justin's take is that overall throughput is worth more than grabbing at a $50 retest right now. Give yourself an easy way to visualize and validate what your hackbot reports. If you're running a bot, your life is triage: you open the queue, read the finding, drop the POC script into y