verify-findings

Verify Review Findings

Independent false-positive verification. Assume every finding is false until proven by evidence.

Parse Arguments

• $ARGUMENTS (required): Path to the review report file to verify

If no argument is provided, ask the user for the report path.

Step 1 — Read and Parse Report

1. Read the report file at the provided path
2. Detect review type from the header:
   • "Pragmatic Code Review Report" → code review
   • "Security Review Report" → security review
3. Extract each finding into a structured list:
   • Triage level (Blocker, Improvement, Question)
   • File path and line number
   • Description and confidence/severity scores
   • For security: CWE, category, exploit scenario
4. Skip Praise and Nit findings — only verify Blocker, Improvement, and Question

Step 2 — Verify Each Finding

For each extracted finding, perform independent verification. See WORKFLOW.md for detailed procedures.

Code Review Findings

1. Read the flagged code at the specified line with ~50 lines of surrounding context
2. Grep the codebase for the same pattern to check if it's an established convention
3. Verify the cited principle — does SOLID/DRY/KISS/YAGNI actually apply here?
4. Check framework handling — does the framework or library address this concern automatically?
5. Assess concrete impact — is the problem demonstrable or theoretical?

Security Review Findings

1. Read the flagged code and trace data flow from source to sink
2. Grep for sanitizers/validators in the code path between source and sink
3. Detect framework protections — React auto-escaping, Spring Security, Django ORM parameterization, etc.
4. WebSearch the CWE/CVE for known false positive patterns and framework-specific mitigations
5. Verify exploit feasibility — is the exploit scenario actually possible in this application context?
6. Check code context — is this test-only code, behind authentication, or behind a feature flag?