> 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/session_05_launch_review_and_documentation_handoff.md).

# Session 05: Launch Review And Documentation Handoff

**Session ID**: `phase16-session05-launch-review-and-documentation-handoff` **Package**: public-website **Status**: Not Started **Estimated Tasks**: \~12-18 **Estimated Duration**: 2-4 hours

***

## Objective

Record launch evidence, update stable documentation, capture carry-forward items, and prepare the next Apex phase decision.

***

## Scope

### In Scope (MVP)

* Confirm all launch gates have pass/fail evidence.
* Record command results for build, typecheck, format/lint where relevant.
* Record manual QA coverage for target viewports.
* Record metadata, RSS, sitemap, robots, draft exclusion, and no-analytics checks.
* Record Cloudflare Pages deployment readiness or exact blockers.
* Update stable project documentation that should mention the public website.
* Capture post-launch backlog items.
* Capture unresolved legal/privacy review items if any.
* Capture no-claim boundaries that must remain after launch.
* Recommend whether to launch, block, or create a follow-up phase.

### Out of Scope

* Implementing new product pages.
* Adding analytics, search, CMS, forms, server rendering, or dynamic routes.
* Performing formal legal, WCAG, VPAT, or third-party security certification.

***

## Prerequisites

* [ ] Sessions 01-04 completed.
* [ ] All launch blocker status known.

***

## Deliverables

1. Launch checklist/evidence document or phase validation notes.
2. Stable documentation updates.
3. Carry-forward list.
4. Launch/no-launch recommendation.
5. Next-phase recommendation if follow-up work is needed.

***

## Launch Gates To Record

* 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.

***

## Post-Launch Backlog To Carry Forward

* 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.

***

## Task Expansion Guidance

When expanded with `plansession`, keep the checklist to 12-18 tasks covering:

* Launch gate inventory.
* Command evidence.
* Manual QA evidence.
* Metadata/feed evidence.
* Draft/no-analytics evidence.
* Deployment readiness evidence.
* Documentation updates.
* Carry-forward list.
* No-claim review.
* Next-phase recommendation.

***

## Success Criteria

* [ ] Launch evidence is recorded.
* [ ] Stable docs reflect the public website where appropriate.
* [ ] Remaining blockers and no-claim boundaries are explicit.
* [ ] Post-launch backlog is preserved.
* [ ] The next Apex action is clear.


---

# 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/session_05_launch_review_and_documentation_handoff.md?ask=<question>&goal=<endgoal>
```

`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.