> 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/sessions/phase16-session05-launch-review-and-documentation-handoff/spec.md). # Session Specification **Session ID**: `phase16-session05-launch-review-and-documentation-handoff` **Phase**: 16 - Quality, Deployment, And Launch Handoff **Status**: Not Started **Created**: 2026-06-02 **Package**: public-website **Package Stack**: Astro/TypeScript *** ## 1. Session Overview This session closes the Phase 16 public website launch path by collecting the evidence needed to make a launch, block, or follow-up decision for the static `faction-os.com` website. Sessions 01-04 already completed responsive and accessibility hardening, performance and image optimization, automated build gates, and the Cloudflare Pages deployment path. The remaining work is to turn that implementation state into a source-backed launch record. The session does not add new routes, product features, analytics, forms, CMS behavior, server rendering, or hosted runtime behavior. It records command results, manual QA coverage, metadata/feed/privacy checks, Cloudflare Pages deployment readiness, unresolved legal or privacy owner-review items, and the post-launch backlog. The output should leave stable docs aligned with the public website status and should keep every hosted, certification, legal, and erasure claim scoped to the evidence that actually exists. After this session is implemented and validated, the next Apex workflow step is `updateprd`; once Phase 16 is complete, the phase-transition cadence begins with `audit`. *** ## 2. Objectives 1. Record pass, fail, blocked, skipped, unavailable, or no-claim evidence for every Phase 16 public website launch gate. 2. Capture local command evidence for the public website and repo-level gates required by the Phase 16 PRD. 3. Record manual QA coverage for target desktop, tablet, mobile, reduced motion, navigation, CTA, and route checks. 4. Update stable documentation with the final launch-review status, remaining blockers, post-launch backlog, and next Apex action. *** ## 3. Prerequisites ### Required Sessions * [x] `phase16-session01-responsive-and-accessibility-hardening` - responsive, keyboard, focus, contrast, reduced-motion, and viewport evidence. * [x] `phase16-session02-performance-and-image-optimization` - static payload, image, font, and performance hardening evidence. * [x] `phase16-session03-automated-checks-and-build-gates` - package typecheck, build, built-site checker, metadata, feed, draft, and privacy gates. * [x] `phase16-session04-cloudflare-pages-deployment-path` - dedicated Cloudflare Pages workflow, manual Wrangler fallback, and deploy boundary documentation. ### Required Tools/Knowledge * Node.js 26.2.0 or newer and npm 11.16.0. * Astro static build flow for `@factionos/public-website`. * Biome format and lint gates from the root workspace. * Cloudflare Pages status labels: passed, failed, skipped, blocked, unavailable, and no-claim. * Existing public website route, metadata, RSS, sitemap, robots, and privacy checker behavior. ### Environment Requirements * Run commands from the repository root unless a task says otherwise. * Cloudflare credentials are optional for this session; absence must be recorded as skipped, blocked, unavailable, or no-claim evidence, not as a local build failure. * Do not write Cloudflare account ids, API tokens, dashboard dumps, credential-bearing URLs, raw probe bodies, or secret values to tracked files. *** ## 4. Scope ### In Scope (MVP) * Release operator can see all public website launch gates and evidence status in one launch readiness record - implemented as a session evidence document. * Release operator can see command results for typecheck, build, built-site checks, format, lint, root workspace build/typecheck, secret scan, and whitespace checks - implemented as a command evidence matrix. * Release operator can see manual QA coverage for 360px, 768px, 1280px, and wide desktop viewports - implemented as manual coverage records. * Release operator can see metadata, RSS, sitemap, robots, draft exclusion, no-analytics, no-form, no-storage, and no-runtime-network evidence - implemented as static output checks. * Release operator can see Cloudflare Pages deployment readiness and exact blockers - implemented as deployment status and no-claim notes. * Maintainer can see stable docs that reflect the public website launch status without overstating production-hosted validation, legal review, analytics, hosted identity, hosted storage, or trusted erasure. * Maintainer can see post-launch backlog items and the next Apex phase decision - implemented as a handoff summary. ### Out of Scope (Deferred) * New product pages, route expansions, or copy rewrites - *Reason: Phase 16 is a launch evidence and hardening phase, not new content scope.* * Analytics, search, CMS, forms, auth, server rendering, or dynamic routes - *Reason: first launch remains static and no-analytics by default.* * Live Cloudflare deploy from this local environment - *Reason: deploy requires authorized credentials and dashboard/domain access.* * Formal legal, WCAG, VPAT, mobile-device certification, or third-party security certification - *Reason: session records owner-review state and no-claim boundaries only.* * Broad media promotion, hosted identity, hosted storage, production app-shell validation, or trusted unified erasure - *Reason: all remain separate source-backed future work unless proven by a later scoped phase.* *** ## 5. Technical Approach ### Architecture The session uses an evidence-first documentation architecture. Source code and website behavior are already in place from prior sessions; implementation work collects current evidence, records command outputs, checks static build output, documents manual QA coverage, and updates stable docs. The primary session artifacts live in the Apex spec directory, while stable documentation updates live in the public website README and release/deployment docs. The public website remains a static Astro workspace. The launch review must distinguish local static build readiness from production-hosted validation. Cloudflare Pages workflow configuration, dashboard settings, and local Wrangler commands are readiness evidence; only a successful authorized deploy plus bounded HTTPS smoke can support a production-hosted claim. ### Design Patterns * Evidence matrix: makes pass/fail/blocker state explicit and reviewable. * No-claim boundary record: prevents local evidence from becoming unsupported hosted, legal, certification, analytics, or erasure claims. * Stable docs sync: keeps `public-website/README_public-website.md`, `docs/deployment.md`, and `docs/release.md` aligned with the final decision. * Session-local backlog: preserves post-launch follow-up work without turning it into Phase 16 implementation scope. ### Technology Stack * Node.js 26.2.0 or newer. * npm 11.16.0 workspaces. * Astro 6.4.x static output in `public-website`. * TypeScript 5.9.x for package typecheck. * Biome 2.4.x for root format and lint. * Cloudflare Pages via Wrangler 4.x for authorized deployment paths. *** ## 6. Deliverables ### Files to Create | File | Purpose | Est. Lines | | ----------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ---------- | | `.spec_system/specs/phase16-session05-launch-review-and-documentation-handoff/implementation-notes.md` | Task log, command evidence summary, blockers, and final implementation notes | \~220 | | `.spec_system/specs/phase16-session05-launch-review-and-documentation-handoff/launch-readiness-evidence.md` | Launch gates, command evidence, manual QA, metadata/feed/privacy checks, and deploy readiness status | \~260 | | `.spec_system/specs/phase16-session05-launch-review-and-documentation-handoff/launch-handoff-summary.md` | Launch/no-launch recommendation, no-claim boundaries, owner-review state, and next Apex action | \~160 | | `.spec_system/specs/phase16-session05-launch-review-and-documentation-handoff/post-launch-backlog.md` | Carry-forward backlog for later phases and post-launch operations | \~120 | | `.spec_system/specs/phase16-session05-launch-review-and-documentation-handoff/security-compliance.md` | Security, privacy, GDPR, and hosted-claim review for the launch handoff | \~140 | ### Files to Modify | File | Changes | Est. Lines | | ----------------------------------------- | ------------------------------------------------------------------------------------------------- | ---------- | | `public-website/README_public-website.md` | Add launch handoff status, evidence references, and post-launch boundary notes | \~40 | | `docs/deployment.md` | Record public website launch-review outcome and deployment readiness status labels | \~35 | | `docs/release.md` | Record public website launch gate outcome, command evidence expectations, and no-claim boundaries | \~35 | *** ## 7. Success Criteria ### Functional Requirements * [ ] Every launch gate from the Phase 16 PRD and Session 05 stub has an explicit evidence status. * [ ] Command results are recorded with the command, status, date, runner context, and concise outcome. * [ ] Manual QA coverage records target viewports and critical route, nav, CTA, reduced-motion, and no-overlap checks. * [ ] Metadata, RSS, sitemap, robots, draft exclusion, no-analytics, no-form, no-storage, and no-runtime-network checks are recorded. * [ ] Cloudflare Pages deployment readiness is recorded without claiming live production validation unless a live deploy and smoke actually occurred. * [ ] Stable docs reflect the final launch-review status and evidence scope. * [ ] Post-launch backlog and next Apex action are explicit. ### Testing Requirements * [ ] `npm --workspace @factionos/public-website run typecheck` passes or has a recorded blocker. * [ ] `npm --workspace @factionos/public-website run build` passes or has a recorded blocker. * [ ] `npm --workspace @factionos/public-website run check:links` passes or has a recorded blocker. * [ ] Root format, lint, typecheck, build, secret scan, and whitespace checks pass or have recorded blockers. * [ ] Manual QA evidence is recorded for 360px, 768px, 1280px, and wide desktop. ### Non-Functional Requirements * [ ] Documentation remains ASCII-only with Unix LF line endings. * [ ] No tracked file contains secrets, account ids, credential-bearing URLs, raw probe output, local private paths, prompts, command bodies, replay buffers, diagnostics, logs, backups, exports, or dashboard dumps. * [ ] Public website claims stay aligned with the static Astro boundary and no-analytics default. ### Quality Gates * [ ] All files ASCII-encoded. * [ ] Unix LF line endings. * [ ] Code follows project conventions. * [ ] No new runtime dependencies or application code are added. *** ## 8. Implementation Notes ### Key Considerations * The final decision can be launch-ready, blocked, or follow-up phase required. The evidence must support the chosen recommendation. * Missing deploy credentials are not a source code failure. Record them as unavailable, skipped, blocked, or no-claim depending on the actual state. * Legal/privacy copy can be launch-ready only with owner approval or clear pre-review labels. * Manual QA evidence should name viewports and routes, not just say "checked." * Do not mutate route contracts unless a blocker forces a small corrective fix; if that happens, rerun the built-site checker and update route-dependent docs together. ### Potential Challenges * Cloudflare credentials unavailable locally: Record unavailable or blocked evidence and keep production-hosted validation as no-claim. * Legal/privacy owner review unavailable: Preserve pre-review labels and block final legal approval claims. * Root workspace gates take time: Record exact command status and use pinned Node/npm runner if the default shell is below baseline. * Manual QA cannot cover every browser/device: Record scoped local browser evidence and avoid formal certification language. ### Relevant Considerations * \[P15-public-website] **Route contract drift is a launch risk**: The launch review must rerun or cite the built-site checker whenever routes, CTAs, navigation, metadata, footer links, or legal markers change. * \[P16-public-website] **Launch hardening is still ahead**: This session owns the remaining launch evidence and handoff decision for Phase 16. * \[P13-public-website] **Public website external links are explicit**: Demo and GitBook links may stay external, but analytics, hosted forms, third-party fonts, CMS, auth, and runtime personalization require separate review. * \[P13-public-website] **Static Astro boundary is intentional**: Do not add a Cloudflare adapter, React, Tailwind, CMS, auth, hosted forms, or analytics as part of launch handoff. * \[P08] **Release evidence is claim-scoped**: Local build and static checks are launch-path evidence, not production-hosted validation, formal certification, trusted erasure, or hosted-service proof. * \[P15-public-website] **Deterministic built-site checks catch drift early**: The package checker is the authoritative static-output gate for routes, metadata, links, drafts, and privacy markers. *** ## 9. Testing Strategy ### Unit Tests * No unit tests are expected because this is a documentation and evidence handoff session with no application code changes. ### Integration Tests * Run package typecheck, package build, built-site checker, root typecheck, root build, format, lint, secret scan, and whitespace checks as launch evidence. ### Manual Testing * Verify critical public website routes and navigation at 360px, 768px, 1280px, and wide desktop. * Verify demo and docs CTAs, mobile navigation, keyboard access, visible focus, reduced-motion behavior, and no text overlap. ### Edge Cases * Cloudflare credentials absent or dashboard/domain status unknown. * Legal or privacy approval unavailable. * Fresh build output missing expected static files. * Draft content appears in production output. * Static checker finds unapproved external links or privacy-sensitive runtime behavior. *** ## 10. Dependencies ### External Libraries * None added in this session. ### Other Sessions * **Depends on**: `phase16-session01-responsive-and-accessibility-hardening`, `phase16-session02-performance-and-image-optimization`, `phase16-session03-automated-checks-and-build-gates`, `phase16-session04-cloudflare-pages-deployment-path` * **Depended by**: Phase 16 closeout via `updateprd`, then phase-transition workflow beginning with `audit`. *** ## Next Steps Run the implement workflow step to begin AI-led implementation. --- # 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/sessions/phase16-session05-launch-review-and-documentation-handoff/spec.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.