Complete

Preconditions

Run complete after implementation is finished, you have reviewed the result, and the exact documented Verify command has passed. When Verify is not configured, the fallback build and relevant test commands must pass.

Complete refuses to land work while any P0 or P1 finding in blueprint/context/findings.md is open or fixed. Close findings through an audit re-review, or waive one explicitly: accepted requires your decision and a recorded reason, invalid marks a finding the review got wrong. See The Findings Ledger.

When a blocking finding belongs to the active feature, fix, or rollback, keep the repair inside that work item. Add the repair as a new checklist step and run /implement; do not start a separate /fix while the current spec is active. After the focused check passes, Implement marks the finding fixed. Run /audit current to re-review the updated code and move the finding to closed, then run /complete again. If independent review is required, its receipt must also cover the updated code.

A required or explicitly started independent review also blocks completion while its receipt is missing, pending, changes-requested, malformed, or stale. A passing receipt must still match the exact checkpoint, base, spec, requested reviewer and model, requested and actual execution, reviewer context, required Check result, and non-empty evidence sections. When a selected review has no receipt yet, Complete follows the configured automatic or manual execution path instead of skipping the gate.

For an intentionally ignored spec, the receipt also binds an exact local spec snapshot. Both files must still match; completion never force-adds them. See Independent review.

Work closeout

Complete:

1. Archives the active spec under blueprint/history/features/, blueprint/history/fixes/, or blueprint/history/rollbacks/.
2. Appends resolved findings to that archive with work-item prefixed IDs (12/F-03, or 12-build-2/F-03 for a second build), carries unresolved entries forward in the ledger, and resets the ledger when empty.
3. Archives a current passing independent-review receipt with the work item and resets review.md.
4. Checks off a completed feature, or unchecks the target of a completed rollback while preserving its number.
5. Resets current-feature.md to its empty stub.
6. Requests approval before creating one conventional work-level commit, including revert: for rollback work.
7. Follows the configured git.landing path.

Complete applies the regular try-guide policy after required verification and review gates. Testable work finishes with the generated ## Try it now proof. When no safe direct observation exists, Complete omits the section and says so plainly. The proof is a user demonstration, not verification or acceptance.

With the default local-merge setting, Complete requests explicit approval before squash-merging into the local default branch. It deletes the finished local branch after verifying the merge, then asks separately before pushing the default branch.

With pull-request, Complete confirms the remote and base branch, then requests one approval to push the work branch and open a pull request. The pull request must use squash merge. Creating it does not approve merging it, enabling auto-merge, deleting the remote branch, or pushing the default branch. After the provider reports the merge, run Complete again to verify the exact result and offer local branch cleanup.

For a rollback, complete preserves the original feature archive and adds a separate dated rollback record with the target commit, reason, dependency review, compatibility work, and verification evidence. History records both that the feature shipped and why it was later removed.

Feature archives preserve every build. The first uses NN-name.md; a later build after rollback uses NN-name--build-2.md, then --build-3.md, and so on. Complete reuses the spec’s build attempt and stable plan ID. It never overwrites an earlier archive or allocates another attempt during recovery.

Resume interrupted completion

Run Complete again if closeout stopped during archival, commit, or landing. It checks the archive and Git evidence before requiring a live spec, identifies the unfinished phase, and resumes without duplicating the archive or repeating a finished commit or merge. A reset current-feature.md does not mean the closeout is finished.

Recovery preserves the reviewed spec, findings, and review receipt. Conflicting archives, missing evidence, or unrelated changes stop with a specific repair request. Older archives without recovery metadata remain readable history but cannot automatically restore a missing live spec. Commit, merge, push, and pull request approval boundaries still apply.

Landing configuration

Set git.landing in blueprint/config.json. Pull-request landing is useful for protected default branches and isolated parallel checkouts. Continuous Mode remains serial and local-only, so it ignores this setting. See Project Configuration for the schema and Working With Multiple Developers for the complete parallel workflow.

Why archive the spec

The history records what was intended, which checks defined success, and how the work was divided. It is useful project context without retaining chat transcripts.