feat: built-in plan orchestrator for multi-session, multi-worktree concurrent plan execution

Problem

When working on non-trivial projects, users quickly end up with multiple plans competing for execution across different sessions and worktrees. There is currently no built-in mechanism to:

1. Track plan lifecycle — plans go from draft → approved → executing → completed, but there is no registry
2. Detect conflicts — two plans may touch the same files or services, but nothing warns you
3. Coordinate multi-session execution — spawning agents in parallel worktrees requires manual orchestration
4. Maintain a dependency graph — Plan A may depend on Plan B completing first
5. Track worktree state — which worktree is executing which plan, what is its status, is it stale?

Real-world example

Our Wire & Cable project built a custom orchestrator to solve this. It is rudimentary but functional:

What it does

• PRD Registry (PRD_REGISTRY.yaml) — single source of truth for all plan lifecycle states
• Manifest schema — each plan declares owned_zones, consumed_interfaces, forbidden_zones, invariants (Pydantic-validated)
• Promote gate — plans must have a SPEC + valid manifest before entering the queue
• Reconciliation — detects zone conflicts between queued plans, builds a DAG, generates an EXECUTION_GRAPH.yaml with parallel/sequential groups
• Dispatch — creates isolated worktrees per plan, enforces contracts (workers cannot touch forbidden zones)
• Worker lifecycle — workers signal completion via WORKER_STATUS.yaml, orchestrator handles merge/archive/replan

Architecture (3 scripts + 1 skill)

• promote_prd.py → validate manifest + SPEC, queue the plan
• reconcile_prd.py → detect conflicts, build DAG, generate EXECUTION_GRAPH
• dispatch.py → create worktrees, spawn agents, enforce contracts
• lifecycle.py → merge / archive / replan / cancel

What is missing (opportunities for Claude Code native support)

| Gap | Impact |
|-----|--------|
| No native plan registry | Users track plans in ad-hoc files or memory |
| No conflict detection | Two plans can silently clobber each others files |
| No worktree awareness | Claude Code does not know which worktree is executing what |
| No cross-session state | If a session dies mid-execution, the plan state is lost |
| No dependency graph | Sequential dependencies require manual ordering |
| No worker isolation enforcement | Nothing prevents a worktree agent from touching files outside its scope |
| No merge coordination | After parallel execution, merging worktrees back is manual and error-prone |

Proposed feature

A built-in plan orchestrator that provides:

1. Plan Registry — /plans list, /plans status, /plans conflicts
2. Manifest-based contracts — each plan declares what it owns and what it cannot touch
3. Automatic conflict detection — flag overlapping owned_zones before execution
4. Multi-worktree dispatch — /plans dispatch creates worktrees and spawns agents with isolation contracts
5. Cross-session persistence — plan state survives session restarts
6. Worker status tracking — agents report progress, orchestrator monitors completion
7. Merge coordination — /plans merge plan-id with conflict resolution

Why this matters

As Claude Code becomes the primary development tool for complex projects, users will increasingly have:

• Multiple features in flight simultaneously
• Parallel agents working in different worktrees
• Plans that depend on each other
• Sessions that crash or time out mid-execution

Without orchestration, this degrades into chaos. Our custom solution works but is project-specific and fragile. A native solution would benefit the entire ecosystem.

Reference implementation

Our orchestrator code is at aegis-ventures/wire_and_cable:

• scripts/orchestrator/promote_prd.py
• scripts/orchestrator/reconcile_prd.py
• scripts/orchestrator/dispatch.py
• scripts/orchestrator/lifecycle.py
• src/schemas/prd_manifest.py (Pydantic manifest schema)
• .claude/skills/wc-orchestrate/ (skill wrapper)

This is a ~1,500 LOC implementation that took several iterations to stabilize. A native Claude Code feature could be significantly more robust and general-purpose.