executing-planslisted

# Executing plans The controller that walks a plan from first task to last. Calls `dispatching-subagents` or `dispatching-parallel-agents` per task. Tracks state with the native Task tools (`TaskCreate` / `TaskUpdate` / `TaskList`). Persists state in the plan file's checkboxes so `/clear` can resume. ## When to use - A plan exists at `docs/llm-orchestrator/plans/`. - More than one task remains. - You're the controller (top-level session), not a subagent. ## When NOT to use - A single task → just dispatch directly. - The plan is unclear or has TBDs → return to `writing-plans` first. ## Steps 1. **Load the plan.** Read every task. Note three lines per task: - `Independent:` (yes / no — depends on N) - `Files:` (paths the task creates/modifies) - Body — to scan for **semantic** dependencies (see step 2). 2. **Compute the real dependency set.** Trust but verify the plan's `Independent:` line: - If a task declares an `Interfaces:` block, treat it as the authoritative signal: A consumes what B introduces → A depends on B. Only body-scan tasks without the block. - For each task, scan the body for references to symbols, endpoints, schemas, types, or files that another later task introduces (look in those tasks' `Files:` and bodies). - If task A references something task B creates, A depends on B — regardless of what `Independent:` says. - Common semantic dependencies: API specs depend on the routes they document; tests depend on the code they exercise; mi