audit-bugs

Bug Audit Checklist

Thesis: Run this checklist against any file or module being reviewed. Each item references a real bug found in this codebase.

When to Run

Use workflow-routing first when the user asks for review/audit depth or when the diff crosses T2/T3 triggers; this checklist is scoped by that tier.

Two trigger points, not just one:

1. Pre-merge gate — before declaring a card/feature "done", run the relevant section of this checklist against every file you touched. ~20% of recent commits are post-hoc audit cleanup; running this proactively converts those into the original commit. This is the highest-ROI use.
2. On demand — when explicitly asked to audit, review for bugs, or grade code quality.

The checklist below is the same for both; only the trigger differs.

Evidence Requirements

A finding isn't "audited" until you've produced one of:

• File path + function name + line range for the offending pattern (e.g., service/feature/feature.go::Create lines 45-52).
• rg command + match count for codebase-wide patterns (e.g., rg "_ = pool\.Exec" -g '*.go' | wc -l → 3 hits).
• "Verified clean" with the search you ran, when no instances exist (e.g., rg "createResource" frontend/ → 0 hits).

"Looks fine" is not an audit result. If you can't cite the search, you didn't run it.

Core patterns (apperror, parameterized SQL, batch(), Switch/Match, createResource, alive guard) — see codebase-standards. Frontend fetch — solidjs-data-fetching. Route UI — solidjs-pages.

Audit Strategy

A single audit pass catches ~60-70% of real issues. Each pass has blind spots due to which files get read first, which patterns the search focuses on, and attention saturation on large codebases. To maximize coverage:

1. Run multiple independent passes with different focus areas — e.g., one pass for reactive patterns, one for auth/security, one for config consistency, one for the fork/rename story. Narrow scope finds more than broad sweeps.
2. Vary the search strategy — don't just follow this checklist. Grep for known anti-patterns (return () => in .tsx, _ = in .go, any in component props). Read files the checklist doesn't mention (entry-server.tsx, rename tool, CI config, env files).
3. Check reference implementations are textbook-perfect — app.tsx, login/index.tsx, dashboard/index.tsx, and settings/index.tsx are copied by the scaffold tool and by AI assistants. A bug in these propagates everywhere.
4. Verify the tool chain, not just the code — rename tool, scaffold templates, deploy scripts, and CI config can have bugs that downstream users inherit silently.
5. After fixing issues, re-read the fixed files — fixes can introduce new problems (e.g., a rename tool step that corrupts URLs by naively replacing project names inside domain strings).