> 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_16/prd_phase_16.md). # PRD Phase 16: Quality, Deployment, And Launch Handoff **Status**: Complete **Sessions**: 5 **Estimated Duration**: 10-20 hours **Progress**: 5/5 sessions (100%) *** ## Overview Harden the static Astro website for launch, verify accessibility, responsive behavior, performance, metadata, feeds, privacy boundaries, automated checks, and Cloudflare Pages deployment, then leave a clear launch evidence trail and carry-forward decision. This phase should not add new product surface area. It should make the already built website safe to deploy at `https://faction-os.com/` while keeping the demo at `https://demo.faction-os.com/` and the public docs at `https://faction-os.gitbook.io/faction-os-docs`. *** ## Progress Tracker | Session | Name | Status | Est. Tasks | Validated | | ------- | --------------------------------------- | -------- | ---------- | ---------- | | 01 | Responsive And Accessibility Hardening | Complete | \~18-24 | 2026-06-02 | | 02 | Performance And Image Optimization | Complete | \~14-20 | 2026-06-02 | | 03 | Automated Checks And Build Gates | Complete | \~16-22 | 2026-06-02 | | 04 | Cloudflare Pages Deployment Path | Complete | \~16-22 | 2026-06-02 | | 05 | Launch Review And Documentation Handoff | Complete | \~12-18 | 2026-06-02 | *** ## Completed Sessions * Session 01: Responsive And Accessibility Hardening * Session 02: Performance And Image Optimization * Session 03: Automated Checks And Build Gates * Session 04: Cloudflare Pages Deployment Path *** ## Upcoming Sessions * Session 05: Launch Review And Documentation Handoff *** ## 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. Verify and fix responsive layout, keyboard navigation, contrast, semantics, focus, reduced motion, and mobile behavior across the complete website. 2. Optimize images, CSS, fonts, static payload size, and build gates without weakening the tactical visual direction. 3. Configure, validate, and document the static Cloudflare Pages deployment path and launch evidence. *** ## Accessibility And Responsive Requirements Baseline: * Valid semantic landmarks: `header`, `nav`, `main`, and `footer`. * Skip link to main content. * One `h1` per page. * Heading levels in order. * Keyboard-visible focus for all links and controls. * Accessible names for external links, icon buttons, and preview controls. * Color contrast minimum `4.5:1` for body text. * Do not rely on color alone for state. * Respect `prefers-reduced-motion`. * Product mockups must be semantic HTML or have useful alt text and nearby explanatory text. * Responsive text must wrap cleanly and never overlap at mobile widths. Viewport validation: * 360px mobile. * 768px tablet. * 1280px desktop. * 1440px or wider desktop. Responsive rules: * Grids transition from three-column desktop layouts above 1024px to single-column stacking on mobile. * Text uses standard `rem`/`em` sizing, wraps cleanly, and avoids viewport-width font scaling. * Long text and code-like content should use `word-wrap: break-word;` and `overflow-wrap: break-word;` where needed to prevent overlap. * Product previews preserve 16:9 when appropriate or swap to mobile workpads without clipping actions. * No hero, button, card, panel, nav, or footer text overlaps or spills outside its container. *** ## Privacy And Security Requirements * No analytics by default. * No trackers. * No hosted form submission. * No client-side code that sends page data to third parties. * External links to demo and public docs are explicit. * Any third-party font loading is documented before launch and should be replaced with self-hosted fonts if privacy review requires it. * Contact flows use `mailto:` or owner-approved external destinations. * The website must not collect prompts, local paths, replay data, demo session payloads, terminal output, credentials, or user-provided code. * Security page copy clearly distinguishes core local workflow, optional integrations, and future hosted surfaces. *** ## Testing And Verification Commands Run from repo root: ```bash npm install npm run format:check npm run lint npm run typecheck npm --workspace @factionos/public-website run typecheck npm --workspace @factionos/public-website run build npm run build ``` Run local preview: ```bash npm --workspace @factionos/public-website run dev npm --workspace @factionos/public-website run preview ``` Manual QA checklist: * Header navigation works on desktop and mobile. * Demo and docs external links open correctly. * Every planned page returns a 200 in local preview. * Blog/news post pages render from content collections. * RSS feed returns valid XML. * Sitemap includes public pages and excludes drafts. * Robots references the sitemap. * Keyboard focus order is logical. * Visible focus states are present. * Mobile nav can be opened and closed with keyboard. * Reduced-motion preference disables continuous motion. * Text does not overlap at 360px, 768px, 1280px, and wide desktop. * Images load, have useful alt text, and are not distorted. * Open Graph metadata is present. * No analytics or tracking requests are introduced. *** ## Deployment Requirements First release deploys a static Astro build to Cloudflare Pages, matching the existing Cloudflare posture for the demo while keeping website and demo artifacts independent. Recommended CI/deploy shape: ```bash npm ci npm --workspace @factionos/public-website run typecheck npm --workspace @factionos/public-website run build npx wrangler pages deploy public-website/dist \ --project-name=factionos-public-website \ --branch=main \ --commit-hash="$(git rev-parse HEAD)" \ --commit-message="$(git log -1 --pretty=%s)" ``` Cloudflare Pages dashboard settings: * Root directory: `public-website`. * Build command: `npm run build`. * Build output directory: `dist`. * Production domain: `https://faction-os.com/`. Do not add `@astrojs/cloudflare` for the initial static site. Astro's Cloudflare adapter is for on-demand/server-rendered routes and is not needed when Astro prerenders the whole site. If the website later needs server actions, sessions, dynamic personalization, form handling, or Cloudflare bindings, re-evaluate a Cloudflare Workers deployment and add the adapter then. *** ## Launch Gates The website is launch-ready when: * All required pages exist. * Homepage first viewport strongly communicates FactionOS. * Demo and docs CTAs are visible and correct. * Product, feature, how-it-works, and security pages are complete. * Blog and news collections work with RSS. * Sitemap and robots are generated. * All indexable pages include metadata. * Draft posts are excluded from production. * Accessibility pass is complete. * Responsive pass is complete. * No runtime analytics or forms are present. * Legal/privacy copy has owner approval or is clearly marked as pre-review. * Cloudflare Pages build succeeds from a clean install. * Static output is deployable from `public-website/dist`. *** ## Post-Launch Backlog Do after the first static launch, not before: * Self-host production font files if initial implementation used third-party font loading. * Add generated social image pipeline if manual Open Graph images become hard to manage. * Add search if blog/news volume grows. * Add tag archive pages if content volume justifies them. * Add a CMS only after publishing workflow needs exceed Markdown/MDX. * Re-evaluate analytics with the existing Umami guardrail posture. * Re-evaluate `@astrojs/cloudflare` only if the website needs server actions, sessions, dynamic personalization, form handling, or Cloudflare bindings. * Add Playwright smoke tests for top routes if website regressions become frequent. *** ## External Implementation References * Astro install and setup: `https://docs.astro.build/en/install-and-setup/` * Official Astro blog starter: `https://github.com/withastro/astro/tree/main/examples/blog` * Astro content collections: `https://docs.astro.build/en/guides/content-collections/` * Astro configuration reference: `https://docs.astro.build/en/reference/configuration-reference/` * Astro images: `https://docs.astro.build/en/guides/images/` * Astro RSS recipe: `https://docs.astro.build/en/recipes/rss/` * Astro sitemap integration: `https://docs.astro.build/en/guides/integrations-guide/sitemap/` * Astro Tailwind integration note: `https://docs.astro.build/en/guides/integrations-guide/tailwind/` * Cloudflare Pages build configuration: `https://developers.cloudflare.com/pages/configuration/build-configuration/` * Cloudflare Workers Astro guide: `https://developers.cloudflare.com/workers/framework-guides/web-apps/astro/` * Node.js release schedule: `https://github.com/nodejs/Release` *** ## Technical Considerations ### Architecture Deployment remains static Astro output. Build gates should run at the website workspace level and from the root workspace where practical. The launch handoff should document what passed, what was manually reviewed, and any remaining blocked or deferred claims. ### Risks * Rich visuals could hurt performance. Mitigation: optimize images, avoid unnecessary JavaScript, use responsive images, and review font loading. * Accessibility can regress during polish. Mitigation: run both automated and manual keyboard/responsive checks. * Deployment docs could imply production validation before it exists. Mitigation: record exactly what was deployed and what remains no-claim. * Legal/privacy pages may still need owner review. Mitigation: launch only with approved text or explicit pre-review status. ### Relevant Considerations * \[P08] Production-hosted validation remains no-claim until safe deployed targets pass sanitized smoke. This website deployment can record its own Cloudflare Pages evidence but must not imply unrelated app-shell, Worker, or demo validation. * \[P07] Analytics must remain disabled by default unless a future scoped phase adds consent, minimization, redaction, authorization, abuse controls, tests, and docs. * \[P02] Responsive and accessibility validation must include mobile, focus, reduced motion, contrast, and complete manual review. * \[P04] Media gates remain active. Do not use launch to promote blocked media. *** ## Success Criteria Phase complete when: * [x] All 5 sessions completed. * [x] Static output is deployable from `public-website/dist`. * [x] Sitemap, RSS, robots, metadata, and canonical URLs are verified. * [x] Manual QA covers 360px, 768px, 1280px, and wide desktop viewports. * [x] No analytics, trackers, hosted forms, or dynamic server dependencies are present. * [x] Cloudflare Pages build and deployment path are documented. * [x] Launch evidence and carry-forward items are recorded. *** ## Dependencies ### Depends On * Phase 13: Public Website Foundation. * Phase 14: Homepage And Core Product Story. * Phase 15: Trust, Content, And Conversion Pages. ### Enables * Public website launch at `https://faction-os.com/`. * Future post-launch improvements such as self-hosted fonts, generated social images, search, tag archives, CMS evaluation, analytics evaluation, dynamic Cloudflare adapter evaluation, and Playwright smoke tests. --- # 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_16/prd_phase_16.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.