loop-implement

loop-implement executes an approved loop-plan plan from its next incomplete phase to the end. For each phase it writes the tests first, implements the change, runs the acceptance commands, commits once, and records the result in the plan. It runs review-impl at the checkpoints the plan names.

When to use it

A loop-plan plan exists, its Plan Review reads APPROVE with a source, and you want the work carried out.
You are resuming a plan that stopped part way. It continues from the first incomplete phase whose dependencies are complete.

/loop-implement

$loop-implement

Add the plan path when you have more than one plan, for example /loop-implement .cross-review/plans/move-tags-to-join-table-plan.md. A plan outside .cross-review/plans/ is used only when you give its path.

What it works out by itself

The plan. It runs the plans command and takes the one plan with format: "loop-plan" and an incomplete phase. A plain markdown file in that folder is never run as a plan.
Whether the plan may run. Plan Review must read APPROVE with its source: review-plan <session id> or user <date>. pending, REVISE, or an approval without a source stops it. If the plan was edited materially after approval, it asks you.
The state of the repository. It reads the repository instructions, git status, the diffs and the recent commits. It keeps unrelated changes you made and never resets or reverts them.

Round by round

Each phase follows the same loop:

Re-read the phase. It checks only the paths and symbols the phase touches.
Docs and tests first. It updates the owning documentation, writes or strengthens the tests, and runs them to see them fail. The red result goes in one line.
Implement. It writes the production code through the real integration path, minimal and consistent with the project.
Verify. It runs each acceptance criterion’s narrow command, then the phase gates.
Inspect the diff. Only the phase’s files are staged, with no secrets and no leftovers of renamed names.
Commit and record. One commit with the planned message. The phase’s met criteria are ticked - [x], and a progress line goes in Progress Log. The plan is staged only when git does not ignore it (see Plans).
Checkpoint. When the plan lists this phase as a review checkpoint, it runs review-impl, with the model the plan names if any. The review decides how findings are handled.

If the reviewer cannot run (not installed, not logged in, quota, repeated errors), it self-reviews the checkpoint against the same criteria, records self-review (reviewer unavailable: <reason>) in the progress line, and continues. A self-review is never recorded as a review approval. At the next checkpoint it tries the reviewer again on the whole diff since the last real review.

Gate discipline

A gate that cannot run is a problem to fix (install, build, or start what the plan names), not a step to skip.
A failure that also happens without the change is a baseline failure. It is recorded and the work continues. Only new failures block.
A criterion that is not fully met is reported as not done with the reason.
When a migration or other state-changing step fails part way, it follows the plan’s retry or rollback path. Without one, it stops and asks.

Changing the plan

It does not add technology, dependencies, limits or mechanisms the plan does not contain. When it finds a real problem in the plan, it proposes one change as a decision with context, options, a recommendation and what happens if you agree. If you agree, it records a dated Decision: line in Progress Log, updates the sections the change touches, and does not rerun the plan review.

Finalization

When the last phase is done:

It runs every Global Gates command once on the final commit.
It runs the end-to-end scenario from Completion Criteria and compares the output with the expected output.
It audits the cumulative diff and history for problems that span phases.
It runs the final checkpoint with review-impl on the whole diff.
It fixes any defects with a regression test first, then reruns the affected gates.
It updates Completion Criteria in the final commit.

What it stops for

It stops only for a decision you must make, missing credentials or infrastructure, requirements that cannot both be met, or an irreversible action the plan does not authorize. A review stalemate is your decision. It asks one question at a time.

What you can say in chat

Your latest explicit instruction overrides the procedure. You can:

You say	Effect
“Skip the review at phase 3”	The checkpoint is skipped and the progress line records your instruction
“Accept the review result”	The current result is recorded as approved by you, not by the reviewer
“Change the order” or “do phase 4 first”	It follows the order you give, if the dependencies allow it
“Use model X for the checkpoint”	The checkpoint review runs with that model
“Stop here”	It stops after the current step and reports the state

Example

Project: orchard-api. The approved plan add-webhook-retries-plan.md has three phases and checkpoints after phases 1 and 3.

Phase 1 (retry queue storage) runs. Its tests fail first, then pass. The commit is feat(webhooks): store delivery attempts, and the checkpoint review runs with review-impl. The reviewer finds one issue, a missing index on the attempts table. It is fixed with a regression test in the same phase.
Phase 2 (backoff schedule) runs without a checkpoint.
Phase 3 (dead-letter handling) runs. The reviewer is not logged in, so the checkpoint is self-reviewed and the progress line says so. The final checkpoint runs again on the whole diff once the reviewer works.

The report lists the commits, the gate results with baseline failures, the review outcomes including the self-review, the criteria marked not done, and remaining risks.

See also loop-plan for writing the plan and review-impl for how checkpoints are reviewed.