chain-studio/docs/landing-page-design.md

# Welcome / Landing-page design

Status: **Design draft.** Not built yet.

## Why we need it

The Today-Hero in the Store mixed two genres of editorial
content:
- **Operator-actionable**: "DeepWiki is two clicks away",
  "text.summarize is in the grid", "try the extract→summarize
  flow". These belong in the Store carousel — they point at
  store / federation items the operator can act on.
- **Architecture education**: "every module is sandboxed",
  "the audit log is hash-chained", "the hub fits in one
  binary, no Docker". These are *what Ch∆In is* — they belong
  on a Welcome page that introduces the platform on first
  launch and stays available afterwards as a reference.

The operator feedback that made this distinction explicit:

> "interessante store einträge oder auch mcp etc zeigen und
> nicht einfach etwas übers system. Stattdessen brauchen wir
> als erstes im system eine art landing page die genau das
> macht und auch zu doku verlinkt, aber diese auch in das
> system optisch integriert und nicht einfach nach außen
> verlinkt."

The architectural-education stories already left the Store
carousel in the same release. The Welcome page is where they
land.

## Page shape

A new top-level Studio surface, accessed from the sidebar
above Doctor. First-launch operators land here automatically;
returning operators can come back any time.

```
┌──────────────────────────────────────────────────────────┐
│  AppBar: Welcome                                         │
├──────────────────────────────────────────────────────────┤
│  ┌────────────────────────────────────────────────────┐ │
│  │  HERO                                               │ │
│  │  Ch∆In Platform                                       │ │
│  │  Deterministic workflow engine for AI-assisted     │ │
│  │  document processing in regulated environments.    │ │
│  └────────────────────────────────────────────────────┘ │
│                                                          │
│  ┌──── Three-pillar row (Hub / Module / Flow) ────┐    │
│  │  ┌──────────┐  ┌──────────┐  ┌──────────┐      │    │
│  │  │   HUB    │  │  MODULE  │  │   FLOW   │      │    │
│  │  │ icon     │  │ icon     │  │ icon     │      │    │
│  │  │ One bin- │  │ Does one │  │ YAML     │      │    │
│  │  │ ary that │  │ thing,   │  │ chains   │      │    │
│  │  │ runs the │  │ sandboxed│  │ modules  │      │    │
│  │  │ flows    │  │ WASM     │  │ together │      │    │
│  │  └──────────┘  └──────────┘  └──────────┘      │    │
│  └────────────────────────────────────────────────┘    │
│                                                          │
│  ┌──── Trust posture ─────────────────────────────┐    │
│  │  🛡  Sandbox by default                          │    │
│  │     Every module declares fs / net / env perms; │    │
│  │     the hub enforces them. Click "Doctor →      │    │
│  │     Modules" to see live permissions per module.│    │
│  │                                                 │    │
│  │  ⛓  Tamper-evident audit log                    │    │
│  │     Every event hash-chained; Doctor verifies   │    │
│  │     end-to-end on every load. WORM-1 promise.   │    │
│  │                                                 │    │
│  │  ✈  Air-gap ready                               │    │
│  │     One binary, SQLite state, no Docker, no     │    │
│  │     external services. Once a module is         │    │
│  │     installed, the flow runs without further    │    │
│  │     network access.                             │    │
│  └────────────────────────────────────────────────┘    │
│                                                          │
│  ┌──── Getting-started checklist ─────────────────┐    │
│  │  ☐ Configure System AI (Settings → System AI)  │    │
│  │  ☐ Add a public MCP source (Store → DeepWiki)  │    │
│  │  ☐ Install your first text module              │    │
│  │  ☐ Run the extract → summarize sample flow     │    │
│  └────────────────────────────────────────────────┘    │
│                                                          │
│  ┌──── Documentation, embedded ───────────────────┐    │
│  │  Architecture map · Module experience ·        │    │
│  │  Flow composition · Compliance posture          │    │
│  │  → click opens an in-app reader, not a browser │    │
│  └────────────────────────────────────────────────┘    │
└──────────────────────────────────────────────────────────┘
```

## Optical integration of docs

The user constraint:

> "diese auch in das system optisch integriert und nicht
> einfach nach außen verlinkt"

So clicking a documentation card does **not** open a browser.
Instead a `_DocReaderSheet` (modal bottom-sheet, same shape as
`_StoreDetailSheet`) renders the markdown inline using the
existing `flutter_markdown` package — same one the Store uses
for module READMEs. The doc source is bundled with Studio as
`assets/docs/*.md`, kept in sync via a build step that copies
the relevant files from `fai_platform/docs/`.

Pros:
- Air-gap-tauglich (no network call to read docs)
- Operator stays in Studio context — Cmd-Tab to a browser
  breaks flow
- Same look-and-feel as module-doc rendering
- Bilingual: each doc has a `_de.md` sibling next to `.md`

Cons / tradeoffs:
- Studio binary grows by the size of bundled docs (a few
  hundred KB)
- Doc-update lifecycle: a Studio release ships a fixed
  snapshot. Live-fetched-from-hub is a Phase 1 question.

## Getting-started checklist

Stateful — the page tracks which items the operator has
completed and persists state to `~/.fai/studio/onboarding.json`
(same shape as theme/locale persistence in `hub.dart`). Each
checkmark is computed:

- ✓ System AI configured: `HubService.systemAiStatus().enabled`
- ✓ Public MCP source added: any
  `mcp.<server>.<tool>` in store
- ✓ First text module installed: any installed module
  whose name starts with `text.`
- ✓ Sample flow run: any `flow.completed` event in audit
  log naming `extract-summarize.yaml` (or any flow that
  uses both `text.extract` and `text.summarize`)

Operator can dismiss the checklist once everything is checked.

## Sidebar placement

The Welcome page becomes the new sidebar default — index 0,
above Doctor. First-launch experience hits it; afterward
operators most often go to Store / Audit, but the home icon
stays one click away.

`labelOf(context)` for the Welcome page returns
`l.navWelcome` ("Welcome" / "Willkommen"). New ARB keys:
`navWelcome`, plus the section-header strings (already mostly
covered by existing `doctorChain*` / `doctorPathLog` keys
that we can reference from the doc-card descriptions).

## Implementation phases

Big enough that a single commit doesn't make sense. Three
phased PRs:

1. **Phase A** — sidebar + scaffolding + hero + three-pillar
   row + trust-posture row. No docs yet, just the static
   content with hard-coded strings (with i18n). Lands
   without the embedded-doc reader.
2. **Phase B** — bundled markdown docs + `_DocReaderSheet`.
   Pick 4-5 source docs from `fai_platform/docs/architecture/`
   that map to operator concerns (security, host-services,
   flow-experience, compliance-gaps). Add a build script that
   syncs them into `assets/docs/`.
3. **Phase C** — getting-started checklist with computed
   state. Adds the persistence layer + the audit-log
   inspection helper.

## Out of scope

- A "tutorial mode" that walks the operator through the
  steps interactively. Editorial checklist + concise
  explanations is enough for v1; tutorial state is a Phase
  1+ idea.
- Live-fetched docs from `hub.fetch_doc(...)`. Air-gap
  posture requires bundled docs.
- Per-deployment branding (custom logo / color). Not a
  KRITIS need.