evidence-based-developmentlisted

# Evidence-Based Development ## Iron Law **EVIDENCE BEFORE CLAIMS, ALWAYS. If you haven't read the code, you don't know what it does.** No recommendation without a citation. No behavioral claim without verification. Confidence is not evidence. ## Show Before Decide Never propose a change without first showing the current state: "Here's what I found at `file.rb:42` → here's what I recommend → here's why." ## Citation Requirements Every claim about code carries a `file_path:line_number` reference. When reviewing diffs, cite the file and the specific hunk. When reporting issues, show the exact code snippet. ## Finding Prioritization All findings, review comments, and issues use P1/P2/P3. This operationalizes the organizational hard boundary **"No Ungrounded Claims"**: every finding carries evidence (file:line, test output, runtime observation) proportional to its priority. | Priority | Meaning | Action | |----------|---------|--------| | **P1** | Must fix — blocks merge, security issue, data loss risk, broken functionality | Fix before proceeding | | **P2** | Should fix — logic error, missing edge case, test gap, convention violation | Fix in this PR | | **P3** | Consider — style preference, optimization opportunity | Fix in-PR by default. Cosmetic P3 in untouched files: fix-if-bounded or document inline (default) / follow-up issue (`minimalScope` mode only). Finding triage is NEVER a valid escalation trigger — see `skills/llm-operator-principles/SKILL.md`. | ## ASSER