party-to-pipeline

Run dispatch-general.ps1 with -StoryId and -Phase (create-story, dev-story, or code-review) from the main controller window. The script registers the run in worker_runs, spawns the worker sub-window, confirms startup within a bounded window, and exits without waiting.

Mode A runs Party Mode multi-agent discussion before creating a Story. Mode B skips discussion when a backlog stub already satisfies four completeness conditions. Mode C handles non-Story general tasks like batch corrections or documentation directly from the main window without BMAD workflows.

The lifecycle moves from dispatching to running, then reported when the worker Stop hook fires, awaiting-review after the controller calls ack_worker_run, and approved or revising after gate_worker_run. Approved runs are closed via close-worker.ps1, which writes the terminal CAS state before taskkill.

No. Worker windows never auto-close, and pipeline-guardian.ps1 only observes and flags stalled runs without killing anything. The only programmatic close path is close-worker.ps1, and direct taskkill calls are hard-blocked by worker-kill-guard.js for active runs.

Use the -Worktree flag on dispatch-general.ps1 for high-conflict-risk batches where multiple workers might race on the git index. It is opt-in per dispatch, keeps the control plane pinned to main, and does not solve semantic merge conflicts, which still require task splitting.

E1 relied on file-based ACK and Wait-WindowClosed, but worker-side ack reading and auto-close were removed, so every phase ended in a forced kill via Stop-WorkerSafe. This violated the notify-only rule, so E1 is frozen and batch needs are handled by sequential E2 dispatches.