Autopilot

Step 6 - configured quality audit and repair

Apply qualityGates.regular.independentReview before a same-session audit:

• manual skips automatic independent review unless a request already exists.
• when-sensitive requires it for authentication, authorization, payments, secrets, personal or user data, migrations, destructive operations, external side effects, security boundaries, or unusually broad changes.
• always requires it for every work item.

The selected review runs after all implementation steps, final Verify, required Check, and the verified spec, before the final review packet and /complete. review.independentExecution chooses the manual fresh-session handoff or an automatic isolated reviewer; it does not change when the gate is selected.

When selected, do not review the builder's work in this session. Ensure application code is in an approved clean checkpoint. Include the verified spec when tracked; an intentionally ignored spec uses Audit's local Spec snapshot contract without changing visibility. Then follow Phase A of /audit independent current. With automatic execution, spawn and wait for the isolated reviewer, then validate its normal receipt. With manual execution, stop with the handoff. Autopilot may use its existing configured checkpoint authority when checkpoint commits are enabled; otherwise show the exact review-checkpoint candidate and ask before committing. On resume, continue only when a fresh reviewer wrote a current passed receipt. Repair changes-requested P0/P1 findings within the normal scope and attempt limit, then obtain a new checkpoint and prepare a new review. A passing independent receipt satisfies the configured Audit gate. A local-spec-only revision may reuse the same approved product HEAD after normal spec and verification gates, with a new snapshot/request and full fresh review. Do not create an empty commit for ignored spec changes. Automatic execution must also confirm access to the same local spec/snapshot and installed skills; otherwise retain the request and use the manual handoff in the original checkout.

The request records Requested execution; the receipt records Actual execution. Require the execution and reviewer-context pairing defined by the project-local review contract, including actual manual plus fresh session when an automatic request explicitly falls back. On resume, a pending request without Requested execution is legacy manual-only. Never add execution fields or run a subagent against it.

Apply qualityGates.regular.audit:

• manual - skip the automatic audit; /audit remains available when explicitly requested.
• when-sensitive - run /audit current for authentication, authorization, payments, secrets, personal or user data, migrations, destructive operations, external side effects, security boundaries, or unusually broad changes.
• always - run /audit current for every work item.

When the gate runs, audit the active feature, its diff, and the nearby code affected by the change. This is a targeted feature audit, not a repository-wide cleanup pass. Findings are recorded in blueprint/context/findings.md with durable IDs and statuses, as /audit defines; the ledger reports status and never scopes what the audit examines.

For every finding:

1. Validate it against the actual code, spec, tests, coding-standards.md, and local project patterns. An audit finding is evidence to investigate, not an automatic instruction to edit.
2. Repair confirmed P0 and P1 findings when the fix stays inside the approved feature scope, does not require a product or architecture decision, and does not remove or change shipped behavior. Set the repaired finding to fixed in the ledger, never closed.
3. Report P2 and P3 findings in the final packet. Fix them only when the change is small, directly caused by the current feature, and clearly required by the project standards.
4. If a confirmed P0 or P1 finding cannot be repaired safely within scope, stop and report it. Do not present the feature as ready for /complete.

After any audit repair:

1. Rerun the documented Verify command when present; otherwise rerun the affected build, lint, typecheck, and test commands.
2. Rerun the acceptance evidence affected by the repair.
3. Recheck the repaired area using the same targeted audit criteria. When that recheck confirms the original defect is gone and the repair introduced no new one, move the fixed finding to closed under the /audit close conditions and name it in the packet. An unrelated new finding gets its own ledger entry and does not keep the repaired one open.
4. Create a checkpoint commit only after the repair and its checks pass, and only when checkpoint commits are enabled.

Use the existing two-attempt hard stop for repeated repair failures. Do not widen the feature into a general refactor, silently suppress a finding, or turn this step into a full-project hardening pass. A broader cleanup remains a separate /audit followed by planned /fix work.

Step 7 - configured try guide

Apply qualityGates.regular.tryGuide:

• manual - skip automatic generation; /check guide remains available when explicitly requested.
• when-user-facing - run /check guide when the change affects UI, navigation, copy, a public API or CLI, output, or another workflow a person directly uses.
• always - generate a guide for every work item.

The guide is a review artifact, not proof. Never claim the user performed it.

Step 8 - final review packet

Stop with a concise review packet. Keep it useful enough for /complete but not a full audit report:

• branch name
• target feature or fix
• whether the spec was created or resumed
• what the spec critique changed
• changed files and why each changed
• build/test/check commands run, with pass or fail
• effective regular quality-gate policies and which automatic gates ran or were skipped
• independent-review target, selected reviewer and model, and receipt state
• screenshots or output paths, when relevant
• how to try it manually, or a pointer to /check guide for the full walkthrough
• checkpoint commits created
• self-review findings
• targeted audit scope and findings, when the audit gate ran
• audit repairs made and checks rerun, when applicable
• P0/P1 findings still open or fixed in blueprint/context/findings.md, which block /complete
• unresolved risks or skipped checks
• exact next action

If everything is green, the next action is usually: review the diff, run /check guide if its gate was manual and a walkthrough is wanted, then /complete.

Always offer a read-only walkthrough of the completed code after the packet. Follow the spec's build steps, explain the key files, symbols, flow, and non-obvious decisions, then offer a focused deep dive. Keep /check guide distinct as the manual product-review path.

If something failed, name the failing check and the next fix target.

Hard Stops

Stop immediately and report instead of continuing when Autopilot would need to:

• commit on main, merge, delete a branch, push, deploy, publish, or send anything
• delete data, reset a database, run irreversible migrations, kill processes, or change system settings
• install dependencies or use network access without the current tool's approval flow
• make a product decision not covered by the docs
• continue after two failed fix attempts on the same issue
• hide, skip, or hand-wave a failing check

Rules

• One Autopilot run handles one feature or one fix.
• Autopilot creates checkpoint commits on the feature or fix branch after passing steps only when project config enables them.
• Autopilot uses qualityGates.regular. The Continuous gate policies and the continuous section do not change an Autopilot run.
• When its audit gate runs, Autopilot audits the active feature and affected code, not the entire project.
• A P0 or P1 finding left open or fixed in blueprint/context/findings.md blocks readiness for /complete. The ledger is what makes this enforceable.
• Autopilot stops before /complete. It never merges.
• The Blueprint files remain the state machine. Keep current-feature.md accurate as steps complete.
• Follow coding-standards.md, ai-interaction.md, and AGENTS.md.
• Prefer fewer, higher-quality changes over broad coverage.
• Report uncertainty plainly. A blocked run is useful if it tells the truth.

Formatting

Format the output to match the project's conventions in blueprint/context/ai-interaction.md: concise, scannable markdown, with lists for enumerations and tables for matrices rather than dense paragraphs.