Audit

Choose the scope and lens

Scope chooses where Audit looks. A lens chooses what it looks for. They are separate controls and can appear in either order.

/audit current
/audit quality changed
/audit security current
/audit performance src/api
/audit tests src/auth
/audit full

• current includes the active spec, committed feature-branch changes from the merge base through HEAD, local changes, and nearby affected code.
• changed covers staged, unstaged, and untracked source files plus nearby code.
• full reviews project-owned source, tests, and configuration while excluding dependencies, generated files, build output, coverage, caches, vendored code, and minified assets.
• A path limits the review while still including the tests and callers needed to understand it.

With no scope, Audit chooses the active feature when one exists, local changes when the working tree is dirty, and the full project otherwise. full always means the full-project scope. It is not a lens.

Choose a focused lens

• quality reviews duplication, dead code, complexity, inconsistent patterns, and standards drift.
• security reviews authorization, input trust, injection, sensitive-data exposure, secret handling, and unsafe configuration.
• performance reviews repeated queries or network work, unnecessary rendering, blocking hot paths, memory growth, oversized payloads, and unbounded work.
• tests reviews important logic without coverage, weak assertions, brittle mocks, shared state, likely flakiness, and skipped or placeholder tests.

With no lens, Audit reviews all four concerns. /audit full therefore runs a broad audit across the full project. A focused lens runs only relevant signals and states which other concerns were not reviewed.

The report identifies the selected scope and lens, commit range, reviewed and excluded paths, unavailable checks, and whether full-project coverage was complete. A partial or focused review is never presented as a broad audit.

Findings and the ledger

Audit records findings in blueprint/context/findings.md with durable IDs (F-01), severity, and status, so they survive a context clear. The ledger is the only file audit writes; it never edits source or commits fixes. Turn accepted findings into a focused fix or handle them in the active implementation spec.

A later pass moves a fixed finding to closed only after re-examining the repaired code: the original defect must be gone and the repair must not have introduced a new one. The ledger reports status; it never becomes the checklist a review scopes to. Every pass reviews the code fresh. See The Findings Ledger.

High-severity findings require concrete evidence such as a reachable code path, violated contract or security boundary, failing check, or reproducible behavior. Unconfirmed concerns are separated from confirmed findings. Suspected secret values are always redacted and never copied into the report.

Best timing

Run audit current before completing a larger feature, audit full when an existing or vibe-coded project needs a broad cleanup plan, or combine a focused lens with current, changed, or a path when one concern needs attention.