--- name: loop-engineering description: Use when a repeatable task must become a bounded Trigger -> Execute -> Verify -> State loop, scheduled automation, goal agent, or metric-driven research cycle. metadata: version: "8.1.0" updated: "2026-08-18" profile: "loop" assumes: "The task has inspectable state, a finite budget, and at least one verifier independent of the builder's opinion." conflicts_with: "Unbounded retries, self-certification, silent external mutation, or loops whose state cannot be recovered." --- # Loop Engineering A repeatable task with inspectable state, finite budgets, permissions, and an independent verifier. A validated Trigger -> Execute -> Verify -> State contract plus resumable run receipts. The declared metric or stop condition is supported by fresh validator and verifier evidence. Dependency-graph orchestration, unbounded autonomy, or self-certified completion. Build loops only when repeated execution creates evidence. Every loop needs admission, a validated contract, durable state, independent evaluation, bounded retries, stop/recovery rules, and a final receipt. ## Usage Template Provide: objective, trigger, scope/non-goals, inputs, state/artifact paths, metric, verifier, permissions, budgets, stop condition, recovery, and write-back. See `references/ci-repair-loop-example.md` for a worked contract. ## Workflow Select one mode: - **Goal:** run until a defined end state or cap. - **Loop:** poll/iterate while eligible work exists. - **Automation:** start from an external schedule/event; the trigger is not execution evidence. - **AutoResearch:** vary experiments against an objective metric in a sandbox. Admit only if work is repeatable, outputs are inspectable, a verifier exists, failures are recoverable, and autonomy is worth the orchestration/review cost. Otherwise use a one-shot workflow. Use `graph-engineering` instead when explicit data dependencies, independent branches, typed joins, or node-local recovery create measurable value. A Graph node may use this Loop contract for local repetition; Graph width does not replace finite Loop depth. Classify unknowns as known, probeable, testable, or blocked. Missing objective, verifier, permission boundary, budget, or recovery is `NEEDS_INPUT`; do not infer these controls from intent. Unknown implementation details may be resolved inside the loop only when the probe is bounded and reversible. Write this contract before acting: ```text Objective: Mode: Goal | Loop | Automation | AutoResearch Trigger: Scope: Non-goals: Owner: Inputs: Artifacts path: State path: Work clock: Success metric: Evidence: Verifier: Topology: single-agent | maker-checker | manager-workers Max iterations: Time limit: Budget: Review budget: Stop condition: Write-back: Permission boundary: Recovery: ``` Validate it with `scripts/validate_loop_contract.py --strict`. Then iterate: 1. **Observe:** load durable state, fresh environment evidence, budgets, and last error. 2. **Orient:** update one hypothesis; choose the smallest action that can change the metric. 3. **Decide:** check scope, permissions, expected evidence, and rollback. 4. **Act:** execute one bounded action and capture artifact/diff/receipt. 5. **Verify:** use a deterministic check or independent checker; compare metric and guardrails. 6. **State:** append diagnosis, action, evidence, delta, budget, and next decision atomically. 7. **Stop/continue:** stop on success, cap, permission boundary, regression, repeated signature, or no useful work. Normalize the model/runtime termination signal after every action. `complete` still requires the declared verifier; `tool_request` returns proposed arguments to the host permission gate; `checkpoint/truncation` persists state before any continuation; refusal, error, or unknown escalates. Never infer completion from fluent prose or from the word "stop" alone. For maintenance and queue loops, declare an allowed `NO_OP` outcome and its eligibility query. A quiet iteration is successful only when the query proves there was no eligible work, output count is within policy, and no side effect occurred. Use `single-agent` by default, `maker-checker` for ambiguous/high-risk evaluation, and `manager-workers` only for genuinely independent work with an explicit integration gate. If a validated Graph owns the dependency topology, this skill owns only the bounded retry behavior inside its declared `loop` nodes. The verifier must test the declared result rather than reward activity. Check evidence freshness, metric movement, guardrails, scope, and state replay. For external or consequential actions, require approval and verified rollback before crossing the boundary. `max_attempts` equals the contract's finite max iterations. Retry only after a named diagnosis and a changed input, tool, scope, or strategy. Stop on the same failure signature twice, metric regression, exhausted review budget, or `NO_PROGRESS`. Persist `{run_id, status, attempt, budget, evidence, unknowns, last_error, next_action}` plus contract version, trigger receipt, hypothesis, action, normalized termination reason, artifact/diff, metric/guardrail delta, permissions, output count, no-op receipt, work clock, and recovery point. Append iterations; write current state atomically. ## Failure Protocol - `NEEDS_INPUT`: a mandatory contract field is absent; do not start. - `BLOCKED_PERMISSION`: the next action crosses authority; checkpoint and request approval. - `VERIFY_FAILED`: result or guardrail fails; rollback/regroup before another attempt. - `NO_PROGRESS`: the same signature repeats or the metric is unchanged after a changed attempt. - `BUDGET_STOP`: any iteration, time, tool, cost, or review cap fires. `max_attempts` is always finite. ## Output Contract Return `status`, `result` (metric/end-state decision), `evidence` (validator and iteration receipts), `unknowns`, and `next_action` (stop, retry, approval, recovery, or handoff). ## Edge Cases - A scheduled job fired but produced no run receipt: status is triggered, not completed; inspect executor state. - The model ends because its context or token budget is exhausted: checkpoint and return `BUDGET_STOP` or resume from state; do not label truncation success. - A queue poll returns zero items: accept `NO_OP` only after the declared query and side-effect check pass. - The metric improves while a safety guardrail regresses: rollback and return `VERIFY_FAILED`; never optimize the headline metric alone. ## Success Metrics - The strict validator passes before execution. - Every iteration changes evidence, state, or diagnosis within finite budgets. - A fresh verifier supports the final status and residual risk. ## Quality Gates - [ ] Trigger, owner, topology, budgets, stop, recovery, and write-back are explicit. - [ ] Builder opinion is not the only verifier. - [ ] Termination classes and any legal no-op have host-owned routing and evidence. - [ ] State replay recovers the next decision losslessly. - [ ] External mutation requires approval and rollback.