review-methodologylisted

# Review Methodology The canonical review process for all Devflow review agents. Ensures consistent, fair, and actionable code reviews. ## Iron Law > **NEVER BLOCK FOR PRE-EXISTING ISSUES** > > Only issues in YOUR CHANGES can block a PR. Pre-existing issues are informational only. > If you didn't add it, you don't own it. Fair reviews focus on the diff, not the codebase. ## Core Philosophy 1. **Focus on changed lines first** - Developer introduced these 2. **Context matters** - Issues near changes should be fixed together 3. **Be fair** - Don't block PRs for legacy code 4. **Be specific** - Exact file:line with examples 5. **Be actionable** - Clear fixes, not vague complaints --- ## 6-Step Review Process ### Step 1: Identify Changed Lines Get the diff to understand what changed. Identify base branch and extract changed files/lines. ### Step 2: Categorize Issues | Category | Scope | Priority | Action | |----------|-------|----------|--------| | **1. Issues in Your Changes** | Lines ADDED/MODIFIED in this branch | BLOCKING | Must fix before merge | | **2. Issues in Code You Touched** | Same file/function, but not your line | HIGH | Should fix while here | | **3. Pre-existing Issues** | Lines you didn't touch at all | INFORMATIONAL | Fix in separate PR | **Note:** All categories and severities — including suggestions — are reported for resolution. Categories affect PR merge-blocking, not whether issues get resolved. The resolve workflow evaluates everything. ### Ste