false-positive-feedback-loop

# False-positive feedback loop (meta-skill) False positives are the #1 reason audit tools get abandoned. This skill governs the state-persistent mechanism for "user told me this is fine, don't report it again." ## Sources of dismissals ### 1. `.auditsentry.yml` `ignore:` section ```yaml ignore: - id: REENT-001 path: "src/Vault.sol" line: 142 fingerprint: "sha256:abc..." reason: "Single trusted caller, reviewed 2025-Q4" dismissed_at: "2026-05-12" dismissed_by: "alice@example.com" ``` ### 2. Inline markers in code ```solidity // auditsentry-ignore: REENT-001 — single trusted caller function trustedOp() external onlyOwner { ... } ``` Effective for next ~5 lines. ### 3. `.auditsentryignore` (file glob) ``` # .auditsentryignore test/** script/** mocks/** ``` Skip these paths entirely. ## Procedure (run before reporting findings) For each candidate finding F: ### Step 1 — Fingerprint Compute `sha256(file_path + ":" + line + ":" + vuln_class)`. This is the unique identifier for "this exact issue at this exact location in this code shape." ### Step 2 — Check ignore list - If F's fingerprint matches any entry in `.auditsentry.yml ignore:` → check freshness. - If the surrounding lines (±3 of `line`) have changed since `dismissed_at` (use git blame or content hash) → fingerprint invalidates, re-surface F with note "previously dismissed but code has changed". - Otherwise → skip F, do not report. ### Step 3 — Check inline markers Scan within 5 lines abo...