Files
automaton/tasks/complete/add-loop-runner/VERDICT.md
T
Lap Tran 4a2301b077
CI / build (push) Has been cancelled
Archive completed tasks, add cleanup commands, self-documenting dashboard UI
- Archive 79 completed framework-dev tasks from tasks/ -> tasks/complete/
- status.py: add --cleanup-done and --install-cleanup-schedule commands
- Add scripts/automaton-cleanup.sh for periodic task archiving
- Dashboard: rename 'Background' tab -> 'Agent', 'Cleanup' agent -> 'Completed Task Archiver', remove redundant group headers and pill badges, dim inactive agent placeholders
- .rules.md: add Self-Documenting UI Names rule
- New tests: test_cleanup_done.py, expanded test_app.py and test_task.py
2026-06-24 22:43:33 -04:00

3.7 KiB

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.