# Demo Runtime Flows

## Demo App Purpose

The demo app (`demo/`) is a runnable reference for shared UI patterns. It is not the public
integration surface for host repositories.

## HTTP Routes (initial)

- `GET /` - pattern bundle catalog page
- `GET /healthz` - health endpoint
- `GET /static/*` - static assets

## Demo Shell Visual Mode (Current Baseline)

- The main demo shell uses a dual visual baseline:
  - `Vapor Soft` for light/system-light mode
  - `Vapor Night` for dark/system-dark mode
- Theme selection in the main demo shell is system-driven (`prefers-color-scheme`) only.
- The style playground route may exist for internal experimentation, but it is not part of the
  primary demo navigation/catalog when the baseline is under active refinement.

## Page Render Flow (`GET /`)

1. Request hits `net/http` server mux
2. Handler prepares bundle/pattern catalog view model
3. Embedded templates render HTML response
4. Static CSS/JS loaded from embedded assets

## Interaction Flow Guardrail (Server-Rendered UI)

- Query-driven interactions (filters, pagination, segmented tabs, bulk actions, modal open/step state)
  must preserve the user's reading position on the page.
- Canonical mechanism in this repo: anchor-to-module links/forms (for example `#table-filters`,
  `#table-list`, `#controls-selection`, `#timeline-drilldown`).
- JS scroll restoration is optional and not required for the base contracts.

## Failure Behavior

- Template parse/render errors return `500`
- No DB calls or external services in bootstrap demo