v-status

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}}.

Steps

1. Locate the run.

   • If {{args}} names a run-id, the run dir is docs/superpowers/execution/{{args}}/.
   • If {{args}} is empty, list the subdirectories of docs/superpowers/execution/. 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 (plain Superpowers' subagent-driven-development task-tracking directory — task-N-brief.md / task-N-report.md / progress.md / review-<sha>..<sha>.diff)? If so, 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) — do not parse or summarize its contents (that directory's format belongs to the base Superpowers plugin, not Compound V; a presence check is all that's warranted). 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.

   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 — --backend <job.backend> --tier <job.tier> [--effort <job.effort>] --stance <routing_stance> [--config .claude/compound-v.json] (the manifest carries intent, not a hardcoded model, so the plugin survives model churn). Pass --stance from the manifest's routing_stance (default balanced) so the displayed Backend · Model matches what actually dispatches — without it a cost-aware standard-tier Claude job would display opus but dispatch sonnet. Show it as a Backend · Model column so it is always visible which model each job runs on:

   Job	Title	Backend · Model	Status	Liveness	Usage	Isolation	Worktree
   task-0-schema	DB schema + types	claude · opus (deep/high)	done	—	—	direct	—
   task-1-editor-ui	Editor UI slice	codex · gpt-5.6-terra (standard/med)	running	WORKING	in=12.3k out=4.1k	worktree	$TMPDIR/…

   If a job carries an explicit model: override in the manifest, show that verbatim (resolution is skipped for it). Per-job status is one of {pending | running | done | blocked | failed} (see state-machine.md). Show the session_id for any Codex/worktree job that has one. If state.json.attempts[<job>] is present and non-zero, show the retry count for that job (e.g. an Attempts column or · retried 2×).