> For the complete documentation index, see [llms.txt](https://faction-os.gitbook.io/faction-os-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/phases/phase_20/session_04_campaign_executable_dispatch.md). # Session 04: Campaign Executable Dispatch **Session ID**: `phase20-session04-campaign-executable-dispatch` **Packages**: `packages/protocol`, `apps/server`, `apps/web` **Status**: Not Started **Estimated Tasks**: \~12-25 **Estimated Duration**: 2-4 hours *** ## Objective Make campaign dispatch run executable terminal and Git tasks while keeping planning-only tasks truthful. *** ## Scope ### In Scope (MVP) * Add executable payload support to campaign task inputs, drafts, responses, and queue records created from campaign tasks. * Route campaign task dispatch through `TaskExecutionCoordinator` for supported terminal and Git payloads. * Include execution run summaries in campaign dispatch responses. * Mark tasks without executable payloads as planning-only, pending, or blocked instead of dispatched. * Update campaign UI labels, rows, and task details to show executable readiness and execution links. ### Out of Scope * Parallel or dependency-graph campaign scheduling. * File, container, channel, template, or managed-agent campaign execution. *** ## Prerequisites * [ ] Sessions 02 and 03 completed and validated. * [ ] Campaign executable dispatch acceptance test defined before implementation starts. *** ## Deliverables 1. Campaign task contract updates, server dispatch behavior, queue linkage, UI state, and tests. 2. Replacement for old tests that asserted campaign dispatch only created queue records. *** ## Success Criteria * [ ] Campaign approve -> dispatch -> executable task run -> execution run -> task completed is proven for at least one terminal or Git task. * [ ] Tasks without payloads are not reported as dispatched or executed. * [ ] Partial failure does not falsely mark the whole campaign completed. * [ ] Campaign and queue rows link to the same execution evidence. * [ ] Focused protocol, server, web, e2e, and `git diff --check` commands for this slice pass. *** ## Folded Source Detail ### User Outcome A campaign task with an executable terminal or Git payload dispatches runnable work, records execution evidence, and keeps planning-only tasks visibly planning-only instead of falsely reporting them as dispatched or executed. ### Current Source Map * Campaign contract: `packages/protocol/src/orchestrationCommandCenter.ts` currently gives `CommandCenterPlanTask` campaign, dependency, owner, expected result, state, and verification fields, but no executable payload or execution result link. * Campaign behavior: `apps/server/src/managers/planCampaignManager.ts` and `apps/server/src/routes/commandCenter.ts` currently create legacy queue rows and mark plan tasks queued; they do not call Git, terminal, file, container, or agent executors. * Existing campaign tests assert the old bridge behavior and must be replaced where they conflict with real execution assertions. ### Required Changes * Add executable payload support to campaign task inputs, drafts, responses, and queue records created from campaign tasks. * Make `PlanCampaignTaskInput` accept an optional executable payload. * Update `PlanCampaignManager.buildCampaignDraft` to preserve executable payloads on tasks. * Route campaign task dispatch through `TaskExecutionCoordinator` for supported terminal and Git payloads. * Include execution run summaries in campaign dispatch responses. * Mark tasks without executable payloads as planning-only, pending, or blocked instead of dispatched. * Update campaign UI labels, rows, and task details to show executable readiness and execution links. * Serial execution is acceptable in this session; dependency graph scheduling belongs to Session 05. ### Recovery Paths * Validation failure blocks the executable task before runtime execution. * Policy-blocked Git requests return unavailable and do not run Git. * Failed terminal or Git tasks surface bounded failure detail and do not falsely complete the campaign. * Tasks without payloads stay planning-only and are not counted as executed. ### Acceptance Tests From Findings * Route test replaces the old campaign dispatch expectation and asserts campaign -> task executable -> dispatch -> execution run -> task completed for a successful Git or terminal task. * Partial failure campaign test proves one failed executable task does not falsely mark the full campaign completed. * Campaign approve -> dispatch -> executable task run -> execution run -> task completed is proven for at least one terminal or Git task. * Campaign and queue rows link to the same execution evidence. * Web tests prove Git or terminal execution result is visible from campaign and queue rows. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/phases/phase_20/session_04_campaign_executable_dispatch.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.