# Restaurant Demo Flow Validation

## Scope

This document records the Stage 48 validation pass for the deployed restaurant demo hosted behind the public `dream-views.com` demo domains.

## Validated On

- Date: `2026-03-31`
- Auth entrypoint: `https://auth.dream-views.com`
- Demo hosts:
  - `https://waiter-floor-demo.dream-views.com`
  - `https://customer-orders-demo.dream-views.com`
  - `https://kitchen-ops-demo.dream-views.com`
  - `https://pos-transactions-demo.dream-views.com`

## Confirmed Working

- Public Thalos session login and cookie-backed session validation work through the public host path.
- The four restaurant web apps serve the updated lifecycle-oriented SPA bundles.
- Public routes for waiter, customer, kitchen, and POS demos return `200`.
- UI copy now describes the intended restaurant flow:
  - order accepted
  - kitchen preparation
  - ready for handoff
  - served and payable
  - payment captured

## Important Runtime Note

- Session cookies are scoped to the public `dream-views.com` hosts.
- Validation against `127.0.0.1` BFF ports will not accurately exercise the deployed session behavior because those cookies do not round-trip on localhost.
- End-to-end validation for the deployed demo should use the public auth host plus the public demo hosts.

## Current Limitation

The deployed demo still does not fully propagate a newly submitted order through the shared restaurant lifecycle:

- `POST /api/customer/orders` accepts a new order and returns success.
- The same order is not yet visible in customer detail queries.
- The order does not appear on the kitchen board.
- Waiter activity does not reflect the new order.
- POS summary does not expose that order as newly payable.

This means the public SPAs now describe a connected flow more clearly, but the runtime still contains static or partially projected demo read models that do not fully reflect live mutations.

## Recommended Follow-Up

- Replace remaining static demo projections in restaurant read paths with lifecycle-backed projections sourced from the shared operations and kitchen stores.
- Re-run Stage 48 validation after that propagation work lands.
- Keep the seeded PostgreSQL data as deterministic walkthrough material, not as proof of the runtime mutation path.