Endless

Endless — the continuous work loop

Overview

A loop that never has to be told what to do next. roadmap decides what, successor decides who, and this skill decides whether to keep going, hand off, or fan out — at every checkpoint, from an observable predicate rather than from whatever the context window still holds.

Core principle: an iteration ends at a checkpoint, not at a task. A finished task with nothing decided after it is where autonomy dies quietly — the session idles, the branch sits unpushed, and the next roadmap item waits for a human. Every checkpoint in this skill forces one of three named continuations. There is no fourth, and "stop" is not one of them unless a human is owed something.

Rigid skill. The checkpoint decision is not a judgment call; the predicates below are.

When to use

Not for: a single task with a defined end (do it), or a loop over work that shares mutable state — parallel sessions on one checkout corrupt each other's index (ADR-0054).

The loop

Ten phases. The skill for each is in the phase table (autonomous-loop-standard.md § Phase → skill, rows 0–22); the commands are in /autoloop. Neither is restated here — a third copy of a table is a third thing to drift, which is what audit F6/F7 found.

arm posture → track → pick → gate → build → verify → land → capture → CHECKPOINT → continue
     ↑                                                                                  │
     └──────────────────────────────────────────────────────────────────────────────────┘

Phase 8 has a second half that only a loop has: an incident becomes a guard. Anything in the iteration that should not have happened goes through oops — root cause, a mechanical guard, one row in MISTAKES.md; a repo-state predicate hands off to mistake-to-gate (ADR-0057). A loop that captures features and drops its own mistakes re-makes them on a schedule.

Checkpoint semantics

A checkpoint is a defined state, not a feeling of being finished. Exactly three reach one:

blocked is not a roadmap status. The engine's statuses are proposed, ready, in-progress, done, dropped, and --status is a fixed choice list — so the command this row prescribed for most of its life, roadmap set RM-XXXX --status blocked, could not run at all. Blockedness is computed, from an unmet deps edge (the graph's own arithmetic) or from an escalate record in a work-loop ledger (a hard external blocker). gauntlet frontier reports the two apart and never sums them: collapsing them is how a rate limit gets reported as a dependency and waited on forever.

Not checkpoints. In-scope work left undone by choice; a plan written but not executed; a branch green but unpushed; "this deserves its own session later". Each of those is the loop handing work back, which CLAUDE.md item 3 forbids in the same words whether a human is watching or not.

The continuation decision

At a checkpoint, run the predicates in order and take the first that fires.

Spend and depth are different quantities, and the burn predicate is first because depth cannot see it. A session sitting at a quarter of its ceiling and re-reading that quarter a thousand times never trips the context predicate. Measured over 29 days: 48 sessions — the top 1% — accounted for 69.5% of all successor cache-read, and the heaviest ran 853 turns at ~239K prefix (about 24% of a 1M ceiling, so the context row never fired once) for $159.61. The median successor session cost about a cent. Relaying is not a tax on the loop; a successor restarts at a fraction of that prefix and does the same work the 853rd turn was doing at 239K.

The starting figure is deliberately not stated. Measured first-turn prefixes are bimodal — a tight cluster around 7K and a second around 65–75K — and the obvious single number to quote, first-turn cache_read, is wrong by construction: on turn one most of the prefix is written to cache, not read from it, so that field understates the real prefix by roughly half. The predicate does not depend on the number, and a figure this easy to misread does not belong in a rule.

The meter reports and never kills: the continuation is /relay, which preserves the work. Run session-burn.sh --json for the machine-readable form, --threshold 0 to disable when a run has a sanctioned reason to be expensive — and say what the reason was.

Layer width alone is not the predicate. Two items in one layer that touch the same files are one worker's work, not two: the graph knows about dependencies, not about collisions. Diff the surfaces before fanning out — two sessions on one checkout is ADR-0054's failure, and a fan-out that lands conflicts costs more than the serial run it replaced.

Coordinator duties are not optional. Fanning out converts this session from a builder into an integrator: reserve every ADR/DEC/RM id up front, monitor two signals (session state and branch movement), scope-diff each branch against its declared authorization, gate the merged result, and tear the worktrees down. successor owns all five; skipping teardown leaves Layer 1F's concurrency guard armed against the main checkout.

Pacing, when the loop self-schedules

The harness re-invokes on completion of the work it tracks, so polling is waste. Schedule a long fallback (1200 s+) that only fires if the tracked work hangs or never notifies. Poll on a short interval only for state the harness cannot see — a remote queue, an external run — and then match the interval to how fast that state actually changes.

Red flags

Quick reference