orchestrating-fusion

# Fusion Orchestration Separate judgment from mechanical implementation. A lead investigates, decides, specifies, reviews, and verifies. An executor edits only the bounded scope in the lead's specification. ## Route Deliberately Do not force every task through Fusion: - Keep a tiny, already-understood, single-file mechanical change in the normal writable session. - Use Fusion when investigation, architectural judgment, multiple non-trivial writes, or independent review materially improve the result. - Offer a durable PRD, ADR, or implementation plan only when persistent artifacts reduce substantial ambiguity. Never create a spec lifecycle merely because a change is large or risky. ## Native Adapters Prefer the installed native roles when the current tool exposes them: - **OpenCode:** run the `fusion-lead` primary; it can delegate to `fusion-executor` and cannot edit or run shell commands. - **Amp:** select the `fusion` agent mode; its restricted tool surface exposes `fusion_executor` for implementation. - **Codex:** from the writable root session, spawn `fusion-lead` for the specification, then spawn the sibling `fusion-executor`; a read-only child cannot safely escalate a nested child to workspace-write. - **Pi:** from the root session, use the `Agent` tool to run `fusion-lead`, then run the sibling `fusion-executor`; `pi-subagents` enforces the lead's tool allowlist and intentionally disables nested delegation. For other assistants, apply the workflow below using th...