> 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_06/collaboration_isolation_safety_baseline.md). # Phase 06 Collaboration, Isolation, And Safety Baseline **Phase**: 06 - Collaboration, Isolation, and Mobile **Session**: 01 - Collaboration Requirements and Safety Baseline **Status**: Baseline for Sessions 02-07 **Created**: 2026-05-30 *** ## Purpose This baseline is the source-backed contract for Phase 06 collaboration, participant authority, redaction, isolation, sandbox diagnostics, mobile readiness, accessibility, and local-first deferrals. It does not implement room authority, new collaboration events, cockpit UI changes, executor behavior, or hosted services. It routes those changes to later Phase 06 sessions or later phases. Phase 06 must preserve the current product boundary: * Core FactionOS remains local-first and works without Cloudflare, hosted auth, hosted storage, analytics, public replay hosting, media providers, Docker, remote runners, or provider credentials. * The Cloudflare Worker in `apps/warroom` remains optional external transfer. * The local Express server remains the loopback runtime and `/warroom` compatibility/status stub. It is not a Worker proxy and not a hosted room backend. * File, git, terminal, Docker, remote, and hosted execution remain unavailable unless a later approved threat model adds consent, authorization, audit, redaction, rollback, tests, and docs. * Leave, reset, diagnostics cleanup, browser storage reset, and CLI recovery are not trusted unified erasure. ## Source Evidence | Evidence area | Source anchors | Baseline conclusion | | ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Phase 06 scope | `.spec_system/PRD/PRD.md`, `.spec_system/PRD/PRD_UX.md`, `.spec_system/archive/phases/phase_06/PRD_phase_06.md`, this session spec and task list | Phase 06 owns collaboration requirements, stronger room authority, shared event contracts, cockpit UX, isolation diagnostics, mobile hardening, and closeout while keeping hosted services and erasure deferred. | | Phase 05 closeout | `.spec_system/specs/phase05-session07-war-room-validation-and-documentation-closeout/validation.md`, `IMPLEMENTATION_SUMMARY.md`, `.spec_system/SECURITY-COMPLIANCE.md`, `.spec_system/CONSIDERATIONS.md` | Optional Worker lifecycle, approval, presence, reconnect, bounded catch-up, sender-excluded federation, and local browser evidence are complete; hosted identity, mobile certification, production-hosted validation, analytics, remote execution, public replay hosting, and trusted erasure remain open. | | Redacted federation | `.spec_system/specs/phase05-session05-federation-event-redaction-and-cockpit-integration/validation.md`, `packages/protocol/src/warroom.ts`, `packages/protocol/tests/warroom.test.ts`, `apps/warroom/src/index.ts`, `apps/warroom/tests/warroom.test.ts`, `apps/web/src/lib/warRoomFederation.ts`, `apps/web/tests/warRoomFederation.test.ts` | Safe frames are protocol-owned, allowlisted, sender-aware, bounded for catch-up, and blocked-field checked before persistence, catch-up, diagnostics, logs, or browser consumption. | | Worker room lifecycle | `apps/warroom/README_warroom.md`, `apps/warroom/src/index.ts`, `apps/warroom/tests/warroom.test.ts`, `docs/runbooks/war-room-operations.md` | The Worker owns create, snapshot, join, approve, reject, socket, health, rate-limit, participant state, and recent-event behavior. Durable Object state is not trusted-erased today. | | Web room UX and state | `apps/web/README_web.md`, `apps/web/src/store/useWarRoomStore.ts`, `apps/web/src/components/WarRoomPanel.tsx`, `apps/web/src/lib/warRoomClient.ts`, `apps/web/src/lib/warRoomPresence.ts`, web War Room tests, `tests/e2e/app.e2e.ts` | The web panel handles local-only, unavailable, create, join, pending, approved, rejected, connected, reconnecting, caught-up, disconnected, left, diagnostics, duplicate action, and remote context states while keeping remote context out of local source-of-truth state. | | Local server and route boundary | `apps/server/README_server.md`, `apps/server/src/server.ts`, `apps/server/src/lib/unsupportedRoutes.ts`, `apps/server/tests/unsupportedRoutes.test.ts`, `docs/api/event-api-hook-contracts.md` | `GET /warroom` is status metadata only; Worker-style room routes on the local server return deterministic separate-surface 501 responses without echoing request bodies or sensitive data. | | Local orchestration and diagnostics | `.spec_system/archive/sessions/phase03-session07-orchestration-validation-and-documentation-closeout/validation.md`, `apps/server/tests/guardedActions.test.ts`, `apps/cli/README_cli.md`, `apps/hooks/README_hooks.md` | Guarded actions are proposals and decisions only. Approved actions produce unavailable or not-executed results when no safe executor exists. Diagnostics summarize counts and sanitized identifiers only. | | Mobile and accessibility | `.spec_system/PRD/PRD_UX.md`, `apps/web/README_web.md`, `tests/e2e/app.e2e.ts`, web component and helper tests | Local browser evidence exists, but Phase 06 must define and validate mobile certification, focus return, keyboard, pointer, screen-reader labels, reduced motion, text fit, no overlap, and visible error states for changed surfaces. | | Hosted and release deferrals | `docs/hosted-services.md`, `docs/deployment.md`, `docs/environments.md`, `docs/release.md`, `docs/privacy-and-security.md` | Hosted auth, hosted storage, analytics, push, public replay hosting, production-hosted app validation, release cleanup, decommission, and trusted erasure remain later work. | ## Collaboration Boundary Phase 06 collaboration has four distinct surfaces: 1. Optional Worker room transfer: the browser can use a configured Worker URL for room lifecycle, health diagnostics, join approval, participant presence, reconnect, bounded catch-up, and allowlisted redacted context. 2. Local-only cockpit workflow: the local server, web app, hooks, CLI, replay, export, settings, adapters, scans, media catalog, queue, guarded actions, mission graph, and local diagnostics remain useful when the Worker URL is empty, invalid, unreachable, timed out, rate-limited, or disabled. 3. Safe shared context: allowed collaboration data is compact participant metadata and protocol-validated presence, cursor, focus, hero state, mission state, and room notice frames. 4. Deferred hosted collaboration: account-backed identity, hosted storage, analytics dashboards, public replay hosting, push, production-hosted app validation, public sharing, inbound commands, remote execution, and trusted erasure are not Phase 06 Session 01 behavior. Local source-of-truth state stays local. Remote room context must not mutate local hero truth, mission truth, task queues, guarded-action proposals, replay buffers, exports, notifications, settings, adapters, scan state, media records, archives, memory findings, logs, backups, or localStorage identity hints. ## Participant Authority Requirements Session 02 owns implementation, but the requirements are fixed here: * Room authority must identify the room, leader, requester, approver, decision, and participant state with deterministic protocol shapes. * Leader, member, observer, and pending roles must be exhaustive and visible in Worker snapshots, web state, accessible labels, and tests. * Caller-supplied participant ids, names, colors, roles, and online flags are untrusted browser hints until a later hosted identity model proves otherwise. * Join approval must be leader-only. Non-leader decisions must return compact errors and must not leak request bodies. * Duplicate joins, duplicate approvals, duplicate rejections, stale decisions, reconnects, disconnects, and leave/reset flows must be idempotent or explicitly conflict-shaped. * Every state-mutating room action must guard duplicate triggers while in flight on the web side and revalidate the room snapshot on re-entry. * Reconnect must not revive stale approvals or remote context for absent or local participants. * Room trust cannot imply hosted account proof, production identity, release-grade audit, or trusted deletion. ## Redaction And Safe Collaboration Payloads Session 03 owns implementation, but the payload baseline is fixed here. Allowed Worker collaboration payloads: * Room codes, participant ids, display names, roles, colors, online flags, pending join metadata, timestamps, compact error codes, health state, rate limit metadata, deployment type labels, and safe lifecycle state names. * `warroom_presence` with bounded state and optional safe label. * `warroom_cursor` with unit coordinates. * `warroom_focus` with target type, bounded safe target id, and optional safe label. * `warroom_hero_state` with safe hero id, label, faction, allowlisted hero state, and unit coordinates. * `warroom_mission_state` with safe mission id, label, allowlisted mission state, and optional safe hero id. * `warroom_room_notice` with level, safe code, and bounded safe message. Required redaction and safety rules: * Unknown frame types, unknown fields, invalid enum values, non-finite coordinates, malformed participant ids, and blocked nested keys fail closed. * `ping` is allowed but must not be persisted. * Sender-excluded broadcast must remain the default for remote events. * Catch-up must use a bounded ring buffer and revalidate stored events before browser consumption. * Web summaries must show counts, timestamps, family labels, and visible safe status, not raw Worker payloads. * External dependency calls need bounded timeout and visible failure handling. Blocked collaboration payload categories: * Prompts and provider prompts. * File contents, file bodies, diffs, patches, broad paths, cwd, home paths, transcript paths, and workspace roots. * Command bodies, terminal output, stdout, stderr, shell history, and raw tool input previews. * Transcripts, assistant text, raw queue entries, proposal rationale, task details, and subagent raw payloads. * Secrets, tokens, API keys, authorization values, cookies, webhook URLs, OAuth identifiers, public client probes, account ids, and zone ids. * Exports, replay buffers, replay-share payloads, scan payloads, media drafts, diagnostics, PID files, spool entries, logs, backups, archives, memory findings, settings snapshots, quarantined historical content, and raw `EXAMPLES/` excerpts. Redaction remains boundary-specific. A payload safe for a Worker frame is not automatically safe for replay, export, archive, adapter, backup, log, hosted analytics, public replay, or release notes. ## Isolation And Sandbox Requirements Session 05 owns implementation, but the isolation posture is fixed here: * Current guarded actions remain non-executing proposals and decisions. Approval produces unavailable or not-executed results unless a later executor is deliberately added. * File, git, terminal, Docker, remote, and hosted executors are unavailable until a dedicated threat model defines capability scope, consent, authorization, audit log, rollback, idempotency, rate limiting, redaction, tests, documentation, and user-visible failure states. * Unsupported local routes must keep deterministic 501 envelopes with family, status, docs path, method, and normalized path only. They must not echo request bodies, prompts, commands, tokens, query secrets, or private path fragments. * CLI and hook diagnostics may report status labels, counts, durations, byte totals, stale PID state, malformed spool counts, and sanitized identifiers only. * Recovery remains explicit and narrow: stale listener PID files and malformed spool JSON only. It must not remove valid spool entries, settings, lifecycle state, archives, memory, browser state, Worker state, backups, or workspace files. * Docker isolation, remote access, hosted queues, inbound commands, and autonomous command execution remain later approved scopes. ## Mobile And Accessibility Requirements Session 06 owns implementation, and Session 07 owns final closeout evidence. Phase 06 changed surfaces must satisfy these acceptance categories: * Supported viewport widths: desktop, tablet-sized responsive widths, and mobile browser widths used by Playwright app projects. * Reachability: battlefield, mission list, roster, War Room, local orchestration controls, settings, dialogs, and error states remain reachable without hidden or clipped controls. * Keyboard: every actionable control has a native keyboard path or equivalent keyboard handler, visible focus, predictable focus order, and no pointer-only critical action. * Pointer: controls have stable hit targets, no accidental overlap, and no layout shift when state, labels, hover, loading, or errors change. * Screen reader: icon-only controls, rosters, pending joins, remote context, diagnostics, unavailable states, and dialogs have accessible names and relationships. * Focus return: dialogs, drawers, and overlays return focus to the invoking control where feasible and do not trap users after close or error states. * Reduced motion: optional animation, reconnect indicators, remote overlays, achievement bursts, replay, and battlefield motion honor reduced-motion settings while preserving meaning. * Text fit: long names, room codes, errors, labels, and action text wrap or truncate intentionally without clipping. * No overlap: mobile and desktop evidence must show no incoherent overlap between controls, panel text, battlefield labels, dialogs, and bottom rails. * Visible failures: Worker disabled, invalid URL, offline, timeout, rate-limited, malformed response, room full, room not found, stale decision, non-leader decision, catch-up failure, scan failure, local server offline, and unavailable execution are visible without console inspection. ## Deferrals The following are explicit deferrals and must not be described as shipped by Phase 06 Session 01: * Hosted account identity, hosted auth, hosted storage, hosted rooms, hosted queues, hosted analytics dashboards, push notifications, public replay hosting, public replay storage, and broad public sharing. * Strong account-backed participant proof unless Session 02 explicitly ships a non-hosted signed authority model and documents its limits. * Production-hosted app validation, mobile certification, release candidate smoke, decommission, and release-grade erasure. * Real file, git, terminal, Docker, remote, or hosted executors. * Inbound chat commands, generic inbound webhooks, remote agent spawning, browser-to-terminal command execution, and Worker command execution. * Trusted unified erasure for Durable Object state, browser hints, archives, memory, settings, replay buffers, exports, diagnostics, logs, backups, valid spool state, workspace files, and future hosted surfaces. ## Session Ownership Summary * Session 02 owns room authority and participant identity contracts. * Session 03 owns shared collaboration event contracts and blocked-field tests. * Session 04 owns collaborative cockpit UX and remote context separation. * Session 05 owns isolation boundary and sandbox diagnostics. * Session 06 owns mobile cockpit and accessibility hardening. * Session 07 owns validation closeout, evidence retention, docs sync, security closeout, and Phase 07/08 handoff. * Phase 07 owns hosted services and analytics guardrails. * Phase 08 owns release hardening, trusted erasure, production validation, and legacy decommission gates. --- # 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_06/collaboration_isolation_safety_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.