> 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_15/prd_phase_15.md). # PRD Phase 15: Trust, Content, And Conversion Pages **Status**: Complete **Sessions**: 6 **Estimated Duration**: 12-24 hours **Progress**: 6/6 sessions (100%) *** ## Overview Complete the remaining public website areas needed for trust, role-based conversion, durable publishing, company context, contact routing, roadmap clarity, FAQ coverage, and basic legal/policy surfaces. This phase turns the core product story into a full first-release website with every planned route present. The phase must keep copy conservative: local-first behavior is real, optional integrations are optional, outbound adapters are outbound-only, hosted services remain disabled by default unless explicitly shipped elsewhere, and legal pages must not appear final without owner/legal review. *** ## Progress Tracker | Session | Name | Status | Est. Tasks | Validated | | ------- | --------------------------------------- | -------- | ---------- | ---------- | | 01 | Use Cases Hub And Role Pages | Complete | \~20-25 | 2026-06-01 | | 02 | Security And Privacy Vault | Complete | \~18-24 | 2026-06-01 | | 03 | Blog And News Editorial Polish | Complete | \~14-20 | 2026-06-02 | | 04 | Company And Contact Pages | Complete | \~16-22 | 2026-06-02 | | 05 | Roadmap, FAQ, And Legal Pages | Complete | \~18-24 | 2026-06-02 | | 06 | Cross-Linking And Copy Consistency Pass | Complete | \~12-18 | 2026-06-02 | *** ## Completed Sessions * `phase15-session01-use-cases-hub-and-role-pages` - complete. * `phase15-session02-security-and-privacy-vault` - complete. * `phase15-session03-blog-and-news-editorial-polish` - complete. * `phase15-session04-company-and-contact-pages` - complete. * `phase15-session05-roadmap-faq-and-legal-pages` - complete. * `phase15-session06-cross-linking-and-copy-consistency-pass` - complete. *** ## Upcoming Sessions Phase 15 is complete. No upcoming sessions remain in this phase. *** ## 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. Create role-specific use-case routes and conversion paths for the main audiences. 2. Make local-first privacy and security posture a primary product feature with precise no-overclaim language. 3. Finish publishing, company, contact, press, roadmap, FAQ, and legal surfaces so the website is complete enough for launch hardening. *** ## Required Routes For This Phase * `/use-cases` * `/use-cases/engineering-teams` * `/use-cases/ai-platform-teams` * `/use-cases/founders` * `/use-cases/power-users` * `/security` * `/blog` * `/blog/[slug]` * `/news` * `/news/[slug]` * `/investors` * `/about` * `/contact` * `/press` * `/roadmap` * `/faq` * `/legal` * `/legal/privacy` * `/legal/terms` * `/legal/acceptable-use` Blog and news routes may already exist from Phase 13; this phase polishes them for launch. *** ## Page Requirements ### Use Cases: `/use-cases` Purpose: route visitors by role and problem. Required sections: * Use-case overview. * Cards for engineering teams, AI platform teams, founders, and power users. * Shared pain points: * Blind agent work. * Risky actions without review context. * Multi-agent coordination. * Privacy and credential concerns. * CTAs to the most relevant pages. Individual use-case pages: * Problem statement. * Workflow before/after. * Relevant FactionOS surfaces. * Proof points or concrete examples. * CTA to demo/docs. ### Security: `/security` Purpose: make local-first privacy a primary product feature. Required sections: * Trust manifesto. * Local-only data lifecycle. * What stays on the machine by default: * Prompts. * File paths. * Terminal output. * Local event snapshots. * Credentials. * Optional integration boundaries. * Redaction and consent guardrails. * Passive Settings status and strict telemetry blocks. * Analytics posture: * Absent by default. * If approved later, use the repository's Umami guardrail posture. * Never collect prompts, local paths, replay data, demo payloads, terminal output, credentials, or user-provided code. * Security FAQ. Security acceptance: * Security claims are precise and do not overpromise. * Hosted features are described as optional and boundary-aware. * Full trusted erasure, hosted identity, production-hosted validation, formal certification, and broad media readiness are not claimed unless separately proven. ### Blog: `/blog` and `/blog/[slug]` Purpose: long-form product thinking and technical essays. Content types: * Agent observability essays. * Local-first architecture decisions. * Gamification design. * Product launch posts. * Technical explainers. List page: * Featured post. * Tag filters or tag links. * Date and reading time. * Cross-link to `/news`. Post page: * Title, description, date, updated date, tags. * Canonical metadata. * Open Graph image. * Author or team attribution. * Previous/next or related posts if useful. ### News: `/news` and `/news/[slug]` Purpose: durable changelog, release notes, company updates, and press announcements. List page: * Latest release/changelog item. * Categories: * Release. * Changelog. * Company. * Press. * RSS inclusion. Post page: * Release notes or announcement format. * Links to docs, demo, or related blog posts. ### Investors: `/investors` Purpose: provide high-signal context without exposing private financial data. Required sections: * Category thesis. * Product wedge. * Market problem. * Differentiation: * Local-first observability. * Provider-neutral protocol. * Developer cockpit. * Optional collaboration path. * Contact CTA. Keep this page polished but conservative. Do not include unverifiable metrics. ### About: `/about` Purpose: explain why FactionOS exists. Required sections: * Mission. * Product principles. * Local-first stance. * Who it is for. * Links to docs, demo, and contact. ### Contact: `/contact` Purpose: route contact intents without server-side form handling. First-release implementation: * Use `mailto:` links or owner-approved external contact links. * Segment contact reasons: * Product/demo. * Security. * Press. * Investors. * Partnerships. Do not add a hosted contact form until spam protection, retention, and privacy handling are designed. ### Press: `/press` Purpose: make brand assets and company facts available. Required sections: * Boilerplate. * Product summary. * Brand assets. * Screenshots/showcase assets. * Press contact. * Links to recent announcements. Use processed image previews but provide downloadable files from `public/press/` when needed. ### Roadmap: `/roadmap` Purpose: show direction without promising exact delivery dates. Required sections: * Current focus. * Near-term themes. * Later themes. * Recently shipped, linked to `/news`. * Guardrail note that roadmap items may change. ### FAQ: `/faq` Purpose: answer purchase, technical, privacy, and demo questions. Categories: * Product. * Setup. * Privacy and security. * Demo and docs. * Integrations. * Teams and hosted options. ### Legal: `/legal/*` Purpose: provide basic legal/policy surfaces for launch. Pages: * `/legal`: index and policy list. * `/legal/privacy`: privacy policy page. * `/legal/terms`: terms placeholder or terms page, depending on legal review. * `/legal/acceptable-use`: acceptable use policy placeholder or page. Legal content must be owner/legal-reviewed before launch or clearly marked as pre-review. *** ## Data Modules Use 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, approved external links. * `src/data/features.ts`: feature groups and feature cards. * `src/data/use-cases.ts`: use-case summaries and routes. * `src/data/faq.ts`: FAQ categories and questions. * `src/data/roadmap.ts`: current, next, later, shipped groups. Keep long editorial content in Markdown/MDX collections, not large TypeScript strings. *** ## Technical Considerations ### Architecture This phase should use the static Astro foundation from Phase 13. Pages should remain static `.astro` routes unless a content collection or data module gives clear value. Contact must avoid server-side form handling for the first release. Legal pages may start as static pages with explicit review markers. ### Privacy And Security * No analytics by default. * No trackers. * No hosted form submission. * No client-side code that sends page data to third parties. * Contact flows use `mailto:` or owner-approved external destinations. * Do not collect prompts, local paths, replay data, demo session payloads, terminal output, credentials, or user-provided code. ### Risks * Security page overpromises. Mitigation: tie claims to local-first defaults and explicitly separate optional/future surfaces. * Investor page overstates traction. Mitigation: no unverifiable metrics. * Legal content looks final without review. Mitigation: clear review marker or owner-approved copy before launch. * Contact page introduces data retention obligations. Mitigation: `mailto:` or approved external destinations only. ### Relevant Considerations * \[P06-S07-HOSTED-IDENTITY] Room-local Worker authority is not hosted account identity. Keep that distinction in security and teams copy. * \[P06-S07-ERASURE] Full trusted unified erasure remains no-claim. Do not imply the website changes this. * \[P06-S07-HOSTED-VALIDATION] Production-hosted app validation remains no-claim until proven. Marketing copy must not imply deployed app-shell validation. * \[P07] Analytics capture remains disabled by default and must not become a first-release website feature. * \[P04] Media promotion gates remain active for press and showcase assets. *** ## Success Criteria Phase complete when: * [ ] All 6 sessions completed. * [ ] Every planned first-release website area has a route. * [ ] Security and privacy claims are precise, conservative, and local-first. * [ ] Contact flows do not require server-side form handling. * [ ] Legal pages are owner-reviewed or clearly marked for review before launch. * [ ] Blog/news surfaces are credible enough to validate production templates. * [ ] Cross-linking, navigation, footer, CTAs, and no-claim copy are consistent across the whole site. *** ## Dependencies ### Depends On * Phase 13: Public Website Foundation. * Phase 14: Homepage And Core Product Story. ### Enables * 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_15/prd_phase_15.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.