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 independent 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, speculative machinery, 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.

Independent review

/audit independent current uses an approved application-code checkpoint and verified spec to record a pending request in blueprint/context/review.md. Audit never creates the checkpoint commit. Existing changes only to review.md and findings.md do not require another code checkpoint; other Git changes do. An explicit invocation uses the configured execution method even when the workflow’s independent-review gate is set to manual.

With review.independentExecution: "automatic", the current runtime starts a generic isolated reviewer when it can prove fresh context, exact reviewer identity and model, and completion. That reviewer uses the Audit skill and review contract installed in the project. It does not discover global agent roles, prompts, or another workflow. If the runtime cannot prove those requirements, Blueprint preserves the request and gives you the manual fresh-session handoff instead.

With review.independentExecution: "manual", select an installed adapter and available model, open a fresh session without the builder conversation, and run the same independent Audit request. In either mode, the reviewer examines the complete feature-branch delta across quality, security, performance, and tests, runs Check when required, updates the findings ledger, and writes a passed or changes-requested receipt.

The receipt records the exact target, permitted base ref and merge base, spec hash, requested and actual reviewer adapter, model, and execution, Check result, commands, evidence, findings, and remaining risk. Later code, tests, configuration, spec, or acceptance-criteria changes make it stale. Blueprint validates the recorded state, but adapter, model, and fresh-context identity remain declared metadata, not cryptographic proof.

The permitted base must be a locally recorded remote default branch, local main, or local master. It cannot be the current work branch, and the base commit cannot equal the target. Independent mode stops when it cannot re-derive a reliable full review range.

The request records whether the applicable regular or Continuous Check policy requires Check for this work item. A passing receipt must record passed when Check is required. When it is not required, the receipt may record not-required or passed if the reviewer ran it anyway.

The selected project adapter must exist in the Blueprint installation. The matching external tool must also be installed and authenticated separately. See Tool Adapters for that distinction.

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.

Ignored local specs

In local-only mode, Audit freezes the exact verified spec under blueprint/.state/review-specs/ and records its path and hash in the new request. The spec and snapshot stay ignored and untracked. Neither is force-added, and their bytes must stay identical through review and completion.

The reviewer needs the same local files. If an isolated reviewer cannot access them, use the manual handoff in a fresh session in the original checkout. A spec-only revision can reuse the approved code commit after verification, with a new snapshot, request, and full fresh review; it needs no empty commit.

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. Independent mode also writes its request or receipt to blueprint/context/review.md and may prepare the local spec snapshot described above. Audit 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.

A proportionality finding names what can be deleted, which existing, standard-library, native-platform, or installed mechanism replaces it, and which current requirement would be lost, recorded as None when nothing is lost. It is P2 or P3 unless the unnecessary machinery causes a concrete reachable defect or violates an established security or data-integrity boundary. A suggested fix that removes or changes shipped behavior needs an explicit user decision and is never presented as an automatic repair.

Best timing

Run audit current before completing a larger feature, audit independent current when a fresh reviewer should own the gate, 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.