@robmclarty/volley 0.7.0 → 0.9.0

package/README.md

@@ -54,8 +54,9 @@ volley \
 The cap is enforced in the loop guard after each phase. Sessions are never
 killed mid-flight for cost (a builder killed mid-edit leaves the workspace
 undefined), so set the cap below your true ceiling by roughly one iteration's
-expected cost. Per-run totals land in `.volley/summary.json` and the final
-terminal summary.
+expected cost. Per-run totals land in the run's `summary.json` (see
+[Run artifacts](#run-artifacts)) and the final terminal summary. An [OpenRouter](#openrouter) seat's cost is the charge
+OpenRouter reports for each call, so the cap trips on one as on any other.
 
 ## How it works
 
@@ -80,7 +81,7 @@ prompt ──> builder (full agentic session in your workspace)
 - **Critic** is read-only (`Read`, `Grep`, `Glob` — no write path at all) and
   returns a schema-validated `{ verdict, feedback, unmet_criteria }`. It is told
   which files the builder changed, so it reviews a change rather than a tree.
-  The harness writes `.volley/feedback.md` and `.volley/verdict`; the critic
+  The harness writes the run's `feedback.md` and `verdict`; the critic
   cannot get them wrong.
 
 Each iteration is a fresh session — no context carries over except through the
@@ -94,7 +95,7 @@ Under the hood the loop is one [fascicle](https://www.npmjs.com/package/fascicle
 composition in [`src/flow.ts`](./src/flow.ts), and fascicle's `describe.diagram`
 draws it straight from the code. It shows what the sketch above leaves out: the
 branch that skips verification once the builder alone crosses the cost cap, the
-critic's retry-then-tool-less fallback for local models whose streams die, and
+critic's retry-then-tool-less fallback on every provider but `claude_cli`, and
 the guard that decides when the loop stops.
 
 <!-- flow diagram: pnpm diagram -->
@@ -108,8 +109,8 @@ volley                                loop: one round per iteration, up to max_i
 │  │  └─ else  sequence
 │  │     ├─ check                     the deterministic gate: checkride, a command, or none
 │  │     └─ critique                  the read-only critic's verdict and feedback
-│  │        └─ critic                 fallback: judge without tools if a local critic's stream keeps dying
-│  │           ├─ retry               one more try after a stream death, local providers only
+│  │        └─ critic                 fallback: judge without tools if a critic on any provider but claude_cli keeps dying or runs out of steps
+│  │           ├─ retry               one more try after a stream death, on any provider but claude_cli
 │  │           │  └─ critic_tools     model call with read-only workspace tools
 │  │           └─ pipe                mark the verdict degraded
 │  │              └─ critic_toolless  model call judging from the check output and a file list
@@ -122,8 +123,10 @@ the one in the `src/flow.ts` header to what the code builds, so neither drifts.
 
 ## Install
 
-Requires Node ≥ 24, pnpm, and the [Claude Code CLI](https://docs.anthropic.com/en/docs/claude-code)
-installed and authenticated.
+Requires Node ≥ 24 and pnpm. The default seats run on the
+[Claude Code CLI](https://docs.anthropic.com/en/docs/claude-code), installed and
+authenticated; seats on [OpenRouter](#openrouter) or a
+[local model server](#local-critic) don't need it.
 
 From a checkout:
 
@@ -147,6 +150,9 @@ volley [options]
 volley --config <path>
 volley resume <run-id>
 volley matrix --builders <models> --critics <models> --config <path>
+volley critique --criteria <criteria> [--baseline <rev>] [options]
+volley acp --builder-provider <name> --builder-model <model> \
+  --critic-provider <name> --critic-model <model> [options]
 ```
 
 | Flag | Default | Description |
@@ -156,13 +162,14 @@ volley matrix --builders <models> --critics <models> --config <path>
 | `--criteria` | (required) | Acceptance criteria. Literal string or `@path`. |
 | `--check` | `auto` | `auto` (checkride if detected, else none), `none`, or a shell command. |
 | `--builder-model` | `opus` | `opus`/`sonnet`/`haiku` or a full model id. |
-| `--builder-provider` | `claude_cli` | `claude_cli`, `ollama`, or `lmstudio` (see [Local builder](#local-builder)). |
-| `--builder-url` | the provider's env var | The builder's model server base URL, for `ollama` or `lmstudio` only. Lets the builder and critic run on different machines with the same provider (see [Seats on different machines](#seats-on-different-machines)). |
-| `--builder-max-steps` | `50` | Local builder tool-loop step cap per iteration. Ignored for `claude_cli`. |
-| `--allow-unsandboxed-builder` | off | Permit a local builder to run without a sandbox (see [Local builder](#local-builder)). |
+| `--builder-provider` | `claude_cli` | `claude_cli`, `ollama`, `lmstudio`, or `openrouter` (see [Local builder](#local-builder) and [OpenRouter](#openrouter)). |
+| `--builder-url` | the provider's env var | The builder's model server base URL, for `ollama`, `lmstudio`, or `openrouter` only. Lets the builder and critic run on different machines with the same provider (see [Seats on different machines](#seats-on-different-machines)). |
+| `--builder-max-steps` | `50` | Tool-loop builder step cap per iteration. Or `VOLLEY_BUILDER_MAX_STEPS`. Ignored for `claude_cli`. |
+| `--builder-max-tool-calls` | `1` | Tool calls a tool-loop builder may make per turn; past it, fascicle runs the first ones and drops the rest. Raise it for a model and runtime that return parallel calls well. Or `VOLLEY_BUILDER_MAX_TOOL_CALLS`. Ignored for `claude_cli`. |
+| `--allow-unsandboxed-builder` | off | Permit a builder other than `claude_cli` to run without a sandbox (see [Local builder](#local-builder)). |
 | `--critic-model` | `opus` | Model for the critic. |
-| `--critic-provider` | `claude_cli` | `claude_cli`, `ollama`, or `lmstudio` (see [Local critic](#local-critic)). |
-| `--critic-url` | the provider's env var | The critic's model server base URL, for `ollama` or `lmstudio` only. |
+| `--critic-provider` | `claude_cli` | `claude_cli`, `ollama`, `lmstudio`, or `openrouter` (see [Local critic](#local-critic) and [OpenRouter](#openrouter)). |
+| `--critic-url` | the provider's env var | The critic's model server base URL, for `ollama`, `lmstudio`, or `openrouter` only. |
 | `--builder-permission-mode` | `acceptEdits` | Or `bypassPermissions` for fully trusted workspaces. |
 | `--critic` | `reviewer` | `reviewer`, `optimizer`, `researcher`, or a prompt file path. |
 | `--max-iterations` | `10` | Hard iteration cap. |
@@ -173,8 +180,9 @@ volley matrix --builders <models> --critics <models> --config <path>
 | `--gate-paths` | (built-in list) | Comma-separated globs naming the gate — tests, fixtures, check config. Replaces the defaults; see [What the builder changed](#what-the-builder-changed). |
 | `--fail-on-gate-edit` | off | Halt the run (exit 8) if the builder edits a gate path, instead of reporting it. |
 | `--sandbox-image` | `volley-sandbox:latest` | Container image for the local-builder sandbox. Or `VOLLEY_SANDBOX_IMAGE`. |
-| `--run-id` | a fresh UUID | The run's id, naming its `.volley/` state and its `volley/<id>` branch, so a harness that owns the id finds it in both. Letters, digits, `-`, and `_`, starting with a letter or digit. |
-| `--dry-run` | off | Validate config, run `checkride doctor`, probe each local seat's model endpoint, run the critic-seat canary (for a local critic), then exit. |
+| `--state-dir` | `$XDG_STATE_HOME/volley`, else `~/.local/state/volley` | The root each run keeps its state under, at `<path>/<run id>/`, never in the workspace (see [Run artifacts](#run-artifacts)). Or `state_dir` in a config file. |
+| `--run-id` | a fresh UUID | The run's id, naming its run state and its `volley/<id>` branch, so a harness that owns the id finds it in both. Letters, digits, `-`, and `_`, starting with a letter or digit. |
+| `--dry-run` | off | Validate config, run `checkride doctor`, probe each tool-loop seat's model endpoint (local or OpenRouter), run the critic-seat canary (for a local critic), then exit. |
 | `--config` | — | TypeScript config file (`VolleyConfig` default export). CLI flags override. |
 | `--json` | off | Machine mode: one summary JSON document on stdout. |
 | `--verbose` | off | Full tool inputs/outputs (truncated at 4000 chars). |
@@ -190,7 +198,7 @@ checkride.
 | Code | Meaning |
 |---|---|
 | 0 | Check passed and verdict approved. |
-| 2 | Max iterations reached without success. |
+| 2 | Max iterations reached without success; for `volley critique`, the critic asked for changes or the check failed. |
 | 3 | Builder/provider error. |
 | 4 | Check pipeline error (broken pipeline, not failing checks). |
 | 5 | Configuration error. |
@@ -223,12 +231,35 @@ export default config;
 ### Resume
 
 ```sh
-volley resume <run-id>            # in the workspace directory
-volley resume <run-id> --workspace ./my-project
+volley resume <run-id>                             # from any directory
+volley resume <run-id> --state-dir ~/volley-runs   # a run started with --state-dir
+volley resume <run-id> --workspace ./my-project    # a run an older volley kept in .volley/
 ```
 
+`resume` finds the run at `<root>/<run-id>/` under `--state-dir`, else the
+default root, from any directory, since the run's recorded config names its
+workspace. A run an older volley started keeps its state in the workspace's
+`.volley/`, and resumes there: point `--workspace` at it, or run `resume` from
+inside it. A run directory with a symbolic link in it is refused, since volley
+never writes one.
+
+**A resume on the host runs only a config this machine signed.** A resume runs
+what the run's `config.json` says, its check command and its seats included.
+So volley on the host signs each config it writes, as `config.sig`, under a
+key that stays on the machine (`$XDG_CONFIG_HOME/volley/run-key`, else
+`~/.config/volley/run-key`), and a resume on the host refuses a config whose
+signature doesn't hold (exit 5). That covers:
+
+- **A contained run's config.** Nothing is signed inside the sandbox, and the
+  builder there can rewrite its own run's config, so resume it inside its
+  container, with the same mount. Inside the container, nothing is checked.
+- **Another machine's config, an older volley's, or one you edited.** Read it,
+  then pass `--trust-config`, and the resume says which check and seats it's
+  about to run before it runs them.
+
 Continues from the last completed iteration with the saved feedback and cost
-totals. An iteration interrupted mid-phase is discarded and re-run.
+totals. An iteration interrupted mid-phase is discarded and re-run. A
+[critique](#critique-a-fixed-change) has one round and nothing to resume.
 
 ### Matrix sweep
 
@@ -261,16 +292,17 @@ local providers share one GPU, so parallel combos would thrash the model loader.
 Each run forces `--worktree --discard-worktree` for a clean per-run reset — a
 sweep wants verdicts, so each seat's effects are isolated and then thrown away,
 leaving neither a branch nor a commit behind — so the **workspace must be a git
-repository**. Every attempt's run state is written to
-`.volley-matrix/<builder>__<critic>/run-NN/summary.json`, the whole sweep to
-`.volley-matrix/matrix.json`, and one aggregate table goes to stderr:
+repository**. Each attempt keeps its run state under the state root like any
+run, and its summary, which names that state as `run_state_dir`, is copied to
+`.volley-matrix/<builder>__<critic>/run-NN/summary.json`. The whole sweep goes
+to `.volley-matrix/matrix.json`, and one aggregate table goes to stderr:
 
 ```
-builder         critic         pass  iters  wall     cost   salvage  flags  why
-──────────────  ─────────────  ────  ─────  ───────  ─────  ───────  ─────  ──────────────────
-qwen3.6:latest  qwen3:8b       3/3   1.0    403.4s   $0.00  0%       —      —
-qwen3.6:latest  gemma4:12b     2/3   1.5    512.0s   $0.00  0%       —      unmet: 2 criteria
-qwen3.6:latest  glm-4.7-flash  0/3   —      184.0s   $0.00  12%      deg    check: types, test
+builder         critic         pass  iters  wall    cost   salvage  flags       why
+──────────────  ─────────────  ────  ─────  ──────  ─────  ───────  ──────────  ──────────────────
+qwen3.6:latest  qwen3:8b       3/3   1.0    403.4s  $0.00  0%       —           —
+qwen3.6:latest  gemma4:12b     2/3   1.5    512.0s  $0.00  0%       —           unmet: 2 criteria
+qwen3.6:latest  glm-4.7-flash  0/3   —      184.0s  $0.00  12%      deg:stream  check: types, test
 ```
 
 **Why `--repeat`.** One run answers "did this pairing converge that time", and
@@ -288,7 +320,9 @@ totals rather than a mean of ratios.
 failing check slots, the criteria the critic still judged unmet, a cost cap, a
 gate edit, or the error that broke the run. `flags` carries what qualifies a
 pass rather than explaining a failure: `deg` for a degraded critic verdict,
-`gate` for a builder that edited the gate. Every attempt's full detail —
+named for what degraded it (`deg:stream` when the critic's stream kept dying,
+`deg:steps` when it ran out of steps), and `gate` for a builder that edited the
+gate. Every attempt's full detail —
 statuses, verdicts, failing slots, unmet criteria, gate edits — is in the
 `--json` aggregate and in `matrix.json`.
 
@@ -296,6 +330,48 @@ A run that does not converge is a *result*, shown in the table; the sweep exits
 0 as long as every attempt produced a summary, and nonzero only when one
 produced none at all (`status: broke`).
 
+### Critique a fixed change
+
+`volley critique` runs the check and the critic once over a change already
+made, with no builder. It's how you choose a critic: replay the same
+known-good and known-bad changes through the critic seat, across models and
+prompts, and count how many of the bad ones each critic rejects. A matrix sweep
+can't tell a critic that reads from one that approves everything, since both
+pass whenever the builder happens to be right.
+
+```sh
+volley critique --workspace ./repo --baseline <rev> \
+  --criteria "@criteria.md" \
+  --critic-provider ollama --critic-model qwen3:8b --critic reviewer
+```
+
+- **The change** is everything that differs from `--baseline`, committed or
+  not, untracked files included: the set a run reports for its builder. Without
+  `--baseline` it's HEAD, so the uncommitted and untracked edits are the
+  change. A revision that isn't a commit is a configuration error (exit 5).
+- **The critic** sees what it sees in a run: the changed paths and gate edits,
+  the check's section, and the same preset or prompt file. `--prompt` is
+  optional and only recorded, since a critic judges against `--criteria`.
+- **The state** is a one-round run's, under the state root
+  ([Run artifacts](#run-artifacts)). The summary records `mode: "critique"`
+  and no builder: `builder` is null in the iteration's archive, and so is the
+  comparison block's `builder_transport`. The archived `critic.tool_calls` says
+  how much the critic read before it judged.
+- **Exit codes**: 0 when the critic approves over a green check, 2 when it asks
+  for changes or the check is red (`status: "rejected"`), and the usual codes
+  for provider, check-pipeline, configuration, and critic errors.
+- **Flags**: the critic's seat flags, `--check`, `--critic`, `--gate-paths`,
+  `--state-dir`, `--run-id`, `--dry-run` (with the critic-seat canary),
+  `--json`, and the output flags work as they do for a run. Every flag only a
+  builder or its loop uses, from `--builder-model` and `--max-iterations` to
+  `--worktree`, `--git`, and `--fail-on-gate-edit`, is refused by name (exit
+  5), and so is `--config`, since a run's config file sets a builder.
+
+With no builder, a local critic needs no sandbox opt-in. The check still runs
+whatever the repository's check runs, though, so review an untrusted change
+with `volley critique` inside the container, its run directory mounted as a
+run's would be ([Local builder](#local-builder)).
+
 ## Local critic
 
 The critic is read-only and schema-constrained, which makes it a good fit for
@@ -325,7 +401,7 @@ Providers and their setup:
 Install the peer for your provider in the project running volley (e.g.
 `pnpm add ai-sdk-ollama@^4.3.0`); fascicle loads it lazily only when the local
 critic actually runs. The version matters. The major must satisfy fascicle's
-declared peer range (`^4` for fascicle 0.14.0, which tracks the AI SDK v7
+declared peer range (`^4` for fascicle 0.16.3, which tracks the AI SDK v7
 line), and volley declares 4.3.0 as its floor (an optional peer, so your
 package manager flags an older copy at install time). Before 4.3.0,
 ai-sdk-ollama streams a thinking model's reasoning only when the request sets
@@ -356,7 +432,14 @@ the *same* model drives the builder tool loop fine, so the defect is specific to
 the constrained-verdict path. volley no longer lets that kill a run: the critic
 phase degrades (a bounded retry, then a tool-less fallback that keeps the
 schema), marks the verdict `critic_degraded: true`, and `--dry-run` predicts the
-doomed combo up front with a critic-seat canary. Even so, prefer a critic whose
+doomed combo up front with a critic-seat canary. A critic that runs out of steps
+before its verdict (its 10-step budget spent, or its last turn a tool call) skips
+the retry, since another identical tool loop would only run out again, and goes
+straight to the tool-less pass. The record's `degrade_cause` says which happened:
+`stream_error` or `step_exhaustion`. A verdict cut off by the token limit or
+blocked by a content filter isn't degraded: it fails the critic phase (exit 6)
+with the finish reason in the message, because taking the tools away fixes
+neither. Even so, prefer a critic whose
 tool-call encoding Ollama parses cleanly — `qwen3:8b`, `gemma4:12b`, and
 `glm-4.7-flash` all pass. The full model-vs-transport write-up is in
 [`research/v3-comparison-finding.md`](./research/v3-comparison-finding.md).
@@ -371,6 +454,14 @@ tool loop per iteration (capped by `--builder-max-steps`, default 50; hitting
 the cap is treated as partial work, not an error). The produced workspace goes
 to check + critic exactly like a `claude_cli` build.
 
+A local builder makes one tool call per turn by default, since some model and
+runtime pairs return parallel calls badly. For a pair that handles them, such
+as qwen3.8 on Ollama's MLX runner, which returns several reads at once,
+`--builder-max-tool-calls <n>` lets each turn carry up to `n`. fascicle runs a
+turn's calls in order, so a read can't race an edit, and the builder's prompt
+then asks it to batch independent reads but make one change or command per
+turn.
+
 ```sh
 volley \
   --prompt "@task.md" --workspace ./my-project --criteria "@criteria.md" \
@@ -397,6 +488,26 @@ mangled crossing the boundary — so a *contained* Claude role must drive by API
 key (`VOLLEY_AUTH_MODE=api_key` with `ANTHROPIC_API_KEY`); the all-Claude
 subscription path stays on the host, Docker-free.
 
+**A contained run's state needs a mount of its own.** The container's root
+filesystem is read-only, so volley inside has nowhere to keep the run's state
+until you mount the run's own host directory where it looks:
+
+1. Create `<root>/<run id>/` on the host first, empty. On Linux, Docker creates
+   a missing one owned by root, and the container's user can't write it.
+2. Mount it at `/home/node/.local/state/volley/<run id>`. That's
+   `SANDBOX_STATE_ROOT`, and `run_state` on `sandbox_run_args` renders the
+   flag.
+3. Pass volley the same `--run-id`.
+
+Without the mount, the run stops before any spend (exit 5) and says what to
+mount. Mount that one directory, never the whole root: the builder runs
+arbitrary commands, and with the root mounted it could read every other run's
+trajectory or plant a check in another run's config. Its own run's config is
+still the builder's to rewrite, so a resume on the host refuses it, since
+volley signs only the configs it writes outside the sandbox
+([Resume](#resume)). Resume a contained run inside the container, with the same
+mount.
+
 To run a local builder uncontained on the host anyway, opt out with
 `--allow-unsandboxed-builder` (or `VOLLEY_ALLOW_UNSANDBOXED_BUILDER=1`), which
 prints a one-time warning — only point it at a workspace you are willing to let a
@@ -494,6 +605,227 @@ on the host, for example `ssh -N -L 11522:localhost:11434 gpu-box`. On a Linux
 host, `host-gateway` is the Docker bridge's address, so the forward, like Ollama
 itself, has to listen there rather than on `127.0.0.1` alone.
 
+## OpenRouter
+
+`--builder-provider openrouter` and `--critic-provider openrouter` put a seat on
+[OpenRouter](https://openrouter.ai), so one API key runs both seats, Claude
+included, with no Claude Code CLI and no local model server:
+
+```sh
+OPENROUTER_API_KEY=sk-or-v1-... volley \
+  --prompt "@task.md" --workspace ./my-project --criteria "@criteria.md" \
+  --builder-provider openrouter --builder-model anthropic/claude-sonnet-5.5 \
+  --critic-provider openrouter --critic-model anthropic/claude-haiku-5.5 \
+  --allow-unsandboxed-builder --max-iterations 3
+```
+
+- **The key.** `OPENROUTER_API_KEY` is required whenever either seat is on
+  `openrouter`. Unset, volley exits 5 naming it, before any work. It goes out
+  as a Bearer token, with `X-Title: volley` so OpenRouter attributes the
+  traffic.
+- **The URL.** `VOLLEY_OPENROUTER_URL` (default `https://openrouter.ai/api/v1`)
+  points both seats at a proxy or another OpenAI-compatible gateway, and
+  `--builder-url` / `--critic-url` give one seat a URL of its own, under the
+  rules in [Seats on different machines](#seats-on-different-machines).
+  OpenRouter runs on fascicle's native transport, so there's no peer to
+  install, and the run summary records the transport as `native`.
+- **The seats.** An OpenRouter seat runs volley's tool loop, the same as a
+  local one. The builder gets volley's tools, `bash` included, so it's refused
+  uncontained unless you opt out, exactly like a
+  [local builder](#local-builder). The critic gets the read-only tools and the
+  same retry-and-degrade ladder as a [local critic](#local-critic).
+  `--dry-run` probes each OpenRouter seat's endpoint but runs no critic canary,
+  which would cost money here.
+- **Cost and reasoning.** OpenRouter reports what each call cost, and that
+  charge is the seat's cost, recorded as `provider_reported`, so
+  `--max-cost-usd` trips on an OpenRouter seat as on any other. A model that
+  reasons streams its reasoning, which the terminal shows dimmed unless
+  `--no-thinking` hides it, and which Zed shows as a thought.
+- **In the sandbox.** The container's allowlist reaches only the host gateway,
+  so a contained OpenRouter seat needs `openrouter.ai` let through your
+  `DOCKER-USER` rules. volley doesn't install that rule for you.
+
+## Run volley from Zed
+
+`volley acp` serves volley to an editor over the
+[Agent Client Protocol](https://agentclientprotocol.com), through fascicle's
+`serve_acp`, so a prompt in [Zed](https://zed.dev)'s agent panel starts a volley
+run on the folder Zed has open. The builder's work streams in as the reply, each
+round opens with a **Round N** line, the check shows as a command card, the
+critic's verdict arrives as a thought, and the turn ends with a summary.
+
+```sh
+volley acp \
+  --builder-provider openrouter --builder-model anthropic/claude-sonnet-5.5 \
+  --critic-provider openrouter --critic-model anthropic/claude-haiku-5.5 \
+  --check "pnpm test"
+```
+
+It reads the protocol on stdin and writes nothing but the protocol to stdout,
+with its own progress on stderr, which Zed shows in its agent log. Zed starts it
+for you ([below](#zed-setup)).
+
+### Each prompt is a run
+
+- **Fresh, in place.** Each prompt is a new volley run on the open folder, with
+  no worktree. Its task and its acceptance criteria are both the conversation so
+  far, then the new prompt. An earlier reply keeps only its last 2,000
+  characters, where its summary sits. An earlier prompt's attached files shrink
+  to a line naming each, since they're still on disk. A turn you stopped is
+  marked as stopped.
+- **Three rounds.** `--max-iterations` defaults to 3 per prompt, not 10, since
+  a prompt is one short exchange, and `--max-cost-usd` caps what it spends.
+  Follow a run that didn't converge with "keep going": the summary it ended
+  with lists what the critic still found missing.
+- **The tools.** The builder gets fascicle's workspace tools (`read_file`,
+  `list_files`, `search`, `write_file`, `edit_file`, `run_command`) plus
+  volley's `finish`. The critic gets the three reads. Both stay inside the open
+  folder, and neither gets `fetch`. volley doesn't offer the editor additional
+  directories, so in a workspace with several folders Zed opens the session on
+  the first, and a client that sends more anyway has its session refused.
+- **The summary.** The turn's last message says whether the run converged, in
+  how many rounds, and with what last verdict. When it didn't converge, it
+  lists the unmet criteria, and it names any gate edits and any verdict the
+  critic reached without its tools. A run that fails ends with a summary saying
+  in which round and phase, and why, so "try again" has a request to retry.
+- **Stop.** Pressing stop ends the turn as cancelled, and kills a running
+  command or check along with its whole process group.
+
+### Flags and refusals
+
+`volley acp` takes the run command's seat flags, and requires four of them:
+`--builder-provider`, `--builder-model`, `--critic-provider`, and
+`--critic-model`. A missing one is refused with every missing flag named. The
+rest are optional: `--builder-url`, `--critic-url`, `--builder-max-steps`,
+`--builder-max-tool-calls`, `--allow-unsandboxed-builder`, `--critic`, `--check`, `--max-iterations`,
+`--max-cost-usd`, and `--state-dir`.
+
+It refuses these before serving, each with exit 5:
+
+| Refused | Why |
+|---|---|
+| `--worktree` | A sibling worktree sits outside the project the editor has open. |
+| `--git` | It commits to the open repo after every phase, which no permission prompt covers. |
+| `--json` | Stdout carries the protocol alone. |
+| a `claude_cli` builder | The Claude CLI runs its own tools under its own permission model, so its edits would never reach the editor's prompts. |
+
+A `claude_cli` critic is allowed: it only reads, and it runs on the host, where
+its login works. The whole config resolves once at startup, so a bad flag or an
+unset `OPENROUTER_API_KEY` exits 5 there, where Zed's agent log shows it, rather
+than failing every prompt.
+
+### Modes and approvals
+
+Each session starts in Manual. Zed's mode picker switches it, and a switch holds
+from the next call on, mid-turn included. Zed also saves the mode you pick as the
+entry's `default_config_options`, and starts the entry's later threads in it.
+
+| Mode | Asks before an edit | Asks before a command |
+|---|---|---|
+| Manual | yes | yes |
+| Accept edits | no | yes |
+| Auto | no | no; offered only contained or opted out (below) |
+
+An edit asks with its diff, and offers "Allow all edits this session", which
+switches the session to Accept edits. A command offers "Always allow" for that
+exact command line: allowing `pnpm test` doesn't cover `pnpm test --watch=false`,
+which asks again. It never offers one for a command with shell control syntax
+such as `;` or `|`. A call you reject reaches the builder as
+`tool_approval_denied`, and its prompt tells it not to reach the same result
+another way.
+
+- **Uncontained, Auto isn't offered.** Outside volley's
+  [sandbox container](#local-builder) (`VOLLEY_CONTAINED`), a person approving
+  each command takes the container's place, so the mode picker lists Manual and
+  Accept edits alone, and the builder's `run_command` asks in both. No client
+  can switch the session to Auto, mid-turn included. A Zed entry left on Auto
+  (`"default_config_options": { "mode": "auto" }`, from a time it was offered)
+  falls back to Manual, with a warning in Zed's log.
+  `--allow-unsandboxed-builder` or `VOLLEY_ALLOW_UNSANDBOXED_BUILDER=1` opts
+  out, and Auto is offered again. So unlike the run command, `volley acp` never
+  refuses an uncontained builder.
+- **The check asks whenever a command would.** In Accept edits and Auto the
+  builder can rewrite a test without asking, and the check runs it next. So the
+  check asks on its own card exactly when a builder command would ask, offering
+  only Allow and Reject, since an "always" for checkride's `pnpm exec` would
+  cover the builder's commands too. A rejected check counts as a failed one, so
+  a round can't converge on work nobody checked.
+- **No keys in commands.** The builder's commands and the check run with the
+  agent's environment minus `OPENROUTER_API_KEY` and `ANTHROPIC_API_KEY`,
+  `PATH` kept, so nothing the builder writes can read the key a seat runs on.
+
+### Where its state goes
+
+Nothing of volley's own lands in the repo. Each prompt's run state goes under
+the same state root as any run's ([Run artifacts](#run-artifacts)):
+`<root>/<run id>/`, where the root is `--state-dir`, else
+`$XDG_STATE_HOME/volley`, else `~/.local/state/volley`. An unwritable root
+stops `volley acp` at startup, so it shows once in the agent log. The whole
+root is safe to delete whenever no prompt is running. A run's
+`trajectory.jsonl` there replays in `fascicle-viewer` like a CLI run's.
+
+### Zed setup
+
+Run `pnpm build` first: Zed runs `dist/cli.js`, and nothing else rebuilds it.
+Then add volley as a custom agent server in Zed's `settings.json`:
+
+```json
+{
+  "agent_servers": {
+    "Volley": {
+      "type": "custom",
+      "command": "node",
+      "args": [
+        "/abs/path/to/volley/dist/cli.js", "acp",
+        "--builder-provider", "openrouter", "--builder-model", "anthropic/claude-sonnet-5.5",
+        "--critic-provider", "openrouter", "--critic-model", "anthropic/claude-haiku-5.5",
+        "--check", "pnpm test"
+      ],
+      "env": {
+        "OPENROUTER_API_KEY": "sk-or-v1-...",
+        "PATH": "/usr/local/bin:/usr/bin:/bin"
+      }
+    }
+  }
+}
+```
+
+`PATH` is there for the builder's commands and the check. Each runs with
+`/bin/sh -c`, which reads no shell profile, so a `node` or `pnpm` from nvm, fnm,
+volta, or asdf can come back as `command not found` unless it's on this `PATH`.
+Put the directories that `dirname "$(command -v node)"` and
+`dirname "$(command -v pnpm)"` print at its front.
+
+### Check it in Zed
+
+Run this by hand against a scratch repository with a test command (a
+`package.json` whose `test` script runs `node --test` is enough), using the
+snippet above. Start a thread with "Volley", and check that the mode picker
+shows Manual: Zed starts a thread in the last mode you picked, so an earlier run
+of step 8 leaves it on Accept edits. Stay in Manual unless a step says
+otherwise:
+
+1. Ask for a small change. The builder's work should stream in as the reply,
+   under a **Round 1** line.
+2. When it edits a file, a permission request should show the diff. Allow it,
+   and the card should keep the diff.
+3. When it runs a command, a permission request should show the command before
+   it runs, and once allowed, the card should show the output.
+4. Once the builder finishes, the check should ask, then run as a command card
+   titled `pnpm test`, with its output.
+5. The critic's verdict should show as a thought.
+6. The turn should end with the summary: whether it converged, in how many
+   rounds, and the last verdict.
+7. Ask it to run `sleep 60`, allow it, and press stop. The turn should end as
+   cancelled, and `pgrep -fl 'sleep 60'` should find nothing.
+8. Open the mode picker. It should list Manual and Accept edits, and no Auto,
+   since volley runs uncontained. Switch to Accept edits and ask for another
+   change. The edits shouldn't ask, but a command still should.
+
+Two more round it out. Ask it to run `echo "key=$OPENROUTER_API_KEY"`, and the
+output should be `key=` with nothing after it. And the repository should hold no
+`.volley`.
+
 ## What the builder changed
 
 A check that exits 0 proves the check passed. It does not prove the builder did
@@ -508,7 +840,7 @@ iteration and reports what moved:
   which ones moved.
 - Changed paths matching the **gate** — the tests, fixtures, and check
   configuration that decide whether the work passes — are called out separately
-  in the prompt, listed in `.volley/summary.json` as `comparison.gate_edits`,
+  in the prompt, listed in the run's `summary.json` as `comparison.gate_edits`,
   and warned about on stderr as they happen.
 
 A gate edit is not misconduct: plenty of tasks are *about* the tests. It is the
@@ -537,11 +869,15 @@ that `--fail-on-gate-edit` cannot fire there.
 
 ## Run artifacts
 
-Everything volley knows lives in the workspace:
+Everything volley knows about a run lives in a directory of its own, outside
+the workspace: `<root>/<run id>/`, where the root is `--state-dir` (or
+`state_dir` in a config file), else `$XDG_STATE_HOME/volley`, else
+`~/.local/state/volley`.
 
 ```
-.volley/
+<root>/<run id>/
   config.json          # resolved run config (immutable per run)
+  config.sig           # this machine's signature over config.json (none from inside the sandbox)
   summary.json         # run-level usage, cost, status
   trajectory.jsonl     # every fascicle trajectory event (replayable, below)
   feedback.md          # current critic feedback (harness-written)
@@ -549,20 +885,44 @@ Everything volley knows lives in the workspace:
   iterations/NNN/      # per-iteration archive: feedback, verdict, check artifacts, summary
 ```
 
-A stale `.volley/` from a previous run is rotated to `.volley.bak.<timestamp>/`.
+- **Why outside.** Some checks read every file in the tree, dot-directories
+  included, as markdownlint-cli2 and checkride's links walk do. Kept in the
+  workspace, the run's own `feedback.md` would fail them from the second
+  iteration on, a failure the builder can't fix. Kept out, the workspace holds
+  only the builder's work, and `--git` checkpoints never commit volley's files.
+- **Finding a run.** A run prints `state: <dir>` when it starts and again in its
+  final summary, and `--json` and `summary.json` carry it as `run_state_dir`.
+  `--dry-run` names the root, and `--run-id` names the directory.
+- **Unwritable.** A run directory volley can't write is a configuration error
+  (exit 5) before any spend. In the sandbox container, mount the run's own
+  directory ([Local builder](#local-builder)).
+- **Pruning.** Nothing prunes old runs. A root volley creates is yours alone
+  (0700), since trajectories hold prompts and tool output. A reused `--run-id`
+  rotates the earlier run aside to `<run id>.bak.<timestamp>/`.
+- **Older runs.** An older volley kept the same files in the workspace's
+  `.volley/`. `volley resume` still finds such a run there, and resumes it in
+  place once you pass `--trust-config`, since an older volley signed nothing
+  ([Resume](#resume)).
+
+`volley matrix` writes its sweep to `.volley-matrix/` in the workspace, and a
+base config's `state_dir` moves each seat's run state as it would any run's.
 
 The trajectory replays in fascicle's bundled viewer — the `fascicle-viewer` bin
 ships inside the `fascicle` package; there is no separate viewer package:
 
 ```sh
-pnpm dlx --package=fascicle fascicle-viewer .volley/trajectory.jsonl
+pnpm dlx --package=fascicle fascicle-viewer ~/.local/state/volley/<run id>/trajectory.jsonl
 ```
 
 ## Environment variables
 
 See [.env.example](./.env.example): `VOLLEY_CLAUDE_BIN`, `VOLLEY_AUTH_MODE`,
-`VOLLEY_LOG_LEVEL`, `VOLLEY_NO_COLOR`, `VOLLEY_PRICING_PATH`, and the
-`ANTHROPIC_API_KEY` billing-meter warning.
+`VOLLEY_LOG_LEVEL`, `VOLLEY_NO_COLOR`, `VOLLEY_PRICING_PATH`, the
+`ANTHROPIC_API_KEY` billing-meter warning, each seat's base URL
+(`VOLLEY_OLLAMA_URL`, `VOLLEY_LMSTUDIO_URL`, `VOLLEY_OPENROUTER_URL`), and
+`OPENROUTER_API_KEY` for [OpenRouter](#openrouter) seats. Every run reads
+`XDG_STATE_HOME` for its default state root, and `XDG_CONFIG_HOME` for where
+it keeps the key it signs run configs with.
 
 ## Development