/v-collect

description: Re-run the collect + scope-gate + review tail of a Compound V run by run-id. Normalizes each job's output into results/<id>.json, re-runs the git-derived scope gate on every job, then the three-pass Review Gate (AC-gated). Use to re-check a dispatched run without re-dispatching workers.

You are running **`/v:collect`** — the **collect → scope-gate → review** tail of the Compound V pipeline, on an already-dispatched run. It does **not** re-dispatch workers (use [`/v:resume`](v-resume.md) for that). It re-normalizes results, re-runs the file-scope gate, and re-runs the Review Gate — the deterministic, idempotent back half of a run.

The run-id is `{{args}}`.

The run-dir layout and per-job `status` semantics are in [`skills/compound-v/state-machine.md`](../skills/compound-v/state-machine.md); the manifest each job is checked against is [`execution-manifest.md`](../skills/compound-v/execution-manifest.md); the canonical `job_result` shape is [`schemas/job_result.schema.json`](../schemas/job_result.schema.json).

Resolving the plugin root

The `scripts/` and `schemas/` this command calls ship with the plugin — they are not files in your own repository. Resolve the plugin root once per session before calling any of them:

CV="${CLAUDE_PLUGIN_ROOT:-$(ls -d "$HOME"/.claude/plugins/cache/*/superpowers-v/*/ 2>/dev/null | sort -V | tail -1)}"
CV="${CV:-$PWD}"; CV="${CV%/}"

`CLAUDE_PLUGIN_ROOT` is set for hooks but is not set in this Bash environment, so treat it as a hint, never the whole answer — the fallback line covers an installed plugin cache or a checkout of this repo. Paths under `docs/superpowers/` stay relative; only the plugin's own `scripts/` and `schemas/` get `$CV`.

Steps

1. **Locate the run.** If `{{args}}` is empty, list the subdirectories of `docs/superpowers/execution/` and ask which run to collect. The run dir is `docs/superpowers/execution/<run-id>/`. If it does not exist, stop and say so. If no jobs have been dispatched yet (`phase` earlier than `DISPATCHED`), tell the user there is nothing to collect and stop.

**Branch on the manifest kind.** If `manifest.yaml` carries a `fast_path` block (a v2.9 pre-eval-backed fast-path run — its `phase` is `FASTPATH_DISPATCHED`), do **not** run the ordinary three-pass review tail (steps 3–4). Run the **fast-path authoritative sequence** below instead (CR5-2). Step 2 (collect/normalize) still applies to the single implementer job. A legacy (non-`fast_path`) manifest uses steps 2–5 unchanged.

2. **Collect — normalize each job's output.** The collector is **per-job** (required `--job-id` + `--run-dir`; no positional run-dir). Loop over every dispatched `<job-id>`, normalizing its heterogeneous worker output into a canonical `results/<id>.json`:

   # for each dispatched <job-id>:
   python3 "$CV/scripts/compound-v-collect-results.py" \
     --job-id <job-id> \
     --run-dir docs/superpowers/execution/<run-id>/ \
     --scope <scope-verdict.json> \
     --worker-output <last-message> \
     --schema "$CV/schemas/job_result.schema.json"

Output lands in `<run-dir>/results/<job-id>.json`. The collector checks each result against [`schemas/job_result.schema.json`](../schemas/job_result.schema.json) — **but read that as the partial check it is**: its runtime checker walks TOP-LEVEL field types only and is blind to the `tests` sub-object, so a `tests` block that violates the schema outright passes it. That blind spot is how a release shipped in which every Engine C `job_result` carried the raw `test-floor` document in `tests` and failed the schema on the clean happy path. Full conformance is asserted by [`tests/test-engine-c-contract.sh`](../tests/test-engine-c-contract.sh), which validates a really-generated `job_result` with `jsonschema`; do not read a clean collector run as proof the document conforms. Its `files_changed` / `violations` / `blocked` fields are **git-derived** (folded in from `--scope`), never model-self-reported; `--worker-output` feeds only the human `summary`. It prints **no fabricated cost metrics**.

3. **Scope gate — git-diff authority, every job.** Re-run the scope gate on each job against its `write_allowed` from the manifest. The script takes a mutually-exclusive **mode flag** (`--worktree` OR `--repo`) plus the allowed globs (`--allow-file`) — no positional path. Use the mode matching how the job was dispatched (mirrors [`phase-3-parallel-opus-dispatch.md`](../skills/compound-v/phase-3-parallel-opus-dispatch.md)):

   # worktree jobs:
   python3 "$CV/scripts/compound-v-scope-check.py" --worktree <wt-dir> --allow-file <allow-globs-file>
   # direct (in-repo) jobs:
   python3 "$CV/scripts/compound-v-scope-check.py" --repo <repo-dir> --baseline <pre-dispatch-commit> --allow-file <allow-globs-file>

Exit codes: `0` = pass, `1` = blocked (violations present), `2` = usage/git error. It derives changed files with `git -C <worktree-or-repo> diff --name-only HEAD` ∪ `git ... ls-files --others --exclude-standard`. Any path outside `write_allowed` ⇒ the job is **BLOCKED**: mark it `blocked` in `state.json`, retain its worktree, **do not merge it**, and **HALT the run** — surface the offending paths to the user. A BLOCKED job is corrected and re-dispatched via `/v:resume`, not silently merged.

**Then run the test floor per job, from the same producer.** Ordering is load-bearing and is the reverse of the fast-path tail: the executor runs, the gate computes `files_changed`/`violations`, and *then* the resolved commands run inside the worktree. Running tests before the gate would let a coverage file or a cache directory a test wrote become a false `violation`. The flip side is real and is the caller's problem: **anything a test creates after the gate is outside the gate's authority and must not be merged** — which is why merge-back stages by `files_changed` and not by `git add -A`.

   python3 "$CV/scripts/compound-v-fastpath-run.py" test-floor \