validate-external-auditlisted

# Validate External Audit ## Overview Before accepting or rejecting any external critique point, ground each claim in actual repo state. Blindly accepting degrades trust; rejecting without evidence wastes credibility. Evidence-first responses are the only durable ones. ## When to Use - Received an external audit, code review, or critique document - Stakeholder or tool has flagged N issues and wants a response - Being asked "is this critique accurate?" **Not for:** Internal self-review mid-implementation (use `judge` instead), or handoff doc staleness (use `verify-handoff-claims`). ## Core Pattern ### 1. Ground before responding Run the actual code check *before* writing any reply. Never open with an opinion—open with evidence. ### 2. For each critique point, produce one of three verdicts | Verdict | Condition | Response shape | |---------|-----------|----------------| | **Confirmed** | File/line evidence matches claim | `file:line confirms — [quote]` | | **Confirmed with nuance** | Technically right but framing is off | State what's correct, then correct the framing | | **Rejected** | Evidence contradicts claim | Specific counter-evidence, not opinion | ### 3. Add gaps the critique missed After working through all points, ask: "What did the critique not see?" These gaps often have higher priority than the confirmed findings. ### 4. Prioritize confirmed findings Order by: structural gaps (CI, automation breaks) → trust breaks (false README claims) → UX issues → c