Implement

Before implementation

current-feature.md must contain a real feature, fix, or rollback spec. Implement refuses to improvise from the placeholder because scope, proof, and exclusions would be undefined.

The step loop

For each unchecked build step, implement:

1. Changes only what that step requires.
2. Runs the narrowest useful focused check while iterating.
3. Reviews the diff for contract coverage, authorization, error handling, scope, and unrelated changes.
4. Marks the step complete only after its code and focused check pass.
5. Presents evidence at the configured review gate.

With the new-project default, workflow.stepReview: "feature", Implement moves through the verified small steps without stopping for approval after each one. It presents one complete feature-level review packet at the end and does not create step checkpoint commits before that review. It normally runs the full documented Verify command once after all steps, unless an earlier full gate is required before later work can safely continue.

With workflow.stepReview: "every", Implement pauses after each step for your approval. If workflow.checkpointCommits is also enabled, it then offers the optional checkpoint prompt. Setting only stepReview to every restores the approval pauses, not the checkpoint prompts. Use every plus enabled to match the previous workflow exactly.

Proportionality check

Every new abstraction, dependency, service, configuration surface, compatibility layer, or security mechanism must trace to the approved spec or an established repository requirement. Implement prefers existing code, the standard library, native platform features, and installed dependencies. Before final verification it runs a proportionality pass that removes speculative machinery the work added, without weakening real trust-boundary validation, data-loss prevention, accessibility, or configured verification. If the simplest complete implementation conflicts with the spec, Implement stops and revises the spec instead of silently building a larger design.

Code walkthrough

After the final review packet, Implement always offers a read-only walkthrough of the completed code. This option does not depend on stepReview or checkpoint commits.

The walkthrough starts with a short map of the feature, then follows the spec’s build steps. It explains each step’s purpose, key files and symbols, important data or control flow, and non-obvious decisions. Large features are split into named sections so you can choose where to begin, and every walkthrough ends by offering a focused deep dive.

This is a code explanation, not verification. /check guide remains the separate manual product-review guide with startup instructions, clicks or commands, expected behavior, and failure signs.

Audit repairs

When the ledger at blueprint/context/findings.md holds an open P0 or P1 finding against the active work, implement appends a repair step to the spec (- [ ] Repair F-03 - title), builds it in the same reviewed loop, and marks the finding fixed. A repair never closes itself; a later audit pass re-reviews the repaired code before the finding clears. See The Findings Ledger.

When a finding came from independent review, the repair makes the old receipt stale. Implement verifies the updated work, obtains approval for a new clean checkpoint, and sends the complete new delta through independent review again. A local-spec-only revision can reuse the approved code commit after verification, with a new snapshot, request, and full fresh review.

Configured independent review

Independent review defaults to when-sensitive for the regular workflow, so authentication, authorization, payments, secrets, user data, migrations, destructive operations, external effects, and unusually broad changes receive a fresh review by default. Ordinary small work does not. The review runs after all build steps, final Verify, any required Check, and the verified spec, but before the final review packet.

The default review.independentExecution: "automatic" starts an isolated reviewer when the active adapter can prove fresh context, exact reviewer identity and model, and completion. Unsupported execution stops with the manual fresh-session handoff instead of skipping the review. A passing receipt must match the exact checkpoint before Implement continues. Commit approval remains separate from review execution.

Tracked specs are included in the checkpoint. Intentionally ignored specs use Audit’s local snapshot contract without changing Git visibility. Existing review/findings evidence alone does not require a new code checkpoint.

Branch behavior

Features use a feature/ branch, fixes use a fix/ branch, and rollbacks use a rollback/ branch. New specs record the exact branch. For an older spec, Implement deterministically combines the configured prefix with the work title in lowercase kebab-case. It stops when the type or title is ambiguous. The completed work remains on that branch until /complete handles archival and merge approval.

Rollback safeguard

For a Type: Rollback spec, implement verifies that the archived feature still maps to the exact approved commit and parent. It applies only that commit’s product diff in reverse with three-way conflict detection. Blueprint plans, context, history, adapters, agent instructions, and prototypes are excluded.

Implement shows the staged reverse diff and stops if a protected path changed or a later dependency causes a conflict. It never substitutes a whole-commit revert, broad checkout, stash, or reset for the reviewed rollback plan.

Testing gate

If AGENTS.md declares a Verify command, implement runs that exact recipe once as the final automated gate. It can use focused tests while building, but they do not replace or weaken Verify.

When Verify is absent and AGENTS.md declares a test command, logic-bearing steps must include focused tests and the suite must pass. UI work uses build output and browser evidence instead of brittle component tests.

With verification.logicTests: "required", logic work stops and points to /tests when no runner is configured. With verification.uiEvidence: "required", a UI done-when cannot pass from build output alone. Implement captures the configured browser evidence or asks you to start the required server.

Try It Now handoff

After final Verify and any required Check pass, Implement applies the configured qualityGates.regular.tryGuide policy. The default when-testable policy asks Check guide for one safe, meaningful direct observation and places the complete ## Try it now section in the final review packet.

The proof gives the smallest useful command or interaction, the exact expected result when practical, and the narrow behavior that result demonstrates. It does not replace automated tests, Verify, Check, independent review, or user acceptance. When no direct path exists, Implement says the guide was skipped instead of inventing instructions.

What it never does

Implement does not silently broaden scope, hide a failing check, merge, push, deploy, publish, or send anything. A rollback also cannot cascade into another completed feature without a new plan and approval.