# VERDICT: add-loop-runner

**Status: PASS**

Task delivers `scripts/loop-runner.py` -- the per-tick engine that partners with the brakes layer (task 2). The runner is the only piece that ever invokes the user's harness (subprocess to `loop.json` `harness.command`); it never inspects model capability (D8) and never auto-approves (D4 -- the orchestrator role calls `status.py --approve` itself, the runner only spawns the role).

## Requirement coverage

| Req | Status | Tests |
|-----|--------|-------|
| R1 entrypoint + clean exits | delivered | TestEntrypoint (2) |
| R2 11-step tick flow | delivered | TestTickFlow (5), TestOrchestratorOrdering (1), TestJsonOutput (1) |
| R3 daemon mode | delivered | TestDaemonMode (1) |
| R4 harness command substitution | delivered | TestHarnessSubstitution (1) |
| R5 context-floor guard (D13) | delivered | TestContextFloor (1) |
| R6 idempotence / no state advance on parse failure | delivered | TestVerifierParseFailure (5) |
| R7 tests (18 total) | delivered | per-class rows above |
| R8 out-of-scope items deferred | delivered | (none in code; docs note deferral) |

Tests: 18 new. Full suite: **328 passed** (was 310 + 18 new). No regressions.

## Defense against the five loop deaths -- runtime enforcement

- **drift** -> runner sees not-ok via `--check-gate` and SKIPs (`drift_detected` reason).
- **runaway** -> runner's iteration_count increments only after gate passes; next tick's `--check-gate` halts at `iterations_exhausted`.
- **bad verifier** -> score appended to history; next `--check-gate` halts `verifier_failed` when score plateaus. Parse-failure halts immediately. Idempotent (no state advance).
- **resource burn** -> `--check-gate` halts `budget_exhausted`; runner never invokes the harness before then.
- **undetected halt** -> runner SKIPs on any not-ok gate; tick log records SKIP with reason; `--audit` Cat-6 surfaces the halt across all loops.

## Agnosticism preserved

- **Harness-agnostic**: `harness.command` is a JSON list; any subprocess-capable harness works. Default `opencode run` is only a default; the user can swap it for `claudia run`, `claude --prompt-file`, a custom shell wrapper, or an SSH-remote harness command.
- **OS-agnostic**: `loop-runner.py --mode tick` is pure Python; works on Linux, macOS, Windows. `--mode daemon` is the portable fallback for CI containers without cron/launchd/schtasks.
- **Model-agnostic**: runner never inspects model size/provider. It only checks hardware context (`vram_detect.py --loop-mode --json -- loop_mode_eligible`). The 16k floor (D13) is enforced by the runner, not the gate, because available context is hardware state (per-tick), not loop state (cached).

## Doc impact landed

- `AGENTS.md` "Loop runner" bullet under State Enforcement -- Loops (v1).
- `README.md` loop-runner one-liner.
- `CHANGELOG.md` `[unreleased]` entry for `add-loop-runner`.

No code-doc mismatches.

## Hardening items deferred (tracked in BUG_REPORT + ADVERSARIAL_BUG_REPORT)

1. fcntl lock on `.state.loop` (A2/A7 TOCTOU; same item as `add-status-brakes` A6) -> v1.1.
2. `parse_verdict` score clamp + `pass` string coercion (O6 + A6) -> v1.1.
3. `outputs.retention` in `loop.json` (O5) -> v1.1.

All three are explicit follow-ups; none block this task.

## Resolution

**PASS -- proceed to `complete`.** Task 3 is the runtime half of the loop v1 foundation. With task 2 (brakes) + task 3 (runner) both shipped, the framework can run a single tick end-to-end against any configured harness. Remaining tasks (4 goal-mode, 5 blast-radius-scheduler, 6 templates-onboarding, 7 self-improvement-loop) add work sources, worktree plumbing, usable templates + prompts, and the default-on self-improvement loop. Tasks 8 and 9 are infrastructure cleanup.