Part of #5. Depends on F1 (#12).
Why
A recipe director (no LLM agent) must start a coordinator run from the app, but today orchestration.run is CLI-only — the only caller is src/cli/handlers/orchestration.ts:462, and there is no window.api.orchestration binding in the renderer (confirmed). The current LLM director only ever starts runs because the agent types orca orchestration run inside the worktree.
What
- Add a preload/IPC binding exposing
orchestration.run (and orchestration.taskCreate) to the renderer, so RecipeDirectorBackend can compile a recipe → tasks → run without an agent.
- The RPC method already exists (
orchestration-gates.ts:44); this is wiring it through the preload API (src/renderer/src/web/web-preload-api.ts) + types.
- Consider whether the run should be triggered from main directly at recipe-director launch instead of round-tripping through the renderer — decide alongside F3 (lifecycle owner).
Verdict from investigation
Additive (~preload binding). The loop still lives in main, so a renderer reload won't kill it; an app restart is handled by F3.
Part of #5. Depends on F1 (#12).
Why
A recipe director (no LLM agent) must start a coordinator run from the app, but today
orchestration.runis CLI-only — the only caller issrc/cli/handlers/orchestration.ts:462, and there is nowindow.api.orchestrationbinding in the renderer (confirmed). The current LLM director only ever starts runs because the agent typesorca orchestration runinside the worktree.What
orchestration.run(andorchestration.taskCreate) to the renderer, soRecipeDirectorBackendcan compile a recipe → tasks → run without an agent.orchestration-gates.ts:44); this is wiring it through the preload API (src/renderer/src/web/web-preload-api.ts) + types.Verdict from investigation
Additive (~preload binding). The loop still lives in main, so a renderer reload won't kill it; an app restart is handled by F3.