org-dispatch

org-dispatch — run an org-team over the coordination channel

org-dispatch is the execution engine of the org-team model: a flat pod of up to four peer Claude Code sessions claims lane-tagged slices of an approved spec and implements them concurrently over the baseline MCP channel, each peer in its own git worktree, so per-feature wall-clock approaches the slowest lane instead of the sum. It is the multi-session counterpart to swarm-dispatch (which parallelizes components of one spec inside one session via bounded subagents).

It is governed by Article X — Multi-session coordinated workflows (a different axis from Article II, which governs intra-session delegation and is untouched). The load-bearing difference from the retired sprint-dispatch sandbox: a peer decides its own in-lane implementation choices in its own main context — it does not bounce every fork to the lead. Only un-decidable or cross-lane forks escalate.

Gate: opt-in, off by default, git required

node .claude/skills/org-dispatch/org-mode.mjs gate   # wraps org-mode.mjs -> orgDispatchGate

If the gate refuses, stop — org mode is the opt-in fence (and worktree isolation requires git).

The run loop (lead, in main context)

1. Decompose into lanes. Read the approved spec and its dependency DAG. Each lane is one channel task {id, lane, write_set, depends_on, assignee?} (org-mode.toLaneTasks). Write the tasks into the channel state and a durable plan (harness/plan-store.createPlan). A lane carries a domain tag the claiming peer inherits — its in-lane decision latitude. No sprint manifest is required: a lane is just a fully-specified task. The lead may also enqueue_task ad-hoc lanes at any time — peers can be handed tasks with no sprint in place; the pool is enabled by velocity.org_mode.enabled alone.
2. Allocate: claim-any or directed. Leave a lane's assignee unset for claim-any (the first free peer wins) — simplest, but one fast peer can monopolize the queue while others idle. Set assignee to a peer_id for a directed lane that only that peer may claim — this is the lead's control to spread load across the pod or hand a specific lane to a named peer. claim_task enforces it server-side (a non-assignee claim is rejected); the task-available push carries the assignee so a well-behaved peer skips a lane that is not its own.
3. Select the pod (peer-select.selectPeerClass): if human-launched peer sessions are registered on the channel, the flat pod (up to four) works the lanes; otherwise the lead spawns bounded swarm-worker subagents as the fallback execution surface. The lead is one of the four — flat for claiming, plus the arbitration + human-escalation hat. 3.5. Isolate every peer before any lane is claimed. For each peer, run worktree.createPeerWorktree({rootDir, peer_id}). It returns the peer's own working directory and branch (org/<peer_id>), or {ok: false, reason}. A refusal stops the dispatch — never fall back to running peers in the primary tree, because two peers in one checkout each see the other's half-finished edits as their own working tree, and the first commit carries both. Re-running for a peer that already has a tree returns the same path, so a resumed dispatch does not tear down live work.