audit-pass2-verifier

name	audit-pass2-verifier
description	Read an audit report claiming fixes applied (PASS 2, PASS 3, etc), verify each claim against source code, then execute deferred items. Use when handed an audit markdown that lists "FIX: applied" entries, when asked to "close audit findings", or to "validate audit work to production".

audit-pass2-verifier

Trigger

User hands you (or you find) an audit/review markdown that:

• Tables findings with severity (CRITICAL/HIGH/MEDIUM/LOW)
• Marks some as FIX: applied in PASS N
• Marks others as DEFERRED
• Includes file paths + line numbers

User says: "verify the audit", "close the audit", "complete the deferred items", "drive this to production-validated".

The Rule

Audit docs lie. Verify every "FIX applied" claim in source before trusting. Then execute deferred items in priority order.

Why: Audit markdown is human/agent-authored. Edits get reverted, hooks reformat them away, parallel sessions overwrite them. Trusting the doc without verification = building on quicksand.

How to apply: Source-of-truth pass, then deferred-execution pass, then test-suite delta.

Workflow

Step 1 — Read audit doc ONCE

Capture: findings table, status column, file paths, line numbers. Do NOT re-read.

Step 2 — Verify each "applied" claim

For each PASS N "FIX: applied" entry:

grep -n "<expected-symbol>" <file-path>

Use grep -n not rg when pattern has special chars (parens, backslashes) — shell escape eats \( in unquoted rg patterns and silently returns 0 matches. Match: claim verified. No match: doc lied or work got reverted.

Build a verification table:

Finding ID	Claim	Verified?	Evidence
C-01	budget gate added L555	YES	nodes.py:559 matches
C-02	_find_garment_image returns "" if missing	YES	tryon_agent.py:171 is_file()
...

Step 3 — Execute deferred items

For each DEFERRED finding, decide:

• (a) Do the work if scope fits the current pass.
• (b) Defer with a concrete plan in a follow-up task file.
• (c) Partial work if a clean subset can ship.

Apply the project's existing pattern (e.g., for a budget gate, mirror the pattern at graph/nodes.py:294-325). Don't invent.

Step 4 — Test delta

pytest <scope> -v --timeout=15 -q 2>&1 | tail -10

Compare to audit's baseline. Report: before X/Y → after X/Y. Categorize remaining failures: pre-existing-out-of-scope vs new-and-bad.

Step 5 — Final report

Structured output:

## Verified (PASS N)
<table: ID | file:line | evidence>

## Executed Deferred
<table: ID | files changed | scope>

## Tests
<before → after delta>

## Still Deferred (with reason)
<table: ID | why deferred | next action>

Anti-Patterns

• Don't trust the audit doc without grep verification
• Don't re-read the audit markdown after the initial pass — it's static
• Don't fix LOW findings unless trivial — they sit on the deferred list for a reason
• Don't run paid APIs to "test" the fix — code path verification + unit tests only
• Don't refactor in scope — audit fixes are surgical

Example invocation

Audit lists 3 CRITICAL + 4 HIGH + 4 MEDIUM. PASS 2 claims 3 CRITICAL + 3 MEDIUM applied; 4 HIGH deferred.

You: grep each of the 6 "applied" claims → 6/6 verified → take H-01 + H-02 (FLUX budget gate ripple), wire the gate at orchestrator level (cleaner than the audit's stage-level suggestion since grep shows compositor_agent doesn't call flux_pipeline) → run tests, 479 pass / 0 fail → report shows H-03 / H-04 (file size splits) still deferred with note.

Related

• verification-before-completion
• systematic-debugging (for treating audit doc as hypothesis, not fact)
• commit-batch-sweep (for landing verified work)