> 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_11_release_evidence_and_event_privacy.md). # Session 11: Release Evidence And Event Privacy **Session ID**: `phase20-session11-release-evidence-and-event-privacy` **Status**: Not Started **Estimated Tasks**: \~12-25 **Estimated Duration**: 2-4 hours *** ## Objective Prove all shipped orchestration paths end to end and align state, event, docs, and release claims with real behavior. *** ## Scope ### In Scope (MVP) * Complete the required protocol, server, web, and browser e2e matrix for terminal, Git, campaign DAG, file mutation, guarded actions, hero lifecycle, and channel/template intake. * Verify Command Center state semantics for queued, in progress, completed, blocked, failed, and unavailable across queue and campaign tasks. * Audit WebSocket events, broad rows, exports, diagnostics, examples, and docs for secret, terminal output, raw Git output, diff, file content, patch, token, absolute path, provider payload, and webhook body leakage. * Update documentation and release claims so unsupported features are explicitly unfinished rather than presented as production orchestration. * Run the focused completion commands and record any remaining unsupported paths. ### Out of Scope * Shipping any feature that lacks real execution, visible result, recovery, and automated proof. * Closing unrelated hosted identity, trusted erasure, production-hosted validation, or formal legal/privacy findings. *** ## Prerequisites * [ ] Feature slices included in the release claim completed and validated. * [ ] Release evidence test matrix updated before closeout. *** ## Deliverables 1. Green focused validation for all shipped paths, event/privacy hardening, and truthful documentation/release wording. 2. Explicit unsupported, proposal-only, approved-not-executing, or unavailable wording for any remaining executor families or dispatch paths. *** ## Success Criteria * [ ] Terminal, Git, file mutation, and supported managed-agent control each pass create -> dispatch or approve -> execute -> observe -> recover evidence in the product. * [ ] Campaign and queue states match actual execution outcomes and never complete from metadata-only work. * [ ] Required focused commands pass: protocol typecheck, server typecheck, web typecheck, `npm test`, the Command Center browser e2e, and `git diff --check`. * [ ] Release docs and UI labels use action verbs only for working actions. * [ ] Remaining unsupported executor families are clearly unavailable, proposal-only, or approved-not-executing. *** ## Folded Source Detail ### Product Outcome All shipped orchestration paths are proven end to end and release wording aligns with real behavior. A feature is not shipped from this plan unless the product outcome is proven with real execution, visible result, recovery path, and automated tests. ### Required Test Matrix | Path | Protocol tests | Server tests | Web tests | Browser e2e | | ----------------------- | --------------------------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------- | -------------------------------------------- | | Queue terminal | executable payload parser and event redaction | fake PTY success, `pty_unavailable`, timeout, kill/restart, duplicate dispatch | queue row result, terminal link, unavailable copy | queue create/dispatch/result/terminal drawer | | Queue Git | Git payload parser and path validation | fake Git runner success/failure/policy block | Git result from queue row | dispatch visible result | | Campaign executable DAG | task executable payload and response shape | dependency order, partial failure, retry failed, no-payload planning state | campaign graph execution states | campaign approve/dispatch/result | | File mutation | file mutation request/result parser | temp-dir mutation, backup, rollback, conflict, stale hash | preview/apply/rollback/conflict states | file task apply and rollback visible | | Guarded actions | capability states and run result parser | approve -> execution for Git/file/terminal, non-ready unavailable | capability matrix truthfulness | approve result visible | | Hero lifecycle | managed-session action parser | owned process stop/restart, observed-only unavailable/record-only | readiness-based button verbs | managed stop result visible | | Channel/template intake | executable task source parser | no auto-execute, idempotent replay, template executable survives | labels split review/create/execute | generated task dispatch result | ### Minimum Completion Commands ```bash npm --workspace packages/protocol run typecheck npm --workspace apps/server run typecheck npm --workspace apps/web run typecheck npm test npm run test:e2e -- --project=app-desktop tests/e2e/orchestration-command-center.e2e.ts git diff --check ``` Use narrower Vitest invocations during development, but a slice is not done until focused server, protocol, web, and browser evidence for that path is green. ### State And Event Requirements * Queue `queued`: has not started. * Queue `in_progress`: execution run is queued or executing. * Queue `completed`: execution run finished `executed`. * Queue `blocked`: validation, dependency, or approval blocks dispatch. * Queue `failed`: execution run finished failed. * Queue `unavailable`: capability was unavailable before or during dispatch. * Campaign task states should mirror queue semantics and keep dependency blocking explicit. * Campaign state should be `in_progress` while any executable task is running or queued, `completed` only when all dispatchable executable tasks finished and required verification passed, `blocked` when dependencies or approvals block progress, and `failed` when one or more required executable tasks failed and no retry is currently in flight. * WebSocket events must include compact updates for queue transition, execution run create/executing/complete, campaign task update, and campaign plan update. * Broad event rows must never include terminal command text, terminal output, raw Git output, diffs, file contents, patch bodies, tokens, secrets, broad absolute paths, provider payloads, or webhook raw bodies. ### Documentation And Release Requirements * Update documentation and release claims so unsupported features are explicitly unfinished rather than presented as production orchestration. * Release docs and UI labels use action verbs only for working actions. * Remaining unsupported executor families are clearly unavailable, proposal-only, or approved-not-executing. * Do not close unrelated hosted identity, trusted erasure, production-hosted validation, authorized Cloudflare deploy, or formal legal/privacy findings. ### Do Not Implement Around The Core Problem Allowed preparatory work is limited to protocol fields required by the vertical slice, one coordinator manager, parser and redaction tests, and UI changes needed to make the executable path visible. Disallowed as completion: * A new queue field that is never executed. * A campaign response that includes executable metadata but does not run it. * A file mutation preview without apply and rollback. * A capability probe that returns `executor_ready` without a passing runtime execution test. * An e2e test that only mocks a successful result without any server-side integration test proving execution. * A UI label change that still routes to metadata-only behavior. --- # 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_11_release_evidence_and_event_privacy.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.