> 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/docs/architecture.md). # Architecture ## System Overview FactionOS is a local-first observability and control platform for AI coding CLI sessions - purpose-built to watch, understand, and command multi-agent workflows from a single cockpit. Observability (event streams, mission timelines, metrics, replay, audit) and active control (operator approvals, guarded actions, orchestration surfaces, mission steering, multi-agent coordination) are both first-class design goals. The current implementation is an npm workspace with a local Express and WebSocket server, a Vite React web client, provider-neutral hook handlers and source maps, a CLI installer, outbound adapters, a Cloudflare Worker room relay, and shared protocol types. The product requirements source is `docs/PRD.md`. This document describes what is implemented in the repository today and separates current behavior from planned phases. ## Dependency Graph ``` Provider-neutral hooks -> apps/hooks -> POST /event on apps/server -> packages/protocol event shapes -> apps/web WebSocket client apps/web -> HTTP and WebSocket on apps/server -> browser localStorage -> optional browser Notification API -> optional room-notice convergence through apps/server Notice Board routes apps/adapters -> apps/server WebSocket stream -> Discord, Telegram, or generic webhook endpoints apps/warroom -> Cloudflare Worker and Durable Object room relay -> optional apps/web War Room room lifecycle, diagnostics, and redacted federation -> optional Notice Board relay, resolution relay, and bounded catch-up public-demo -> standalone browser demo -> GitHub Pages workflow -> path-prefixed service worker cache for offline reload after one online visit public-website -> static front-facing faction-os.com website surface -> landing page, product story, blog/news, investor material, demo links, and public docs links ``` Phase 05 records the War Room requirements, trust, routing, and payload-redaction baseline in `.spec_system/archive/phases/phase_05/`. Current Worker and web integration consumes those artifacts for optional room lifecycle, diagnostics, approval, presence, reconnect, bounded catch-up, and allowlisted redacted federation. Broader hosted collaboration, trusted identity, and trusted erasure remain outside the current scope. ## Components | Component | Location | Current purpose | | ------------------------ | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Protocol | `packages/protocol` | Shared TypeScript types for events, REST, missions, heroes, notices, suggestions, command-center records, room participants, and local orchestration contracts. | | Server | `apps/server` | Express routes, WebSocket fanout, in-memory managers, local command-center and orchestration routes, diagnostics, LLM endpoints, local archive/export helpers, mock generator, and rate limiting. | | Web app | `apps/web` | React cockpit with roster, missions, details, Command Center workbenches, local orchestration controls, overlays, settings, replay, notifications, a derived game projection aggregate, and an asset-driven 2D battlefield. | | Hooks | `apps/hooks` | Dependency-light provider-neutral hook handlers, provider-specific source maps, and a per-terminal WebSocket listener. | | CLI | `apps/cli` | `factionos init`, `status`, `doctor`, and `uninstall` for local hook setup. | | Adapters | `apps/adapters` | Outbound bridges from the server WebSocket stream to Discord, Telegram, and generic HTTP webhooks. | | War Room Worker | `apps/warroom` | Cloudflare Worker and Durable Object backend for room creation, join approval, sockets, participant state, and bounded catch-up. | | Public demo | `public-demo` | Zero-install static demo and PWA shell, deployed by GitHub Pages. | | Public website | `public-website` | Static Astro source root for the main `faction-os.com` website: shipped home, product, features, how-it-works, blog, and news routes, plus phase-scoped conversion pages and links to `public-demo` and the public GitBook docs. | | Assets and media catalog | `assets`, app public dirs, `packages/protocol`, and `apps/web/src/data/mediaCatalog.ts` | Approved tracked showcase, generated references, typed catalog contracts, app media fixtures, public-demo media config, and runtime assets. Quarantined media remains in ignored `EXAMPLES/` as reference-only standards and gap evidence. | Phase 04 media ownership is routed by `.spec_system/archive/phases/phase_04/media_gap_matrix.md`. Current architecture keeps media ownership split by consuming surface: app runtime files stay under the app that loads them, public demo files stay in the standalone artifact, cross-surface references stay under `assets/`, and shared TypeScript catalog contracts live in `packages/protocol` when runtime packages need typed records. The matrix and catalog do not promote new media by themselves; they record source evidence, risk, owner session, status, and release blockers. Session 08 validated the current media gate stack, browser media behavior, public-demo offline behavior, and documentation closeout while preserving blockers for conditional and future media. Phase 02 closeout validates the browser-facing architecture through local Playwright projects for app desktop/mobile and public-demo desktop/mobile. That evidence covers the local app and static demo surfaces, not production hosted auth, hosted storage, analytics, or web-to-Worker federation. Phase 03 closeout routes local orchestration evidence through `.spec_system/archive/phases/phase_03/orchestration_gap_matrix.md`. Current source ships the approved local subset: non-executing task queue entries, source-owned agent templates, typed subagent lineage, in-memory mission graph frames, guarded action proposals and decisions with explicit unavailable results, web cockpit controls, CLI/hook/listener diagnostics, server diagnostics, and bounded local recovery for stale listener PID files plus malformed spool JSON. That Phase 03 subset did not ship hosted queues, trusted inbound command execution, analytics, Docker/container isolation, broad remote execution, future media release expansion, or release decommissioning. Phase 19 later adds the local proposal-first channel intake described in the Command Center section below. Phase 05 closeout records optional War Room Worker integration evidence in `.spec_system/archive/sessions/phase05-session07-war-room-validation-and-documentation-closeout/`. Current source ships the Worker relay, shared protocol contracts, web room lifecycle store, approval/presence/reconnect/catch-up controls, browser diagnostics, sender-excluded redacted federation, and remote overlays. The local server remains a compatibility/status stub for `/warroom`; it is not a room relay or proxy. Phase 06 Session 01 records the collaboration and isolation baseline in `.spec_system/archive/phases/phase_06/collaboration_isolation_safety_baseline.md` and the owner routing in `.spec_system/archive/phases/phase_06/phase06_requirement_routing_matrix.md`. Later Phase 06 implementation must keep protocol-led collaboration contracts, optional Worker transfer, local-server separation, unavailable executors, hosted-service deferrals, and non-erasure wording aligned with those artifacts. Phase 06 closeout records room-local authority, safe collaboration frames, remote-context UX, non-executing isolation diagnostics, and mobile/accessibility hardening in `.spec_system/archive/sessions/phase06-session07-collaboration-isolation-and-mobile-validation-closeout/`. The evidence is local Vitest and Playwright coverage with local server and mocked or same-origin Worker paths. It is not hosted account identity, production-hosted validation, mobile or WCAG certification, real executor approval, public replay hosting, analytics readiness, or trusted erasure. Phase 07 Session 01 records hosted-service guardrails in `.spec_system/archive/phases/phase_07/hosted_services_requirements_privacy_baseline.md`, `.spec_system/archive/phases/phase_07/phase07_requirement_routing_matrix.md`, and `.spec_system/archive/phases/phase_07/hosted_payload_privacy_blocklist.md`. Those artifacts route later work for hosted configuration, identity, persistence, public replay, analytics, push, remote access, diagnostics, validation, and Phase 08 release risks. They do not add hosted runtime dependencies. Phase 07 Session 03 adds protocol-first hosted identity guardrails in `.spec_system/archive/phases/phase_07/hosted_identity_authorization_guardrails.md` and `packages/protocol/src/hostedIdentity.ts`. Server and web consumers use those planned-state contracts for status-only diagnostics and helper copy. The architecture still has no hosted account runtime, OAuth redirect, Supabase auth client, account UI, organization management, billing, or persisted account state. War Room authority remains an optional Worker room proof, not account identity or production audit proof. Phase 07 Session 04 adds protocol-first hosted persistence and public replay guardrails in `.spec_system/archive/phases/phase_07/hosted_persistence_public_replay_boundaries.md` and `packages/protocol/src/hostedPersistence.ts`. Server and web consumers use those planned-state contracts for status-only diagnostics and helper copy. The architecture still has no Supabase client, database, bucket, migration, upload endpoint, browser direct storage write, account-backed persistence, public replay page, takedown runtime, release-grade deletion, or trusted erasure. Phase 07 Session 06 adds protocol-first hosted operation guardrails in `.spec_system/archive/phases/phase_07/push_remote_access_operator_diagnostics_guardrails.md` and `packages/protocol/src/hostedOperations.ts`. Server, CLI, and web consumers use those planned-state contracts for local diagnostics, loopback operator output, and browser helper copy. The architecture still has no Web Push delivery backend, push subscription endpoint, VAPID private key browser exposure, Cloudflare Tunnel runtime, remote access gateway, remote executor, hosted diagnostic agent, production-hosted validation, or trusted erasure. Phase 07 Session 07 closes out the phase. It validated the hosted-services and analytics guardrails end to end (20 focused test files / 183 tests, full suite 2186 passed / 1 skipped, format/lint/typecheck/build/secret-scan all green) and confirmed requirement closure for P07-R001 through R025. The architecture ships no new runtime in this session: hosted configuration, identity, persistence, public replay, analytics, push, remote access, and tunnels remain disabled, planned, or unavailable, and core local workflows run without hosted accounts or credentials. Production-hosted validation, trusted erasure, certification, and legacy decommission remain Phase 08. Phase 08 Session 01 adds documentation-only release baseline artifacts under `.spec_system/archive/phases/phase_08/`. They define release claim gates, requirement routing, risk ownership, and candidate-only decommission inputs for later sessions. They do not change the runtime architecture, activate hosted identity/storage/analytics/push/remote surfaces, validate production hosting, certify accessibility/mobile behavior, approve media promotion, or implement trusted erasure. Phase 08 Session 08 closed out the release-candidate evidence and docs sync in `.spec_system/archive/phases/phase_08/release_candidate_validation_record.md` and the matching session spec directory. That closeout confirms local release-gate evidence only; it does not upgrade any hosted, production, certification, or full trusted-erasure claims. Phase 09 closes out the provider-neutral Codex foundation in `.spec_system/archive/sessions/phase09-session01-contracts-and-naming-baseline/`, `.spec_system/archive/sessions/phase09-session02-hook-runtime-normalization/`, and `.spec_system/archive/sessions/phase09-session03-codex-hook-map-and-codex-specific-handlers/`. The shared protocol package is now the source of truth for `codex-cli`, `AGENT_HOOK_EVENT_NAMES`, Codex lifecycle names, compact safe ingest metadata, and the source-controlled Codex hook map while preserving the Claude compatibility path. ## Runtime Flow 1. A developer starts `apps/server` on port `2468` and `apps/web` on Vite port `5193`. 2. The CLI can merge FactionOS hook commands into Claude Code settings. 3. Hook scripts POST lifecycle, prompt, tool, file, permission, and subagent events to `POST /event`. 4. Agents and humans can post explicit Notice Board coordination through the CLI, local REST routes, WebSocket `post_notice`, hook context lookup, or automatic mission lifecycle notices. 5. The server updates in-memory managers, the persistent local Notice Board manager, and broadcasts typed events over `ws://127.0.0.1:2468/`. 6. The web client hydrates initial state, renders the cockpit, and persists selected settings, replay buffers, and the derived game projection aggregate to localStorage. 7. Adapters can subscribe to the same WebSocket stream and forward selected event summaries to external systems. 8. When a browser-safe Worker URL is configured, the web War Room panel can call `apps/warroom` directly for room lifecycle, health diagnostics, participant sockets, and allowlisted redacted federation. When the URL is blank, invalid, unreachable, timed out, or rate-limited, the local cockpit remains usable. 9. When the optional War Room relay is connected, safe Notice Board messages, resolutions, and catch-up frames can cross the Worker boundary while the local server remains canonical for local board state. ## Data Layer The current core has no production database requirement. | Data | Current storage | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Heroes, missions, scrolls, achievements | Server memory while the process runs. | | Command Center campaigns, tasks, attention, executor posture, file intents, workpads, evidence, verification, handoffs, channel commands, usage, and notification readiness | Server memory while the process runs, with compact local REST snapshots and WebSocket updates. Notification preference and readiness records stay local; hosted delivery remains inactive by default. | | Notice Board messages | Local `notice-board.json` under `FACTIONOS_HOME` or the injected server state root, with a 500-message cap, pruning, room scoping, and shutdown flush. | | Quest Board suggestions, issues, summaries, scan status, and dismissed IDs | Local `suggestions.json` under `FACTIONOS_HOME` or the injected server state root, with manager-owned validation, debounced atomic writes, startup load, corrupt-store recovery, and shutdown flush. | | Session archive and memory findings | Local files under the FactionOS home directory when runtime paths use those helpers. | | Web settings, replay buffer, and derived game projection aggregate | Browser localStorage. Projection storage uses `factionos-game-v1`, is guarded against replay/mock writes, and is cleared by browser-local erasure or reset. Scanner camps, Quest Board links, combat playback, live enemy display state, scrying hints, and alert focus state inside the projection are aggregate-only ids, safe labels, HP/tier/counters, cells, timestamps, and display-state fields. | | Room participants, recent room events, and filtered Notice Board relay history | Cloudflare Durable Object storage when `apps/warroom` is deployed and used. | | Session exports | User-downloaded CSV or JSON from \`GET | Hosted persistence remains planned or unavailable. Future hosted storage must be server-mediated by default for account, replay publish, takedown, export, deletion, or authorization-sensitive data unless a later accepted design proves a safer boundary. Current replay sharing remains a redacted local URL fragment and is not a public replay host. ## API Boundary `packages/protocol` is the source of truth for event and domain shapes. The current shipped HTTP and WebSocket surface is summarized in `docs/api/README_api.md`. The server intentionally returns `501` JSON for documented historical routes that are not wired in this build. That keeps unsupported routes explicit instead of silently looking like ordinary 404s. Notice Board is one of the protocol-led cross-package surfaces. Protocol owns notice types, priority values, REST shapes, event payloads, compatibility aliases, safe related-file normalization, and Worker relay frame validation. The local server owns canonical Notice Board state, persistence, filtering, targeting, context generation, resolution, automatic lifecycle posts, and optional local-to-Worker bridge sends. The web cockpit consumes hydrate, message, and resolve events after local normalization and target filtering. The CLI owns first-party agent commands for post, list, type-filtered list, context, and resolve. Hooks own bounded prompt-start context lookup and provider-safe output. The Worker owns optional external relay, resolution relay, and bounded catch-up for safe coordination notices only. The Notice Board is explicit coordination, not automatic raw telemetry. It may carry typed concise messages, display author metadata, target session ids, room code, timestamps, resolution state, and safe relative related files. It must not carry raw prompts, transcripts, terminal output, command bodies, file contents, secrets, tokens, absolute paths, logs, exports, replay buffers, scans, media drafts, diagnostics, backups, or quarantined historical content. Quest Board is another protocol-led cross-package surface. Protocol owns the typed suggestion, issue, summary, analysis, project scan, scan status, summary, REST, and `suggestion_update` event contracts. The local server owns `SuggestionManager` as the source of truth for active cards, dismissed IDs, freshness windows, persistence, summary counts, and mutation broadcasts. Engine write paths are manager-only: hero-idle lifecycle, session summaries, codebase scan orchestration, on-demand analysis, and project scan all validate their outputs before storing them, then emit canonical snapshots through the same WebSocket update path. Quest Board snapshots are delivered to new WebSocket clients after Notice Board hydration and before later cockpit hydration frames. REST mutations for accept, suggestion dismiss, issue dismiss, scan, analysis, and project scan also emit manager-owned snapshots. The web cockpit treats `suggestion_update` as the source of truth, keeps `idle_suggestion` only as compatibility input, renders typed multi-source cards, and calls local `/api/suggestions/*` routes for card actions and scan triggers. Accept and assign return prompt intent labels; they do not start real executors, Docker tasks, remote terminals, or codebase issue accept-as-quest work. Scanner camps now fold from the same `suggestion_update` path into the existing browser-local `GameProjection`. Phase 24 keeps that projection as the only derived game-state authority for camps, pending Quest Board prompt links, mission-bound links, live enemy display state, combat playback counters, scrying hints, and alert focus state. There is no parallel camp or combat store, protocol event, server route, hosted state, reward ledger, or storage key. The battlefield reads ranked camps and linked combat state from projection selectors; camp inspection opens the existing Quest Board issue set. Dry Banish calls the current issue-dismiss route and remains progress, reward, XP, loot, achievement, camp-kill, camp-damage, and Dawn Report inert. Replay, reconnect, and mock-mode guards prevent synthetic camp or combat progress from being written to durable projection storage. Full trusted erasure, hosted deletion, production-hosted validation, public-demo synthetic proof, and trusted public replay remain no-claim boundaries. The Phase 24 battlefield layers are React/CSS product presentation over selector output. `LiveLegionLayer`, `CombatPlaybackLayer`, and `ScryingAndAlertFocusLayer` do not fetch generated source assets directly. Generated Phase 3 sheets under `assets/generated/game-design/phase03/` stay in typed implementation-reference records and media catalog blockers until a later media promotion adds serving, slicing, optimization, fallback, accessibility, and privacy evidence. The Orchestration Command Center is the Phase 19/20 local control surface, with Phase 21 browser access through the bottom-rail Orchestration compact card and focused surface. Protocol owns the command-center DTOs, parser guards, event names, executor family vocabulary, channel command records, notification readiness records, executable queue summaries, and no-claim labels. The local server owns in-memory command-center state, capability snapshots, proposal-first channel/webhook intake, bounded File/Git workbench routes, terminal/container readiness gates, usage rollups, notification posture, collaboration posture, handoff scaffolds, and compact WebSocket updates. The web cockpit consumes those local snapshots in one mounted Orchestration panel implementation that can be shown as the compact bottom-rail card or promoted to the focused Command Center surface. Campaigns, Queue, File/Git, terminal runtime controls, Executors, Federation, Metrics, and adjacent-surface links live under that focused Orchestration path; retained summary/detail popups are secondary inspectors. The panel keeps scope filters, workbenches, keyboard shortcuts, adjacent-surface links, and duplicate-trigger guards aligned across compact and focused presentations. Channel intake can create queue, attention, or guarded proposal state for operator review, but it does not run trusted remote commands without a local conversion. Metadata-only queue rows still use local tracking state, while terminal, Git, file, and container queue executable rows dispatch only through their manager-owned local boundaries. Campaign dispatch uses the same task-queue execution boundary for tasks that carry private terminal, Git, file, or container executable payloads and leaves planning-only tasks visible. Observed Hero/Lineage controls record lifecycle intent only unless a supported managed controller is attached. File controls record intent, conflict, resolution, structured mutation evidence, and rollback metadata without exposing file contents. Git, terminal, and container controls execute only through explicit local readiness gates and bounded output paths; container queue/campaign dispatch uses compact isolated-spawn metadata rather than raw Docker commands, env, mounts, volumes, or output. Broad remote execution, hosted execution, Worker command bridges, remote access, and trusted unified erasure remain no-claim boundaries. War Room room APIs are not local server APIs. `GET /warroom` on the local server is compatibility/status metadata only, and Worker-style paths such as `/rooms/:code` or `/warroom/create` remain separate-surface route families unless a future PRD adds a local relay threat model. Shared room, participant, event, error, and redaction contracts must start in `packages/protocol` before `apps/warroom` or `apps/web` consume them. Phase 06 adds no local room relay. Any future authority, collaboration event, or isolation diagnostic change must preserve the current split: protocol owns shared contracts, the Worker owns optional room transfer, the local server owns loopback runtime and explicit unavailable or separate-surface responses, and the web cockpit owns visible local-only and remote-context UX. Phase 03 kept protocol first for shared queue, template, lineage, and guarded action shapes. Server, hook, CLI, and web packages consume the shipped subset through typed protocol contracts and focused tests. Remaining historical route families stay planned, unsupported, deferred, excluded, or separate-surface until a later approved session adds producers, handlers, authorization, redaction, tests, and docs. ## Optional Services Core local workflows do not require Anthropic, Cloudflare, Discord, Telegram, generic webhooks, Supabase, Umami, PostHog, hosted auth, or a database. Optional integrations are configuration-driven: * Anthropic transfer requires `ANTHROPIC_API_KEY` plus `FACTIONOS_ALLOW_LLM_PROVIDER_TRANSFER=true`; otherwise LLM engines use deterministic local fallbacks. * Cloudflare is needed only for `apps/warroom` deployment, the optional War Room custom domain `warroom.faction-os.com`, the public demo Pages deployment at `demo.faction-os.com`, and deployed Worker validation. Local app/server development does not require Cloudflare credentials or a Worker URL. * Discord, Telegram, and generic webhooks require operator-supplied credentials. * fal.ai, ElevenLabs, or later media providers are not runtime dependencies. Phase 04 draft generation treats provider output as non-runtime evidence until a later promotion closes source, rights, metadata, fallback, accessibility, privacy, and budget blockers. * Umami and Supabase are future/deferred hosted surfaces with PRD guardrails, not current required runtime dependencies. * Hosted identity is a planned-state contract only. Future account-sensitive operations must add provider flow design, token validation, consent, revocation, authorization, audit, abuse controls, tests, and local-only fallback before any account-backed architecture claim is made. * Hosted persistence and public replay are planned-state contracts only. Future storage or replay publication must add schema artifacts, migrations or bucket policies where applicable, RLS or authorization tests, consent, retention, export, deletion, takedown, no-index posture, abuse controls, audit, tests, docs, and local-only fallback before any active architecture claim is made. * Push, remote access, Cloudflare Tunnel, and hosted operation diagnostics are planned-state or unavailable contracts only. Browser notifications are local OS notifications; Web Push, VAPID backend use, remote access, tunnels, and hosted diagnostic agents require later explicit opt-in, authorization, redaction, rate-limit, Origin/CORS, audit, abuse-control, and validation scope before any active architecture claim is made. * Future hosted-sensitive operations should be server-mediated by default when they involve secrets, authorization, account data, storage writes, diagnostics, push, remote access, or public replay. ## Security Boundaries The current local server has useful caps but is not release-hardened. See `docs/SECURITY-COMPLIANCE.md` for the archived security posture and open findings. Important current boundaries: * Server JSON body limit is `2mb`. * Server and Worker rate limits default to 240 requests per 60 seconds. Cloudflare zone-level rate limiting is not currently added for the War Room custom domain because the single available zone rule slot is already used by `Leaked credential check`. * The local server binds to loopback by default, requires explicit opt-in for non-loopback binds, restricts default HTTP/WebSocket origins, and can require a local bearer token with `FACTIONOS_AUTH_TOKEN`. * Codebase scan limits approved roots, file count, file size, scanned extensions, ignored directories, symlinks, and returned root metadata. * Hook handlers are designed to be silent and timeout-bounded. * Notice Board context lookup is bounded and failure-to-no-context; manual and automatic notices are validated before mutation and safe related files must normalize to relative repository or worktree paths. * War Room Worker storage is bounded by participant and recent-event caps. * War Room Worker federation is optional external transfer. Current web integration sends only allowlisted redacted presence, focus, cursor, hero, mission, room-notice context, and safe Notice Board relay frames, filters catch-up frames, and keeps remote context out of local hero truth, replay persistence, exports, notifications, adapters, settings, and localStorage identity hints. * Prompt, path, command, token, URL, archive, export, replay-share, LLM, adapter, command-center, and channel/webhook redaction is in place for the current local surfaces. Future hosted, federation, analytics, and trusted remote-execution surfaces still need review before broad release. ## Current Gaps * War Room federation remains optional. Room-local authority, safe frames, and mobile-visible remote context are shipped, but hosted identity, trusted erasure, public replay hosting, broad inbound command execution, remote executors, and hosted storage remain future work. * Route-specific authorization and schemas cover current high-risk local routes, but future route families still need the same treatment when implemented. * Local retention and unified erasure controls for archives, memory, settings, and browser state remain release-hardening work. * Hosted auth, cloud persistence, and analytics are planned surfaces with guardrails, not current user-facing dependencies. * Phase 07 guardrails now define variable categories, blocked hosted payload categories, hosted identity planned-state contracts, and hosted persistence plus public replay planned-state contracts, and hosted operation contracts for push, VAPID, remote access, tunnels, and operator diagnostics. Hosted identity, hosted storage, public replay hosting, analytics, push delivery, remote access, Cloudflare Tunnel, hosted diagnostic agents, hosted diagnostics upload, and production-hosted validation remain unavailable as runtime behavior unless a later session adds source, tests, and docs. * Historical artifacts remain local intake until stable docs and release deletion gates cover their retained value. * Production hosted browser validation remains later hosted-service or release work; Phase 02, Phase 05, and Phase 06 evidence is local app/browser validation. * Local orchestration now ships the Phase 03 local subset, the Phase 19 Command Center, the Phase 20 evidence-backed local actionability slice, and the Phase 21 bottom-rail focused browser path. File/Git workbench routes, file mutation and rollback, bounded terminal sessions, local isolated-spawn previews/runs, queue and campaign executable dispatch, channel/webhook proposal intake with local conversion, metrics, notifications, and handoff/collaboration posture exist only inside the local command-center boundaries documented above. Hosted queues, shared queues, War Room command execution, hosted collaboration, broad inbound chat command execution, analytics dashboards, Docker isolation beyond the documented local readiness gates, broad remote execution, public sharing, and release decommissioning remain future phase work. * Phase 04 media gates are implemented, but conditional media blockers remain for portraits, brand, showcase, public-demo speech/music, generated references, generated drafts, unknown-provenance media, and quarantined historical intake. --- # 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/docs/architecture.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.