Continuous Dev Loop

单-slice 持续开发循环 V4：协议化交接、仓库态续跑、自恢复停机。

Use when the user wants a code project advanced in repeated, bounded engineering rounds that can be continued by a coding agent or background supervisor without relying on chat memory alone.

Use This For

• Ongoing development where one verified slice should land before the next begins.
• Repositories where continuity should come from repo-native state, not conversational recollection.
• Sessions where each round should end with a machine-readable continuation contract.
• Workflows that should keep moving round after round until a real stop condition is hit.

V4 Core Model

Treat one round as exactly:

development -> verification -> optimization -> handoff

Each round must:

• pursue exactly one slice
• verify that slice concretely
• leave one and only one next slice
• emit a supervisor-readable footer
• write continuity into the repository or supervisor state, not only the chat reply

Core Rules

• Each round must pursue exactly one slice. Do not branch into a second feature.
• Continue from explicit repo evidence first, not memory of the conversation alone.
• Prefer this priority order when choosing what to continue:
  1. explicit user priority for the current turn
  2. previous round's machine-readable NEXT_SLICE
  3. repo-native current-slice evidence in progress docs, tasklists, roadmap files, loop state files, or validation scripts
  4. the active mainline ladder already established for the project
• If the repo exposes a dedicated continuation file such as LOOP_STATE.md, PROGRESS_LOG.md, .claude-orchestrator/current-next.txt, or equivalent, treat it as first-class evidence.
• Verification is mandatory. Every successful round must include:
  • one build / compile / typecheck style check
  • one smallest behavior check tied directly to the slice
• If the repo lacks a slice-specific proof path, adding the smallest deterministic proof helper is allowed inside the same slice.
• Optimization is local cleanup for the completed slice only. Do not smuggle in adjacent scope.
• Every successful round must leave exactly one next slice.
• Every round must end with an explicit loop status enum, not just prose.
• If automatic continuation is active, do not wait for a fresh user prompt between successful rounds.

Round Workflow

1. Identify the current mainline. Read the last verified repo state, any machine-readable continuation artifact, and the strongest explicit repo evidence.

2. Choose one slice. Define the smallest meaningful increment that advances the mainline. Refuse implicit multi-slice expansion.

3. Develop the slice. Make only the changes needed to complete that increment.

4. Verify the slice. Collect concrete evidence. Minimum required:

   • one build/typecheck-style command
   • one deterministic slice-specific proof

5. Optimize the slice. Tighten local naming, comments, edge handling, or structure only where it improves the completed slice.

6. Write continuity. Update the repo-native continuation surface when one exists. Examples:

   • docs/LOOP_STATE.md
   • docs/PROGRESS_LOG.md
   • .claude-orchestrator/current-next.txt
   • tasklist or roadmap files that already act as the project's state surface

7. Emit the handoff. End with a human-readable summary plus the required machine-readable footer.

Continuation Protocol

Treat the next slice as a contract, not a suggestion.

Every successful round must produce:

• exactly one NEXT_SLICE
• exactly one LOOP_STATUS
• exactly one VERIFY_BUILD
• exactly one VERIFY_SLICE
• exactly one REPO_STATE
• exactly one STOP_REASON

Allowed LOOP_STATUS values:

• continue
• blocked
• milestone_reached
• needs_human
• repo_broken

Interpretation:

• continue: the supervisor should immediately start the next round from NEXT_SLICE
• blocked: the round cannot continue automatically until the blocker is addressed
• milestone_reached: stop cleanly because the intended checkpoint was hit
• needs_human: stop because a human decision or permission is required
• repo_broken: stop because repository state is not trustworthy enough to continue

Blocker Taxonomy

If a round does not end in continue, classify the blocker into exactly one bucket:

• repo_state
• auth
• tool_hang
• test_gap
• unclear_spec
• external_dependency

A blocked round must provide:

• blocker bucket
• concrete evidence
• last verified state
• one clean RESTART_SLICE

Recovery Ladder

When a round wobbles, recover in this order:

1. shrink the slice once
2. retry with the narrower target
3. if still blocked, stop the chain cleanly
4. emit blocker evidence plus one RESTART_SLICE

Shrink once means meaningfully reducing scope, not retrying the same broad task with different wording.

Git / Repo Rules

If the workflow is intended to run unattended, treat repo hygiene as part of the slice contract.

• Do not call a round complete if repo state is broken.
• If the repo is expected to stay clean between rounds, say so in REPO_STATE.
• If the round completed code changes that should persist, commit them before claiming a clean continuation point when the environment allows it.
• If push is part of the repository's normal safety contract, perform it before a continue handoff when possible.
• If git state, auth, or push failure prevents safe continuation, stop with LOOP_STATUS=blocked, LOOP_STATUS=needs_human, or LOOP_STATUS=repo_broken as appropriate.

Validation Ladder

Use the smallest proof that still makes the slice credible.

• For package or infra changes: build/typecheck plus one command-level smoke check.
• For state-transition logic: add one deterministic script or focused test that exercises the failure mode directly.
• For UI slices: prefer a narrow state/logic check first, then deploy-style verification if the repo already has that path.
• When a verification helper is missing, adding one is allowed if it stays inside the same slice and directly proves the change.

Repo-Native Continuity Preference

Continuity should survive process restarts.

Prefer writing the current handoff into repo-native artifacts when the project already has a natural place for it. Good examples include:

• tasklist files
• progress logs
• loop state docs
• supervisor-owned next-slice files
• deterministic verification scripts that encode what "done" means for the current mainline

Do not create noisy state files if the project already has a clear continuity surface. Reuse the repo's existing state surface when possible.

Mainline Priority Example

When the user does not provide a new priority, continue the existing mainline before opening a fresh track.

Example ladder:

• remote control capability gaps
• operator console visibility and feedback
• safety confirmations and failure recovery
• recording and replay scaffold

Keep this as a priority ladder, not a license to touch multiple items in one round.

Human-Readable Summary

Also end each round with this compact summary shape:

Done

• what changed this round

Verified

• exact checks run and what they proved

Risks

• remaining uncertainty, gaps, or blocker notes

Next

• one next slice only

Required Machine-Readable Footer

After the human-readable summary, emit this exact footer shape:

LOOP_STATUS: <continue|blocked|milestone_reached|needs_human|repo_broken>
NEXT_SLICE: <one concrete next slice or none>
VERIFY_BUILD: <exact command or none>
VERIFY_SLICE: <exact command or none>
REPO_STATE: <clean|dirty|broken|unknown>
COMMIT_SHA: <sha-or-none>
BLOCKER_BUCKET: <repo_state|auth|tool_hang|test_gap|unclear_spec|external_dependency|none>
RESTART_SLICE: <one restart slice or none>
STOP_REASON: <reason or none>

Rules for the footer:

• NEXT_SLICE must be one concrete slice when LOOP_STATUS=continue
• NEXT_SLICE may be none only when stopping cleanly
• VERIFY_BUILD and VERIFY_SLICE must be exact commands when verification happened
• BLOCKER_BUCKET must be none on successful continuation
• RESTART_SLICE must be populated on blocked rounds
• STOP_REASON must be none when LOOP_STATUS=continue

Anti-Patterns

• Do not treat a broad milestone as a slice.
• Do not skip verification because the change looks obvious.
• Do not bury multiple options under Next or NEXT_SLICE.
• Do not rely on chat history as the source of truth when the repository says otherwise.
• Do not use optimization to start the next feature.
• Do not call a round verified if only the broad repo build passed but the slice-specific failure mode was never checked.
• Do not output only prose when the workflow is intended for automatic continuation.
• Do not stop with vague blocker text when a blocker bucket and restart slice can be given.
• Do not leave continuation state only in the terminal reply if the repository has a better continuity surface.