loop

Compound-Engineering Loop Protocol

MODE: LOOP runs an objective end to end as a series of gated phases, then loops to compound improvements until the objective is met or a stop condition fires. Each cycle reuses the existing mode skills (brainstorm, plan, critic-gate, execute, phase-wrap) and ends with a learning-capture step so the next cycle is cheaper — that is what makes the loop compounding rather than merely repeating.

This is a real implementation workflow: it delegates to the coder, declares scope, and mutates source code through the normal EXECUTE path. It is distinct from full-auto (a critic gate via the critic_oversight agent that intercepts phase completions and high-risk actions for review — full-auto never plans, delegates, or executes; the architect retains ALL delegation duty) and turbo (parallel lanes within a single phase). LOOP is a user-initiated, gated, sequential, compounding workflow.

The two design rules that everything below serves:

1. Separate the generator from the verifier. The context that writes a change must never be the only context that approves it. Implementation, independent review, and critic challenge live in separate delegated contexts. Review is report-only; a distinct fix step applies changes.
2. Stop on positive evidence or a budget — never on vibes. Every phase has an entry gate and an exit gate backed by concrete evidence, and the loop has layered stop conditions so it can never run away.

---

Step 0 — Parse Header

Parse the [MODE: LOOP ...] header to extract:

• objective: the goal text after the header (the WHAT to achieve). Empty only when resume=true.
• max_cycles: integer 1..5 (default 3) — hard cap on outer improvement cycles.
• autonomy: auto (default) or checkpoint.
  • auto: proceed across gates without prompting, but still enforce every hard stop condition and the mandatory review/critic gates.
  • checkpoint: pause at each phase gate and wait for explicit user approval before continuing.
• depth: standard (default) or exhaustive (wider exploration in BRAINSTORM and PLAN: more candidate approaches, deeper localization).
• resume: true | false. When true, resume the existing run from durable state instead of starting a new objective.