Complete tasks 3-7: harden verdict parsing, outputs retention, base branch, linux schedule parity, claim loop task

AGENTS.md

@@ -96,6 +96,19 @@ The framework enforces the state machine computationally:
 - **FORBIDDEN actions in prompts**: Each phase prompt explicitly lists what agents cannot do
 - **Untracked tasks**: Tasks without `.state` files are UNTRACKED. All commands (`--transition`, `--can-edit`, `--task`) refuse to operate on them. Run `--upgrade` to bootstrap `.state` files.
 
+## State Enforcement — Loops (v1)
+
+Loops add a parallel concept: each loop has a `.state.loop` JSON file at `{project}/.automaton/loops/<name>/.state.loop` (framework-internal: `~/.automaton/loops/<name>/`). It is the single source of truth for loop runtime state.
+
+- **`.state.loop`**: `status ∈ {running, halted, paused, complete}`, `halt_reason ∈ {iterations_exhausted, budget_exhausted, verifier_failed, drift_detected, human_intervention}`, `iteration_count`, `last_tick_at`, `score_history`, `current_task`, `worktree_path`.
+- **`--create-loop NAME [--from-template T]`**: The only valid way to bootstrap a loop dir + `.state.loop` + `loop.json`.
+- **`--check-gate NAME`**: Runs all 6 brake gates (status, iterations, budget, task phase, worktree drift, score plateau). First failure halts the loop and best-effort disables the OS schedule unit.
+- **`--approve --loop NAME`**: The only way to clear a halt. Increments `resumed_count`. No auto-approve path in v1.
+- **`--transition`**: Refuses to transition any task owned by a HALTED loop until `--approve --loop` clears the halt.
+- **Untracked loops**: Loop dirs without `.state.loop` are UNTRACKED. All `--loop` commands refuse; `--audit` flags them.
+- **`.state.lock` (v1.1)**: Cross-process file lock serializes read-modify-write cycles on `.state.loop`. POSIX `fcntl.flock`, Windows `msvcrt.locking`. Per-loop granularity (`<loop_path>/.state.lock`), blocking acquire, no timeout in v1.1. The runner holds the lock across the entire tick (gate → harness → state write). `--pause-loop`, `--resume-loop`, `--approve --loop`, `--check-gate` in status.py each acquire the lock around their read-modify-write blocks. `--create-loop` is unwrapped. The runner sets `$AUTOMATON_NO_LOOP_LOCK=1` in the `--check-gate` subprocess env ONLY (avoids self-deadlock on the parent's held flock); harness subprocesses do NOT inherit the env var. See `design/loops/technical.md` §7 "Lock serialization".
+- **Loop runner**: `scripts/loop-runner.py --mode tick --loop <name> --project <p>` is the per-tick engine. Called by the `automaton-loop-tick.{sh,bat}` stub that `--install-schedule` generates. It calls `--check-gate` first; any non-ok gate exits 0 (clean scheduler exit). Also supports `--mode daemon` (Python sleep loop) and `--json` machine-readable output. See `design/loops/technical.md` §7 for the 11-step tick flow.
+
 ## Harness Integration
 
 `status.py --can-edit` provides a pre-edit gate that any agent harness can call before allowing file modifications. This is the primary enforcement layer. See `contracts/harness-integration.md` for the full integration contract.
@@ -111,6 +124,7 @@ Modes:
 - `--can-edit --project {p} --file {path}` — Same, plus file scope check
 - `--can-edit --project {p} --task {t}` — Is this specific task in an edit-allowed phase?
 - `--can-edit --project {p} --task {t} --file {path}` — Same, plus file scope check
+- `--can-edit --project {p} --loop {name} [--loop-worktree] --file {path}` — Loop worktree scope check: is the file inside this loop's declared `blast_radius.file_scope`? `--loop-worktree` treats the path as worktree-relative; otherwise the absolute path must be inside the project/framework root.
 - Add `--json` for machine-readable output
 
 ## Adding or Updating Prompts