Continuous Dev Loop

Use when the user wants a code project driven in repeated, bounded engineering rounds instead of ad-hoc task hopping.

Use This For

• Ongoing development where one verified slice should land before the next begins.
• Repositories where continuity should come from code, docs, and prior validation evidence rather than chat memory alone.
• Sessions where each round should end with a clean handoff for the next round.

V2 Core Rules

• Treat one round as exactly: development -> verification -> optimization -> planning.
• Each round must pursue exactly one slice. Do not branch into a second feature.
• Continue from the last verified repo state and explicit repo evidence first, not conversational recollection alone.
• Prefer this priority order when choosing what to continue:
  1. explicit user priority for the current turn
  2. previous round's explicit Next
  3. repo-native current-slice evidence in README, roadmap, tasklist, progress docs, or validation scripts
  4. the active mainline ladder already established for the project
• Verification is mandatory. At minimum include:
  • one build / compile / typecheck style check
  • one smallest behavior check tied directly to the slice
• For UI, control-flow, or recovery work, prefer a deterministic micro-check over a vague manual statement. If the repo has no test harness, add the smallest reproducible verification path that proves the slice.
• Optimization is local cleanup for the completed slice only. Do not smuggle in adjacent scope.
• Planning must recommend exactly one next slice.
• If a delegated coding agent stalls, first shrink the slice and retry once if realistic; otherwise close the round manually, record the blocker, and still emit the next-round handoff.
• Use codegraph or similar tools only to narrow the change surface or confirm call chains, never as a substitute for implementation or verification.

Workflow

1. Identify the current mainline. Read the repo state, recent validation evidence, and any explicit Next handoff from the previous round.

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

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

4. Verify the slice. Collect concrete evidence. Prefer repo-native commands and tests. Required minimum:

   • one compile/build/typecheck-style check
   • one minimal behavior check tied to the slice

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

6. Plan the next round. End with exactly these four sections:

   • Done: what changed this round
   • Verified: exact checks run and what they proved
   • Risks: remaining uncertainty, gaps, or blockers
   • Next: one recommended next slice only

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.

Recovery Ladder

When a round starts wobbling, recover in this order:

1. shrink the slice once
2. retry with the narrower target
3. if still blocked, close the round manually with explicit blocker evidence
4. emit one clean Next slice that resumes from the last verified state

Do not let a stuck subagent or flaky tool erase the loop.

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.

Output Contract

Use a compact round summary in this shape:

Completed

• concise description of the finished slice

Verified

• exact command or check
• exact command or check

Optimized

• any local tightening applied after verification

Next

• one slice only

If the user prefers the four planning exits exactly, preserve Done / Verified / Risks / Next in the final planning block.

Anti-Patterns

• Do not treat a broad milestone as a slice.
• Do not skip verification because the change looks obvious.
• Do not bury multiple future options under Next.
• Do not rely on chat history as the source of truth when the repository says otherwise.
• Do not use the optimization step 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.