> 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/prd_phase_06.md). # PRD Phase 06: Collaboration, Isolation, and Mobile **Status**: Complete **Sessions**: 7 **Estimated Duration**: 7-14 days **Progress**: 7/7 sessions (100%) *** ## Overview Phase 06 turns the optional Worker-backed War Room and shipped local orchestration surfaces into a safer collaboration-ready cockpit without making core FactionOS depend on hosted accounts, hosted storage, analytics, public replay hosting, remote execution, or trusted erasure. This phase owns source-backed collaboration requirements, stronger room and participant authority, shared collaboration event contracts, collaborative cockpit UX, local isolation boundaries, sandbox diagnostics, mobile cockpit hardening, accessibility validation, and documentation closeout. Phase 06 must preserve the local-first boundary from Phases 01-05. The Cloudflare Worker remains optional external transfer. The local server remains the loopback runtime and must not become a War Room relay, hosted queue, or remote execution service unless a later approved threat model changes that boundary. Collaboration payloads must stay compact and redacted, and isolation work must not imply real file, git, terminal, Docker, or remote executors are available until separately designed, authorized, audited, tested, and documented. *** ## Progress Tracker | Session | Name | Status | Est. Tasks | Validated | | ------- | ------------------------------------------------------ | -------- | ---------- | ---------- | | 01 | Collaboration Requirements and Safety Baseline | Complete | \~14-20 | 2026-05-30 | | 02 | Room Authority and Participant Identity Contracts | Complete | \~16-24 | 2026-05-30 | | 03 | Shared Collaboration Event Contracts | Complete | \~16-24 | 2026-05-30 | | 04 | Collaborative Cockpit UX and Remote Context | Complete | \~16-24 | 2026-05-30 | | 05 | Isolation Boundary and Sandbox Diagnostics | Complete | \~14-22 | 2026-05-30 | | 06 | Mobile Cockpit and Accessibility Hardening | Complete | \~16-24 | 2026-05-30 | | 07 | Collaboration Isolation and Mobile Validation Closeout | Complete | \~12-18 | 2026-05-30 | *** ## Completed Sessions * Session 01: Collaboration Requirements and Safety Baseline - completed on 2026-05-30. * Session 02: Room Authority and Participant Identity Contracts - completed on 2026-05-30. * Session 03: Shared Collaboration Event Contracts - completed on 2026-05-30. * Session 04: Collaborative Cockpit UX and Remote Context - completed on 2026-05-30. * Session 05: Isolation Boundary and Sandbox Diagnostics - completed on 2026-05-30. * Session 06: Mobile Cockpit and Accessibility Hardening - completed on 2026-05-30. * Session 07: Collaboration Isolation and Mobile Validation Closeout - completed on 2026-05-30. *** ## Upcoming Sessions None. Phase 06 is complete. Phase 07 owns hosted services and analytics guardrails; Phase 08 owns release hardening, trusted erasure, production-hosted validation, mobile certification, and legacy decommission. *** ## Session 01 Outputs Session 01 creates the Phase 06 source-backed baseline artifacts: * `collaboration_isolation_safety_baseline.md` - collaboration, authority, redaction, isolation, sandbox, mobile, accessibility, local-first, and deferral baseline. * `phase06_requirement_routing_matrix.md` - requirement ownership for Sessions 02-07 plus Phase 07/08 deferrals. * `mobile_accessibility_acceptance_checklist.md` - viewport, keyboard, pointer, screen-reader, focus, reduced-motion, text-fit, no-overlap, visible error, and evidence acceptance checklist. Later sessions must use these artifacts as routing sources and may update them only with source-backed implementation evidence. ## Session 07 Closeout Evidence Session 07 records the Phase 06 validation closeout in `.spec_system/specs/phase06-session07-collaboration-isolation-and-mobile-validation-closeout/`. Recorded evidence includes: * Focused protocol, Worker, web, server, CLI, and hook validation: 24 files passed, 186 tests passed. * App desktop/mobile Playwright validation: 11 tests passed and 1 expected mobile skip after fixing the mobile Plan Workpad overflow found by the first browser run. * Repository gates: format, lint, workspace typecheck, full Vitest, workspace build, secret scan, media release gate, battlefield asset gate, and `git diff --check` passed. * Retained browser evidence under `test-results/e2e/` and HTML report under `playwright-report/`. * Security, privacy, documentation, README, and runbook closeout artifacts preserve Phase 07/08 deferrals. The browser evidence is local Playwright evidence with local server and mocked or same-origin Worker paths. It is not hosted identity proof, production-hosted validation, mobile or WCAG certification, analytics validation, remote execution validation, public replay hosting validation, or trusted unified erasure. *** ## Objectives 1. Reconcile collaboration, isolation, mobile, trust, redaction, and accessibility requirements into a Phase 06 routing baseline. 2. Replace hint-only room authority with signed or otherwise stronger participant, leader, approval, reconnect, and duplicate-action contracts while keeping hosted accounts deferred. 3. Define and implement compact collaboration event contracts for safe shared focus, presence, notices, handoff, and catch-up without transferring prompts, commands, transcripts, broad paths, exports, scans, media drafts, logs, or backups. 4. Improve the web cockpit collaboration UX so local-only, unavailable, remote context, member, observer, conflict, reconnect, and leave states are clear on desktop and mobile. 5. Define local isolation and sandbox boundaries for future executors, keep unsupported execution deterministic, and expose safe diagnostics without running commands or mutating workspace files. 6. Harden mobile cockpit layout, keyboard/pointer/screen-reader access, focus return, reduced motion, and no-overlap behavior for collaboration and core cockpit workflows. 7. Validate Worker, protocol, web, server, CLI, docs, security, privacy, mobile, and accessibility behavior with retained evidence and a clean Phase 07 handoff. *** ## Prerequisites * Phase 05 completed. * Phase 05 War Room closeout artifacts and security posture are available. * `packages/protocol`, `apps/warroom`, `apps/web`, `apps/server`, `apps/cli`, and `apps/hooks` current README files are reviewed before scoped changes. * Cloudflare credentials remain optional for core local workflows; tests must provide local, mocked, or documented Worker paths. * Hosted auth, hosted storage, analytics, public replay hosting, remote execution, Docker isolation, and trusted erasure remain out of scope unless explicitly routed to a later phase. *** ## Technical Considerations ### Architecture Protocol contracts lead cross-package collaboration work. Shared room, participant, authority, role, collaboration event, safe-frame, and blocked-field types should start in `packages/protocol`, then flow into `apps/warroom` and `apps/web`. The Worker remains the optional room relay. The local server remains the loopback runtime and `/warroom` compatibility/status stub. If Phase 06 needs local collaboration diagnostics, they must report compact posture and unavailable states without proxying Worker room traffic. Isolation work should define capabilities, unavailable states, and diagnostic envelopes before enabling execution. Any future file, git, terminal, Docker, remote, or hosted executor needs separate consent, authorization, audit, rollback, redaction, tests, and documentation before it can ship. The web cockpit owns the user-facing collaboration and mobile experience. It must keep the battlefield, mission log, roster, details, local orchestration, and War Room controls reachable without overlapping text or blank panels on supported desktop and mobile browser widths. ### Ownership Handoff * Session 02 owns room authority, participant identity, leader/member/observer roles, duplicate decisions, stale approvals, reconnect authority, and spoofing limits. * Session 03 owns shared collaboration event contracts, allowlists, blocked-field tests, sender exclusion, catch-up bounds, and remote-context payload minimization. * Session 04 owns collaborative cockpit UX, remote context visibility, local-only fallback, conflict/reconnect/leave states, and source-of-truth separation. * Session 05 owns local isolation boundaries, unavailable execution envelopes, server/CLI/hook diagnostics, and no-mutation evidence. * Session 06 owns mobile cockpit layout, keyboard, pointer, screen-reader, focus return, reduced motion, text fit, and no-overlap hardening. * Session 07 owns validation evidence, docs closeout, security posture, and Phase 07/08 residual-risk handoff. * Phase 07 owns hosted services and analytics guardrails. * Phase 08 owns trusted erasure, production-hosted validation, release hardening, and legacy decommission gates. ### Technologies * TypeScript contracts in `packages/protocol` * Cloudflare Worker, Durable Objects, WebSocket, Wrangler, and Worker tests in `apps/warroom` * React 18, Vite, TypeScript, Tailwind, Zustand, and browser fetch/WebSocket/localStorage APIs in `apps/web` * Express, WebSocket, local orchestration managers, diagnostics, and explicit unsupported-route envelopes in `apps/server` * Node CLI and dependency-light hook diagnostics in `apps/cli` and `apps/hooks` * Vitest, Testing Library, Playwright, Biome, npm workspace scripts, secret scan, ASCII/LF checks, and browser evidence capture ### Risks * Participant trust spoofing: signed authority, approval, reconnect, and duplicate-action behavior must be deterministic before broader collaboration claims. * External transfer leakage: collaboration events could expose prompts, paths, commands, transcripts, exports, scans, media drafts, diagnostics, logs, or backups without strict allowlists. * Scope bleed: hosted auth, hosted storage, analytics, public replay hosting, real executors, Docker isolation, remote execution, and trusted erasure belong to later approved phases. * Isolation ambiguity: diagnostics or UI could imply commands will execute when the product still only ships proposals and unavailable execution states. * Mobile regressions: dense cockpit controls can overlap, disappear, trap focus, or become pointer-only without dedicated mobile and accessibility validation. * Erasure claims: room leave/reset, diagnostics cleanup, and local storage reset are not trusted unified erasure. ### Relevant Considerations * \[P05] **Unified erasure still missing**: Phase 06 must not claim trusted deletion for Worker storage, browser hints, archives, memory, settings, replay, exports, diagnostics, logs, backups, or future hosted surfaces. * \[P03] **Real executors remain unimplemented by design**: file, git, terminal, remote, and container executors still need a separate threat model, authorization, audit log, tests, and docs before shipping. * \[P05-apps/warroom+apps/web] **War Room federation is optional and redacted**: stronger identity, broad hosted collaboration, mobile certification, and trusted erasure remain future work unless specifically scoped here. * \[P05] **Redaction is boundary-specific**: collaboration, Worker, diagnostics, replay, export, archive, adapter, backup, log, and future external-transfer payloads need explicit minimization. * \[P02-apps/web] **Responsive and accessibility debt**: future UI changes still need mobile, focus return, dialog semantics, reduced motion, contrast, and full accessibility validation. * \[P03-packages/protocol] **Protocol leads cross-package work**: shared contracts should be updated before server, web, hooks, adapters, Worker, or CLI code depends on new collaboration or isolation behavior. * \[P03] **Local-first boundary is architectural**: collaboration and isolation must degrade cleanly when Cloudflare, hosted services, public tokens, provider credentials, and analytics are absent. *** ## Success Criteria Phase complete when: * [x] All 7 sessions completed. * [x] Source-backed Phase 06 requirements, safety baseline, mobile acceptance criteria, and routing matrix exist. * [x] Room and participant authority contracts reduce hint-only trust without requiring hosted accounts or hosted storage. * [x] Collaboration event payloads are explicitly allowlisted, compact, redacted, bounded for catch-up, and covered by blocked-field tests. * [x] Web cockpit collaboration UX covers local-only, unavailable, remote context, member, observer, reconnect, conflict, disconnect, and leave states on desktop and mobile. * [x] Isolation boundaries and diagnostics are explicit, and unsupported execution remains deterministic without running file, git, terminal, Docker, remote, or hosted commands. * [x] Mobile, keyboard, pointer, screen-reader, focus, reduced-motion, and no-overlap behavior are validated with retained browser evidence. * [x] Security, privacy, API, architecture, environment, deployment, release, package README, and phase PRD docs describe shipped Phase 06 behavior and remaining deferred Phase 07-08 work. *** ## Dependencies ### Depends On * Phase 05: War Room Worker Integration ### Enables * Phase 07: Hosted Services and Analytics Guardrails * Phase 08: Release Hardening and Legacy Decommission --- # 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/prd_phase_06.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.