Code Quality With Audit - AI Blueprint Docs

Use a read-only audit to catch maintainability drift before it becomes the project's default style.

What to look for

AI-assisted code can accumulate repeated helpers, slightly different component patterns, unused exports, oversized files, and untested business logic. Audit examines the codebase for those patterns without changing it.

Match the scope and lens to the job

Use audit current for an active feature. It covers committed checkpoint work from the feature branch’s merge base through HEAD, along with local changes and nearby code. Use audit changed for only the current working changes, a path for one subsystem, or audit full for a project-wide hardening pass.

A full audit excludes generated and third-party code, reports what it reviewed and skipped, and states whether coverage was complete. This keeps a large repository from receiving a misleading clean bill of health after only a partial scan.

Add a focused lens when you do not need every concern reviewed:

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

Quality covers maintainability and standards. Security covers trust boundaries and data exposure. Performance covers repeated or unbounded work and runtime risks. Tests covers coverage gaps and the reliability of the test suite itself. A focused pass reports which other lenses it omitted.

Handle findings deliberately

Classify each finding by impact and confidence. Fix clear defects and harmful duplication. Do not turn every stylistic preference into a refactor, especially when it would broaden the active feature.

Confirmed high-severity findings need concrete evidence. If the code path or failure cannot be established, keep the concern in the report as an unverified risk instead of presenting it as a confirmed blocker.

Findings are recorded in blueprint/context/findings.md with durable IDs and statuses, and a serious finding blocks completion until it is repaired and re-reviewed, accepted with a reason, or invalidated. The Findings Ledger covers the full lifecycle.

Configure automatic audit gates

Direct /audit runs remain available at any time. Separately, blueprint/config.json can run an audit automatically for regular or Continuous work. Each audit gate defaults to manual. Use when-sensitive for work that crosses security, data, payment, migration, destructive-operation, external effect, or unusually broad boundaries, or use always for every work item.

Autopilot uses qualityGates.regular.audit. Continuous Mode uses qualityGates.continuous.audit once per feature. See Project Configuration for the full policy.

Clean up a vibe-coded project

Adopt the existing codebase first so Audit can judge it against real project conventions. Then run audit full, review the prioritized findings, and turn accepted work into small fixes. Address security, data integrity, broken behavior, validation, and unsafe types before broad maintainability cleanup.

Avoid one giant rewrite. Fix one risk area at a time, rerun the relevant checks, and repeat the audit after the highest-risk batches land.

Security and performance

The security and performance lenses can flag obvious unsafe input handling, missing authorization scope, secret exposure, expensive repeated work, or avoidable client code. They are not substitutes for a dedicated threat model, penetration test, dependency scan, or production profiling when those are required.

Audit never prints a suspected secret value or raw output containing it. Reports identify only the redacted category, location, risk, and remediation.