Skill: Arcanum Orchestrate

1. an explicit repository route declared by the active repository instructions;
2. an explicitly user-named skill, normalized through a declared repository alias;
3. a matching repository-local capability package;
4. a user-global or catalog candidate only when the repository package is absent and repository policy permits fallback.

For Codex, the repository package is .agents/skills/<capability>/SKILL.md. For Claude, it is .claude/skills/<capability>/SKILL.md. The legacy alias arcanum-orchestrate normalizes to repository capability orchestrate; it must never cause a probe for .agents/skills/arcanum-orchestrate/ or .claude/skills/arcanum-orchestrate/, and it cannot override an installed local orchestrate package. Catalog metadata may be present in host context, but it is not consulted when an earlier repository-owned route resolves.

orchestrate execute <dispatch.json>

Accept exactly one repository-local dispatch JSON path. Extra positional arguments, a missing path, or another verb return a blocked preflight receipt and perform no host action.

Native execution after preflight uses scripts/native_dispatch_driver.py. Its prepare-spawn and prepare-wait commands append the required pre-call events before making a host request artifact available. record-spawn and append-event record host-owned results. advance-wave admits the exact current-wave receipt set, appends receipt joins and the reducer-owned gate decision, validates the causal stream, and only then persists dependent actions. prepare-next-wave-plan binds those exact actions to an exclusively created current-wave plan without changing the causal stream.

orchestrate rehearse <dispatch.json>

For an authorization-required v0.2 dispatch, run the deterministic coordinator rehearse command before requesting execution authority. Rehearsal validates the dispatch and compiles every wave and typed gate in memory. It emits no action documents, makes no host calls, records spawn_attempt_count: 0, and grants no execution authority.

1. Parse the exact execute grammar.
2. Run the canonical Dispatch Spec validator. Continue only when the result is pass; flag and block emit a blocked receipt.
3. Read subagent_strategy.authorization. Legacy v0.2 continues only for approved or not_needed. A v0.3 run instead requires the canonical dispatch to remain requires_user_permission and one separate execution entry carrying authorization: approved; the coordinator applies that approval only to an in-memory execution projection. Use authorization_pending when neither contract supplies valid authority; use blocked for blocked or missing authority.
4. Load the selected host profile and compare every required_execute_operation with the active host tool catalog. The active host catalog is runtime evidence; a shell executable or prose claim is not a substitute.
5. If any required operation is missing, emit state=blocked, name the missing operations, set spawn_attempt_count=0, and stop.
6. Ask the deterministic coordinator to verify registration against the canonical append-only strategy ledger. Legacy v0.2 verifies embedded exact-sheet registration unchanged. V0.3 verifies the run-local execution entry, exact immutable canonical dispatch, runtime profile, confirmation binding, optional equivalence and required admission receipts, raw adapter-normalized ledger row, executable projection, registered topology, source lifecycle, consumed registration envelope, and temporary close path. Missing, stale, mismatched, duplicate, or unconsumed registration blocks before actions are emitted.
7. Ask the deterministic coordinator to compile the first eligible wave. A passing preflight persists strategy-registration.json beside the state and run plan and ends at state=wave_ready with action documents and spawn_attempt_count=0.

Preflight never invokes spawn, wait, join, close, message delivery, or a model-backed CLI.

• command, dispatch ID, and caller-supplied run ID;
• status and state;
• validation and authorization status;
• host ID, required/available/missing native operations;
• action count and whether a run plan was emitted;
• spawn_attempt_count, which must equal zero;
• blockers.

The deterministic coordinator's reduce command remains an offline reducer and fixture surface. Its result alone is not live execution evidence and cannot justify a resolved closeout. A live native path must use the driver handshake and a validator-clean causal stream. If a pre-call append blocks, do not make the host call. If a post-call append or terminal validation blocks, preserve the partial stream and close with error; never reconstruct the missing event.

1. Admit the action only when its action_id exists in the current run plan, its persisted document matches that plan entry, and no attempt event already exists for the identifier.
2. Revalidate the action's canonical briefing_binding digest and exact read/write-policy equality, then build bounded host context from the action's role, capability, target, mode, mutation policy, references, and complete typed briefing. Preserve task-completion status separately from domain-gate status. Never infer forbidden reads from forbidden-write scopes. The host task name must be an opaque deterministic function of dispatch ID, run ID, and action ID. It must differ across fresh runs and must not include raw role, target, reference, dispatch, or run prose.
3. Run driver prepare-spawn; it must block on missing, changed, or incomplete briefing material before appending action_attempted, then append that event before exposing the exact host request. If preparation blocks, do not invoke the host.
4. Invoke that operation exactly once. Do not retry implicitly.
5. On return, run driver record-spawn --request <prepared-request> --agent-id <id> to append host_spawn_returned and bind the returned agent_id to the action_id. The returned identifier's basename must equal the exact deterministic task_name in the persisted prepared request. A missing or mismatched identifier blocks before append.
6. On host error, run driver record-spawn --failed to append host_spawn_failed, persist the failure in the non-causal residue stream when useful, and stop dependent execution.

An unknown, non-persisted, mismatched, duplicate, or replayed action blocks before a host call. Waiting, joining, result normalization, and gate reduction are separate execution steps.

Use correct-agent-binding only against an owner-accepted correction batch. The command binds the admitted action and exact persisted spawn request; names the prior host-result and wait-registration sequences; preserves both original events; and appends one v0.2 correction whose corrected identifier basename equals the prepared task_name. The validator makes that corrected binding effective for later terminal, cleanup, join, and gate checks.

A correction fails closed when the action, wave, prior identifier, prepared task name, superseded sequences, reason code, or uniqueness check differs. It also fails after any same-wave terminal, timeout, interrupt, close, receipt join, or gate evidence. A prior mailbox-wide wait attempt may remain because the causal wait event carries no target identifier, but its derived request artifact becomes audit residue and must be replaced by a corrected audit-only binding projection. Never replay the host wait solely to repair that artifact.

1. Reject bindings that are absent, duplicated, outside the selected wave, or inconsistent with the persisted actions.
2. Run driver prepare-wait; it derives every successful native binding from the causal stream, appends one agent_wait_registered per expected action and wait_attempted, then exposes the mailbox-wide wait request.
3. Invoke the host's mailbox-wide wait operation, then reconcile returned completions and the host inventory against only the pending identifiers. Repeat only within the declared bounded wait policy, appending another wait_attempted before each call.
4. For a terminal known agent, validate its declared action and agent identities, normalize its bounded result to schemas/receipt.schema.json, append agent_terminal, and mark it logically closed exactly once with agent_closed.
5. For an unresolved known agent when the wait policy expires, append wait_timed_out, invoke the mapped interrupt operation once, append agent_interrupted, and normalize an explicit timed_out receipt for its expected action.
6. Persist normalized receipts in a directory containing exactly one <action_id>.json file per current-wave action and no other entries.
7. Persist exactly one raw task-result JSON object per current-wave action, then run driver advance-wave with that exact directory. It validates every briefing-required field and task-completion status before receipt admission, requires a blocked task result to normalize as status=block, and under execution contract v0.2 verifies every normalized domain field/value against the raw task result rather than trusting normalized output alone. For v0.2 it also requires each normalized receipt's artifacts to equal that action's declared output_refs, and the admitted wave artifact union to equal the bound gate's requires_role_receipts. It validates closed receipt shape and identity, and only then appends receipt_joined, invokes the reducer, appends gate_decided, and exposes dependents. A failed task-result validation writes blocking evidence and emits no join or gate.
8. When a passing gate exposes dependents, run driver prepare-next-wave-plan with the exact dispatch, prior run plan, gate decision, next action set, next state, causal prefix, and action directory emitted by advance-wave. Continue only with its exclusively created current-wave plan.

Under arcanum.capability-bound-execution.v0.2, every wave has a non-null gate ID and exactly one typed evaluation. gate_pass may unlock the declared next wave. gate_block unlocks nothing. gate_resolved is a valid final domain resolution, unlocks nothing, and preserves the exact field/value/classification in terminal state and final gate_decided event even when orchestration state is complete. Legacy schema versions remain validate-only and unchanged.

An unknown result, duplicate terminal result, missing binding, identity mismatch, non-pass result, or missing result is blocking evidence. It cannot open a dependent gate. Multi-wave progression and closeout are separate execution steps.

Invoke it as prepare-next-wave-plan <dispatch.json> --prior-run-plan <plan> --gate-decision <gate> --next-actions <action-set> --next-state <state> --events <events.jsonl> --actions-dir <actions> --output <next-plan>.

Pass the emitted plan to prepare-spawn with the matching --depends-on-gate-id. A dependent-wave spawn without one passed gate from its declared dependency waves blocks before appending action_attempted.

1. Stop every later spawn in that wave.
2. Run driver prepare-partial-recovery; it derives only successful native bindings, appends their registrations plus one mailbox-wide wait event, and exposes the exact host wait request.
3. Reconcile only those known identifiers with the host inventory. Record a completed sibling through record-partial-terminal; for an unresolved one, run prepare-partial-interrupt, invoke its exact interrupt request once, then record it with record-partial-interrupt.
4. Append separate evidence_closure residue for every cleaned sibling.
5. Run close-partial-wave. It requires all known siblings to be cleaned, appends a terminal typed run_blocked, validates the complete stream, and emits no joins, gates, dependent actions, or retry.

Partial-wave recovery is scoped to the selected failed wave. Earlier completed waves retain their joins and gate decisions, while run_blocked remains unique and globally terminal for the run.

The blocked closeout preserves the failed run as evidence only. A fresh run requires a distinct run ID and explicit retry authority; it must not replay an action in the closed stream.

Residue is read-only collaboration or diagnostic evidence. It cannot satisfy a spawn, wait, terminal, join, gate, closeout, authority, or promotion obligation. Historical mixed logs remain historical failure evidence and must not be rewritten into a passing causal stream.