v-orchestrate

You are running /v:orchestrate — the materialize step of Compound V. You turn a verified plan into the machine-readable contract the dispatcher runs: a manifest.yaml plus an initial state.json in a fresh run directory. This command does not dispatch — it produces the manifest and stops, so the user (or /v:dispatch) can inspect or edit it first.

The argument is {{args}}. It is normally a plan path. It may instead be an accepted fast-path pre-eval — a pre_eval_id (YYYY-MM-DDThhmmssZ-<slug>-<nonce>) or a path to docs/superpowers/pre-eval/<pre_eval_id>.json whose decision is FASTPATH_ELIGIBLE — in which case take Step 0 and stop.

The manifest schema and rules are defined in skills/compound-v/execution-manifest.md; the routing decisions come from skills/compound-v/routing-policy.md; the run-dir layout and state.json shape come from skills/compound-v/state-machine.md. Read those — they are the authority; this command is the procedure.

Steps

1. Fast-path branch (accepted pre-eval → committed single-job run). If {{args}} resolves to an accepted FASTPATH_ELIGIBLE pre-eval record (a pre_eval_id, or a docs/superpowers/pre-eval/<pre_eval_id>.json path with decision: FASTPATH_ELIGIBLE), do not run the plan-based flow below — the fast path has no full plan and no three audits. Instead delegate to the deterministic materializer, which runs the authoritative Phase-M lifecycle (mint a deterministic run-id from pre_eval_id → copy the pinned taxonomy snapshot into the run → write spec/plan stubs, block-YAML audit skip-records, the single-job fast_path manifest with the review declaration only, and the captured implementer prompt → commit all artifacts except state.json → append + commit the bind event → commit state.json at FASTPATH_DISPATCHED LAST). It also runs the validator in --mode pre-dispatch as an in-code gate before binding, so a manifest the validator would reject never reaches dispatch.

   python3 scripts/compound-v-fastpath-materialize.py materialize \
     --repo . --pre-eval-id <pre_eval_id> [--prompt-file <captured-implementer-prompt>]
   

   The materializer is idempotent + crash-consistent: a committed state.json at FASTPATH_DISPATCHED ⇒ the bind is already durable ⇒ the run is complete (re-running is a no-op); a run interrupted before state.json is rebuilt deterministically (same pre_eval_id → same run-id; an existing child is discovered before another is minted). It fails closed — a tampered record (its localization.resolved_paths[0] disagreeing with the committed localization artifact, a non-FASTPATH_ELIGIBLE decision, or a taxonomy snapshot whose bytes don't content-address to the record's taxonomy_digest) is rejected before any write or commit. Report the run-id and the next step (/v:dispatch <run-id>), then stop — Steps 1-9 below do not apply.

2. Resolve the plan. If {{args}} is empty, list the plans in docs/superpowers/plans/ and ask the user which to materialize. If the named plan path does not exist, stop and say so.

3. Read the plan and its pre-flight audits. Extract:

   • the feature title and feature-level Acceptance Criteria (from the spec the plan targets),
   • the verified Partition Map (the disjoint write-paths per task),
   • the three audit paths (docs/superpowers/{archaeology,expert,library-audit}/<topic>.md). If the plan has no Partition Map, stop — this plan is not Compound-V-ready; route it through Phase 2 (skills/compound-v/phase-2-disjoint-partitioning.md) first.

4. Choose the run-id. Convention: YYYY-MM-DD-<slug> (the slug from the plan/feature). The run dir is docs/superpowers/execution/<run-id>/. Create it (and jobs/ + results/ subdirs).

5. Apply the routing policy (routing-policy.md) to each partition entry. For every job set backend · model · isolation · run from its type, honoring the active stance in .claude/compound-v.json (Balanced default; Claude-only when Codex is absent). Consult docs/superpowers/memory/routing-lessons.md — a recorded lesson overrides the table default for that pattern.