> 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_05/war_room_payload_redaction_baseline.md). # War Room Payload Redaction Baseline **Phase**: 05 - War Room Worker Integration **Session**: 01 - War Room Requirements and Trust Baseline **Status**: Transfer and minimization baseline **Last Updated**: 2026-05-29 *** ## Purpose War Room federation is optional external transfer through the Cloudflare Worker and Durable Object surface. This baseline defines what may cross that boundary, what must never cross it by default, and which later Phase 05 sessions own runtime enforcement. The current Worker accepts unknown socket event payloads and stores them in a recent-event ring buffer. That is acceptable as historical source evidence, but it is not sufficient for web cockpit integration. Before the web panel sends real cockpit events, Sessions 02 and 05 must add shared schemas, validation, drop/reject behavior, and focused tests. ## Boundary Principles * Fail closed. Unknown event types and unknown fields must be rejected or dropped before Worker persistence, catch-up, logs, diagnostics, or browser consumption. * Minimize before transfer. Send compact state needed for collaboration, not local developer data. * Redaction is boundary-specific. Worker-safe does not mean export-safe, replay-safe, log-safe, analytics-safe, or public-share-safe. * Preserve local-first operation. No core cockpit workflow may require Cloudflare credentials, hosted auth, hosted storage, analytics, public replay hosting, media provider transfer, or external transfer. * Do not claim trusted deletion. Phase 08 owns unified erasure for room data, browser hints, logs, exports, archives, backups, and future hosted records. ## Allowed Room Management Payloads These fields may cross the Worker boundary after Session 02 validates shape, length, enum, and authorization: | Category | Allowed fields | Notes | | ------------------------- | ------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Room code | `code` | Six-character Worker room code from the approved alphabet. | | Room timestamps | `createdAt`, bounded event timestamps | ISO strings generated by trusted runtime where possible. | | Participant identity hint | `id`, `selfId`, `requesterId`, `leaderId` | Opaque bounded ids only. Do not encode local usernames, paths, tokens, or transcript ids. | | Participant display | `name`, `requesterName`, `color` | Presentation hints only; not authority. | | Participant role | `leader`, `member`, `observer`, `pending` | Role changes require Worker-side authorization. | | Presence | `online`, connected/disconnected state | Presence is operational status, not account identity. | | Approval state | pending, approved, rejected, stale, conflict | Deterministic error and event contracts required. | | Health and diagnostics | health ok, service id, retry-after, rate-limit counters | Diagnostics must avoid request bodies and sensitive local payloads. | ## Allowed Collaboration Event Payloads Session 05 may define a narrow allowlist for redacted cockpit collaboration. Candidates are allowed only after shared protocol schemas and tests exist: | Event family | Allowed shape | Notes | | ------------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------ | | Participant roster change | participant ids, display names, roles, colors, online flags | No local auth tokens, account identity, email, or raw storage keys. | | Ghost hero overlay | participant id, bounded hero id, display label, faction, coarse state, normalized battlefield position | No prompt, command, transcript, file path, or mission body. | | View or selection hint | participant id, selected local object id, compact object kind | Prefer opaque ids and short labels; never include local paths or raw descriptions. | | Room notice | bounded status code and short safe copy | No raw exception, stack, request body, command output, or provider response. | | Reconnect catch-up marker | sequence, timestamp, allowed event payload | Applies the same allowlist as live events. | | Sender exclusion metadata | `from`, `eventId`, `sequence` | `from` must be Worker-derived or revalidated, not trusted from client payload alone. | These candidates are not approved for broad use until Session 05 ships runtime validators and tests. Until then, the web panel must not send real cockpit payloads through the Worker. ## Non-Transferable Categories The following categories are blocked from Worker federation by default: | Category | Examples | Required handling | | ------------------- | ------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | Prompts | user prompts, provider prompts, mission prompt summaries, generation prompts | Drop or replace with stable redacted marker before transfer. | | File contents | source text, snippets, diffs, patches, scan file bodies | Never include in Worker events. | | Command bodies | shell commands, git commands, CLI arguments, planned executor commands | Never include in Worker events. | | Terminal output | stdout, stderr, logs, stack traces, process output | Never include; diagnostics use compact status codes. | | Transcripts | transcript paths, transcript text, session logs, chat turns | Never include in Worker events. | | Secret values | API keys, bearer tokens, cookies, OAuth ids, webhook URLs, provider keys | Reject and fail validation if detected. | | Broad paths | home paths, workspace roots, absolute paths, transcript paths, generated output paths | Use no path by default; if future scope needs path context, use approved relative labels only. | | Exports | CSV/JSON export bodies, export URLs, export fragments, export schema payloads | Keep local; do not federate. | | Replay buffers | replay share fragments, replay events, URL hashes, local replay state | Keep local; do not federate. | | Media drafts | generated images/audio/video, provider outputs, source prompts, draft manifests | Keep non-runtime until media promotion gates pass. | | Scan payloads | scan roots, file lists with sensitive paths, issue bodies, scanned content | Keep local; do not federate. | | Local diagnostics | PID files, spool entries, backups, local logs, lifecycle files | Keep local and redacted in diagnostics only. | | Hosted account data | future auth claims, emails, profile ids, storage keys | Deferred until hosted identity scope defines consent and erasure. | ## Catch-Up Rules The Worker currently keeps a recent-event cap of 100 events. Future catch-up must preserve that bound and add these constraints: * Catch-up frames use the same allowlist as live frames. * Unknown or malformed frames are dropped before persistence and therefore cannot appear in catch-up. * Catch-up must not replay raw local WebSocket frames from the local server. * Catch-up must not replay browser replay buffers or exported session data. * A reconnecting participant must be reauthorized before receiving catch-up. * UI must report catch-up unavailable or failed without exposing raw payloads. ## Replay, Export, Log, And Diagnostics Adjacency * Replay state remains local browser state. War Room events must not include replay buffers, replay share fragments, or replay URL hashes. * Session exports remain local downloaded artifacts. War Room events must not include export bodies or generated download links. * Logs and diagnostics may record compact status, counts, durations, and error codes. They must not record raw Worker event bodies, prompts, commands, terminal output, secret values, broad paths, or stack traces. * Browser toasts and error copy may include stable error codes such as `room_not_found`, `room_full`, `awaiting_approval`, `rate_limited`, or `worker_unavailable`; they must not echo request bodies. ## Enforcement Ownership | Session | Enforcement responsibility | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | Session 02 | Shared Worker REST/WebSocket schemas, error envelopes, participant authority, and Worker-side validation. | | Session 03 | Web state store that sends only typed client requests and preserves local-only mode when Worker configuration is absent. | | Session 04 | UI duplicate-action guards, stale state handling, pending/rejected copy, reconnect authorization, and catch-up state presentation. | | Session 05 | Redacted collaboration event allowlist, drop/reject tests for blocked categories, sender-exclusion cockpit updates, and replay/export/log adjacency checks. | | Session 06 | Diagnostics and deployment docs that expose health/rate-limit status without sensitive payloads. | | Session 07 | End-to-end validation and privacy/security closeout evidence. | ## Acceptance Checklist * [ ] Worker validators reject unknown event types before persistence. * [ ] Worker validators reject or strip unknown fields from known event types. * [ ] Blocked categories have focused tests. * [ ] Catch-up frames are bounded and allowlisted. * [ ] Browser UI makes external transfer optional and visible. * [ ] Docs avoid claiming local redaction is public-share safety. * [ ] No Phase 05 docs claim unified erasure for Worker room data. --- # 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_05/war_room_payload_redaction_baseline.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.