dispatchlisted

# /foundry:dispatch The lean dispatch path — a native-primitive REPLACEMENT for the bespoke dispatch stack. Worker spawn = the native **`Agent` tool** (`isolation: "worktree"`, structured return); multi-atom fan-out = the native **`Workflow` tool** (`workflows/release-wave.js`). For a **single-repo** adopter this REPLACES the bespoke `dispatch-agent` + `.claude/dispatch-queue/` machinery (queue manifests, flock, `wt claim`, WorktreeCreate prereqs, `result.json` polling, fan-out hygiene) — native primitives subsume it. > **Single-repo only.** Native `isolation:worktree` worktrees the **session repo** (the > workspace). It CANNOT reach a separate gitignored **product clone**, so a **multi-repo** > adopter (workspace ⟷ product-repo, e.g. acme-app, or self-hosting `agentic-foundry/`) > still needs a re-extracted minimum: an explicit **`target_repo`** (a frozen+authorized > contract field), a per-spawn **dispatch manifest**, the **`WorktreeCreate` hook** > (`foundry-worktree-create.sh`) that redirects the worktree to the named product repo via > **`foundry-wt`**, and worktree-time binding of the worker to that named repo (so its PR can only > land there). See *Multi-repo dispatch* below. This is NOT the heavyweight bespoke queue — it is > the one fact native isolation cannot provide (which repo to worktree). ## Native default vs. the deprecated bespoke fallback (feat-foundry-dispatch-on-native-workflow, AC-DNW-1..4) **Native is the default, unconditionally, for both a single a