/v-status

description: Render the state of a Compound V orchestrator run — pipeline phase plus a per-job status table — by reading state.json from the run directory. Optional run-id argument; without one, list runs and pick the most recent.

You are about to render the **state of a Compound V orchestrator run**. This is read-only: it inspects `state.json`, it does not dispatch, collect, or merge anything.

The run-id (optional) is `{{args}}`.

Resolving the plugin root

The `scripts/` 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.

Steps

1. **Parse `{{args}}`, then locate the run.** `--live` is the only flag this command recognizes. If `{{args}}` is exactly `--live`, or starts with `--live` followed by whitespace, strip that leading token, note that the live watch (step "Live watch" below) is requested, and treat whatever remains (trimmed) as the run-id for the rest of this step — e.g. `--live 2026-09-01-foo` locates run `2026-09-01-foo` and requests the watch; a bare `--live` requests the watch with no run-id, same as the no-argument case below. `{{args}}` with no leading `--live` is a bare run-id (or empty), exactly as before, and the live watch is not requested.

• If the (flag-stripped) `{{args}}` names a run-id, the run dir is `docs/superpowers/execution/<run-id>/`.
• If `{{args}}` is empty, list the subdirectories of `docs/superpowers/execution/` — **except `epics/`**, which holds epic spines (`epics/<epic-id>/epic-state.json`), not runs; it is rendered by the "Epic progress" section below, never as a run row. If there is exactly one, use it. If there are several, show them (newest first by run-id date prefix) and render the most recent, noting the others.
• If `docs/superpowers/execution/` is absent or empty, tell the user there are no **Compound V**

orchestrator runs yet. Before stopping, do one cheap check: does `.superpowers/sdd/` exist in this repo? That is plain Superpowers' `subagent-driven-development` workspace root, and in 6.2.0 it is **plan-scoped**: the skill's `scripts/sdd-workspace <plan>` prints and creates `<repo-root>/.superpowers/sdd/<plan-basename>/`, writing a self-ignoring `.gitignore` at `.superpowers/sdd/`, so one plan's whole artifact set — the `progress.md` ledger whose first line names its plan, `task-N-brief.md` (`scripts/task-brief`), the implementer's report file, and the `review-<base7>..<head7>.diff` review packages (`scripts/review-package`) — sits one level deeper and stays git-ignored (`subagent-driven-development/SKILL.md:122-135`). That ledger is the SDD controller's recovery map, and its per-task fix loop runs **five rounds maximum** before a breaker trips and the controller adjudicates each open finding itself, parking it in the ledger with a ruling (`subagent-driven-development/SKILL.md:319-320,358-364`). A clean final review deletes the plan's workspace outright (`SKILL.md:416-421`), so an absent directory is not evidence that no SDD run happened either.

`/v:status` **only checks that the directory exists.** It does not read the ledger — so it does not know which plan ran, which tasks are complete, how many fix rounds were spent, whether the breaker tripped, or which findings were parked — and it never parses briefs, reports or review packages: that format belongs to the base Superpowers plugin, not Compound V, and a presence check is all that's warranted. If the directory is there, say so explicitly: work clearly happened here, just not through Compound V's manifest-driven dispatch (auto-interception didn't trigger, or the plan predates it), and point the user at `progress.md` instead of summarizing it. Otherwise stop as before — genuinely no orchestrator runs of either kind.

2. **Read `state.json`** from the run dir (and `manifest.yaml` for job titles). If `state.json` is missing or unreadable, report that the run dir exists but has no state yet, and stop.

3. **Render the run-level phase.** Show the `phase` (one of `SPEC_READY → PREFLIGHT_DONE → PARTITION_VERIFIED → DISPATCHED → COLLECTED → REVIEWED → MERGED`, or terminal `BLOCKED`) and `updated_at`. The phase meanings are defined in [`skills/compound-v/state-machine.md`](../skills/compound-v/state-machine.md).

**v2.9 fast-path phases.** A pre-eval-backed fast-path run uses two extra `state.json` phases (same authority doc): `FASTPATH_DISPATCHED` (the single-job fast-path manifest was materialized + dispatched) and terminal-branch `ESCALATION_REQUIRED` (the pre-merge post-hoc reclassifier escalated; the pipeline rejoined the full path via a **new** run). Render them exactly like any other phase. `PRE_EVAL_DONE` is **not** a phase — it is a `status` field inside a write-once pre-eval **record** (there is no `state.json` at prediction time); never expect it in `state.json.phase`. When `phase == ESCALATION_REQUIRED`, read `state.json.escalated_to` and show the child run-id the fast-path escalated into (`escalated → <child-run-id>`); the fast-path patch stays under this run as evidence, the child starts from the clean baseline.

4. **Render the per-job table.** One row per job from `state.json.jobs`, with `manifest.yaml` supplying the title, the `backend`, and the routing **intent** (`tier`, optional `effort`). For each job, resolve the concrete **model** it runs on with [`scripts/compound-v-resolve-model.py`](../scripts/compound-v-resolve-model.py) — `--backend <job.backend> --tier <job