> 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_14/prd_phase_14.md). # PRD Phase 14: Homepage And Core Product Story **Status**: Complete **Sessions**: 5 **Estimated Duration**: 10-20 hours **Progress**: 5/5 sessions (100%) *** ## Overview Build the core commercial product narrative for FactionOS. This phase turns the Astro foundation into a product website that immediately communicates: FactionOS is mission control for AI coding agents, a local-first observability and orchestration layer that turns Claude Code, Codex CLI, and compatible agent activity into a live command surface. The first viewport must be a strong FactionOS signal, not a generic SaaS hero. Visitors should see the cockpit and battlefield concepts quickly, understand the local-first loop, and have immediate paths to the demo and public docs. *** ## Progress Tracker | Session | Name | Status | Est. Tasks | Validated | | ------- | --------------------------------------- | -------- | ---------- | ---------- | | 01 | Hero Cockpit And Primary CTAs | Complete | \~18-24 | 2026-06-01 | | 02 | Battlefield Preview And Product Mockups | Complete | \~16-22 | 2026-06-01 | | 03 | Homepage Narrative Sections | Complete | \~18-24 | 2026-06-01 | | 04 | Product Overview Page | Complete | \~16-22 | 2026-06-01 | | 05 | Features And How-It-Works Pages | Complete | \~20-25 | 2026-06-01 | *** ## Completed Sessions * Session 01: Hero Cockpit And Primary CTAs completed on 2026-06-01. * Session 02: Battlefield Preview And Product Mockups completed on 2026-06-01. * Session 03: Homepage Narrative Sections completed on 2026-06-01. * Session 04: Product Overview Page completed on 2026-06-01. * Session 05: Features And How-It-Works Pages completed on 2026-06-01. *** ## Upcoming Sessions * None. Phase complete. *** ## Apex Workflow And Split Rules Each session must be expanded with `plansession` before implementation, then follow `plansession -> implement -> validate -> updateprd`. After all sessions in this phase complete, follow the Apex phase-transition cadence: `audit -> pipeline -> infra -> carryforward -> documents`, followed by manual QA and LLM audit before creating or starting the next phase. Split a planned session before implementation if: * The task checklist exceeds 25 tasks. * The objective includes two unrelated outcomes. * The session touches more than 2-3 packages. * The work needs both broad page creation and deep QA in the same session. * Legal/privacy owner review blocks completion inside the same 2-4 hour window. *** ## Objectives 1. Build a first-viewport homepage experience that makes the product category, brand, visual cockpit, and primary actions obvious on desktop and mobile. 2. Create reusable product-like visual components for battlefield, status, terminal, metrics, event streams, and local runtime flows. 3. Publish core product, features, and architecture pages that are accurate, concrete, responsive, and conservative about trust boundaries. *** ## Positioning Requirements Core message: * FactionOS is mission control for AI coding agents. * It is a local-first observability and orchestration layer for Claude Code, Codex CLI, and compatible agent events. * It turns sessions, prompts, tool calls, file touches, plans, approvals, outcomes, and optional collaboration signals into a live browser cockpit. Audience: * Engineering teams evaluating AI coding workflows. * Founders and technical leads running multiple coding agents. * AI platform and developer tooling teams. * Power users who need visibility, replay, guardrails, and local control. * Investors and press who need a crisp product overview and proof of category. Tone: * Tactical, specific, and technical. * Product-first and visual. * Avoid vague AI productivity claims. * Prefer concrete flows, screenshots, synthetic mockups, protocol boundaries, and operational language. Recurring proof points: * Local-first by default. * No hosted account required for the core workflow. * Claude Code and Codex CLI supported. * Generic event API for compatible producers. * Web cockpit with mission, roster, battlefield, replay, approvals, diagnostics, and settings surfaces. * Optional War Room collaboration. * Optional outbound Discord, Telegram, and generic HTTPS webhook adapters. * Synthetic demo is zero-install and separate from real local sessions. Copy guardrails: * Do not claim hosted collaboration is required. * Do not claim inbound external adapters control the local runtime. * Do not imply demo data is real user data. * Do not imply prompts or local file paths leave the machine by default. * Do not use unverifiable performance, revenue, adoption, or security claims. * Avoid generic phrases like "AI-powered productivity platform" unless paired with concrete product behavior. *** ## Information Architecture For This Phase Primary header items used by these pages: * Product * Use Cases * Features * How It Works * Security * Blog * News Primary actions: * Demo: `https://demo.faction-os.com/` * Docs: `https://faction-os.gitbook.io/faction-os-docs` Routes implemented or completed in this phase: * `/` * `/product` * `/features` * `/how-it-works` The pages must use shared navigation, metadata, responsive shell, footer, and demo/docs CTAs from Phase 13. *** ## Page Requirements ### Home: `/` Purpose: convert a first-time technical visitor into demo/docs exploration. Required sections: 1. Hero cockpit: * FactionOS brand and concise positioning. * Simulated terminal prompt. * 2D battlefield layout preview. * Primary CTA to the demo. * Secondary CTA to the public docs. 2. Live status panel: * Simulated local server status. * Active agents. * Events processed. * Mission state. 3. Observability battlefield preview: * Mission map with agent tokens, status rings, file/tool traces, and event stream. * Must look like a product interface, not an illustration-only banner. 4. Three-pillar value deck: * Observability. * Gamification. * Local-first. 5. How the loop works: * Hook events enter local server. * WebSocket stream updates cockpit. * Optional adapters notify external systems. 6. Security boundary callout: * Local-first by default. * No hosted account required. * No prompt/file/path upload by default. 7. Publishing preview: * Latest blog and latest news/changelog item. 8. Final CTA: * Demo and docs links in a tactical panel. Home acceptance: * First viewport clearly shows FactionOS and the product concept. * Demo and docs actions are visible without scrolling on desktop and mobile. * The hero does not use a generic split-card SaaS layout. * No text overlaps at common mobile widths. ### Product: `/product` Purpose: explain the complete product surface and where each capability fits. Required sections: * Product promise. * Surfaces: * Web cockpit. * Hook ingest. * CLI. * Protocol. * Optional War Room. * Outbound adapters. * Static demo. * Product screenshots or synthetic product mockups. * Local-first operating model. * Demo/docs CTA. ### Features: `/features` Purpose: provide a deeper product inventory. Feature groups: * Cockpit navigation and shell. * Live roster and mission feed. * Battlefield map. * Mission detail and replay. * Approvals and guarded actions. * File/tool timelines. * Prompt lifecycle visibility. * Diagnostics and settings. * Local orchestration deck. * Subagent lineage nodes. * Outbound adapters: * Discord. * Telegram. * Generic HTTPS webhooks. * Export and audit trail. Feature acceptance: * Feature descriptions are concrete and tied to product workflows. * Outbound adapters are described as outbound notification bridges, not inbound command channels. * Each feature group links to demo/docs where relevant. ### How It Works: `/how-it-works` Purpose: show the architecture simply and accurately. Required sections: * Visual pipeline: * Claude Code hooks. * Codex CLI hooks. * Compatible event producers. * Local `/event` API. * `apps/server`. * WebSocket stream. * `apps/web` cockpit. * Optional adapters and War Room. * CLI setup guide with example command panels: * `npm install` * `npm run dev` * `factionos init --cli claude` * `factionos init --cli codex` * `factionos init --cli all` * Local runtime requirements. * Trust boundary diagram. * Links to public docs. How-it-works acceptance: * Commands are clearly marked as examples. * The page does not replace full public docs. * Technical diagrams are responsive and accessible. *** ## Component Requirements This phase should complete or substantially use: * `HeroCockpit.astro` * `BattlefieldPreview.astro` * `LiveStatusPanel.astro` * `ThreePillarDeck.astro` * `FeatureMatrix.astro` * `FeatureBand.astro` * `PipelineDiagram.astro` * `TerminalWindow.astro` * `SecurityBoundary.astro` * `ExternalCta.astro` * `MetricStrip.astro` * `Panel.astro` * `ButtonLink.astro` All components should respect reduced motion, keyboard navigation, readable focus states, and responsive text wrapping. *** ## Technical Considerations ### Architecture Use structured data modules to keep copy and page structure maintainable: * `src/data/site.ts`: domain, demo URL, docs URL, default metadata, contact addresses/links. * `src/data/navigation.ts`: header nav, footer nav, and approved external links. * `src/data/features.ts`: feature groups and feature cards. * `src/data/use-cases.ts`: use-case summaries and routes if needed for home previews. * `src/data/faq.ts`: FAQ categories and questions if security/home excerpts need a shared source. * `src/data/roadmap.ts`: current, next, later, and shipped groups if home previews need direction. Keep long editorial content in Markdown/MDX collections, not large TypeScript strings. ### Risks * A visually rich homepage can become too decorative. Mitigation: every visual panel must show a product state, data flow, or trust boundary. * Architecture copy can become too deep. Mitigation: keep `/how-it-works` overview-level and link to public docs for exhaustive setup. * Adapter copy can imply inbound command support. Mitigation: call adapters outbound notification bridges only. * Continuous motion can create accessibility fatigue. Mitigation: implement reduced-motion behavior with static clarity preserved. ### Relevant Considerations * \[P03] Guarded actions are proposals and decisions only. Do not imply approved actions execute files, git, terminal, Docker, or remote work. * \[P07] Hosted services remain disabled-default guardrails only. Do not imply active hosted accounts or hosted analytics. * \[P05] War Room federation is optional and redacted. Do not describe it as hosted identity or broad public collaboration. * \[P10] Provider display for Claude Code and Codex CLI should stay aligned with protocol-backed naming and avoid raw payload leakage. *** ## Success Criteria Phase complete when: * [x] All 5 sessions completed. * [x] Homepage first viewport has brand, product concept, battlefield/cockpit visual proof, and demo/docs actions visible on desktop and mobile. * [x] Core product pages describe real product surfaces without generic SaaS copy. * [x] Technical diagrams are responsive, accessible, and do not replace full public docs. * [x] Reduced-motion behavior is implemented for continuous visual effects. * [x] Copy stays conservative about local-first, hosted, adapter, demo, and executor boundaries. *** ## Dependencies ### Depends On * Phase 13: Public Website Foundation. ### Enables * Phase 15: Trust, Content, And Conversion Pages. * Phase 16: Quality, Deployment, And Launch Handoff. --- # 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_14/prd_phase_14.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.