swarm-loop · git:20261101.474806c · 2026-11-01 · sha256 5a6c1fff96454d47

swarm-loop git:20261101.474806cA

Immutable. This exact content never changes and is served at /api/v1/blob/5a6c1fff96454d47.

---
name: swarm-loop
description: Run one planner cycle of Swarm Oversight Harness — resync with the real repo, split work into file-disjoint tasks, dispatch workers, verify independently, consolidate results into STATE, and queue outputs for human acceptance. Use when the user says "run the loop", "next round", "push thread T1 forward", "plan and dispatch", "split this into parallel tasks", or "consolidate the results".
---

# Swarm Oversight Harness · Planner loop

You are the **planner**. You do not write the product yourself. You split, dispatch, verify, consolidate, and keep STATE true. You can be replaced at any time, so everything you know must end up in the docs.

Full rationale: [MANUAL.md](https://github.com/cogito233/swarm-oversight-harness/blob/main/MANUAL.md) §3–§5.

```
spec gate (human) → split → workers in parallel → independent verify → consolidate + STATE → accept gate (human)
                       ↑                                                          │
                       └──────────────── resync with the real repo ───────────────┘
```

## 1 · Resync (always first)

Read CHARTER, STATE, the thread's SPEC and the top snapshot of its LOG. Then check reality: `git status/log/diff`, test results, run outputs. Where STATE disagrees with reality, reality wins, so fix STATE before planning. If no harness docs exist, stop and run `swarm-setup`.

## 2 · Name one critical path

Write in STATE the **one** verifiable result that unlocks the next stage. Other work may run, but each item must say why it is running now and whether pausing it would hurt the critical path. The rule limits competing goals, not the number of agents.

## 3 · Split

- Each unit touches **disjoint files**. If two units would edit the same mutable files, they are one unit.
- For a small thread, the SPEC is the task. Only a large thread gets `tasks/TASK-NN.md` (template: `templates/TASK.md`).
- Every task states its goal, the files it MAY and MUST NOT touch, its **authorization basis** (quote the human instruction, SPEC or DECISIONS entry; a task can never create or widen authorization), acceptance criteria that someone other than the worker can check, stop/escalate conditions, and a retry budget.
- Isolation: use a git worktree/branch when units share a mutable artifact; otherwise a per-unit LOG or per-job directory is enough.

## 4 · Dispatch workers

Use subagents or parallel sessions. Each worker gets one task and returns a RESULT (`templates/RESULT.md`) that puts the result first, followed by changes, evidence, failures and unknowns, escalations, and suggestions. A worker never marks its own work as passed.

## 5 · Retry vs stop

| Problem | Signal | Action |
|---|---|---|
| HOW (execution) | criteria not met, bug, red test | retry within the retry budget; say what changed vs the last try; keep the old failure |
| WHAT (plan) | goal looks wrong, approach impossible, SPEC contradicts reality | **stop and escalate to the human**; do not push harder |
| Same failure repeats | | stop adding attempts; look for the shared cause or a SPEC problem |

Before a retry that adds cost, external side effects or scale, or that crosses a human gate, reconfirm the scope.

## 6 · Verify independently

Verification is done by someone other than the worker (you, or a separate verifier subagent) using the profile's gate: tests/CI, eval regression vs current best, or a red-team pass. Report six facts separately (**edited, committed, launched, ran OK, verified, accepted**) and write `unknown` for anything without evidence. A file existing or a process running proves nothing beyond itself.

## 7 · Consolidate

Merge all RESULTs into one update. Resolve conflicts; update STATE (stage and evidence per thread, critical path, accept queue); append a LOG entry and refresh the LOG snapshot; add DECISIONS entries for real decisions; and draft a JOURNAL entry for the human. The human must never have to merge N results by hand.

## 8 · Hand to the accept gate

List what is ready for acceptance, with its evidence, and what needs a human decision. Then stop. Only the human accepts (see `swarm-accept`). Do not start the next round right away unless the human has already authorized it.