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

# Session 04: Product Overview Page

**Session ID**: `phase14-session04-product-overview-page` **Package**: public-website **Status**: Not Started **Estimated Tasks**: \~16-22 **Estimated Duration**: 2-4 hours

***

## Objective

Build `/product` as a complete map of shipped and optional FactionOS surfaces with accurate local-first positioning and clear demo/docs actions.

***

## Scope

### In Scope (MVP)

* Create or complete `src/pages/product.astro`.
* Define product surface data for:
  * Web cockpit.
  * Hook ingest.
  * CLI.
  * Protocol.
  * Optional War Room.
  * Outbound adapters.
  * Static demo.
* Add product promise and category framing.
* Add local-first operating model section.
* Add product screenshots or synthetic product mockup panels where useful.
* Add demo/docs CTA.
* Include metadata and structured data if appropriate.

### Out of Scope

* Full feature matrix; that belongs to `/features`.
* Deep setup guide; that belongs to `/how-it-works` and public docs.
* Investor thesis; that belongs to `/investors`.
* Hosted account, hosted storage, dashboard login, or public replay claims.

***

## Prerequisites

* [ ] Phase 13 shell and SEO complete.
* [ ] Session 02 product mockup components available or a static panel alternative chosen.

***

## Deliverables

1. `src/pages/product.astro`.
2. Product surface data module or local data array.
3. Reusable product proof panels.
4. Local-first operating model section.
5. Demo/docs CTA wired to approved external URLs.

***

## Product Surface Requirements

Describe each surface concretely:

* Web cockpit: live browser view of missions, roster, battlefield, replay, approvals, diagnostics, and settings.
* Hook ingest: local ingestion from Claude Code, Codex CLI, and compatible event producers.
* CLI: setup and lifecycle commands for local operation.
* Protocol: shared contracts for events, runtime state, and integrations.
* Optional War Room: redacted collaboration path, not hosted identity.
* Outbound adapters: Discord, Telegram, and generic HTTPS webhook notification bridges, not inbound command channels.
* Static demo: zero-install synthetic experience separate from real local sessions.

***

## Task Expansion Guidance

When expanded with `plansession`, keep the checklist to 16-22 tasks covering:

* Product page route.
* Surface data.
* Product promise copy.
* Surface cards/panels.
* Local-first model.
* Mockup reuse.
* CTA section.
* Metadata.
* Responsive layout.
* Copy guardrail review.
* Build check.

***

## Success Criteria

* [ ] `/product` renders a complete product overview.
* [ ] Surface copy is concrete and accurate.
* [ ] Optional and unavailable/future capabilities are not overclaimed.
* [ ] Demo/docs CTAs are visible and accessible.
* [ ] Product page links cleanly to `/features`, `/how-it-works`, and `/security` where relevant.


---

# 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/session_04_product_overview_page.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.