# Restaurant Demo Flow Validation

## Scope

This document records the restaurant demo validation passes across Stage 48, the Stage 49 propagation follow-up, and the Stage 53 hardening pass 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 restaurant runtime was refreshed from current repo state, including `operations-dal`, `kitchen-dal`, `operations-service`, `kitchen-service`, `waiter-floor-bff`, `customer-orders-bff`, `kitchen-ops-bff`, and `pos-transactions-bff`.
- Public routes for waiter, customer, kitchen, and POS demos return `200`.
- Customer-origin orders propagate through the shared lifecycle:
  - submission is accepted
  - customer status and detail show the new order
  - kitchen board derives a queued ticket for that order
  - kitchen transitions advance the order into a payable POS check
  - POS capture succeeds for that check
  - customer detail now moves to `paid` after full capture
- Waiter-origin orders also propagate into waiter activity and kitchen visibility through the same shared lifecycle.
- New kitchen-derived work-item and ticket IDs now use the full order identity and do not collide for similar numeric suffixes.
- Kitchen transition responses now return `transitioned: true` when the upstream mutation is applied successfully.

## Important Runtime Note

- Session cookies are scoped to the public `dream-views.com` hosts.
- Validation against `127.0.0.1` BFF ports does 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.

## Validation Evidence

### Customer-origin flow

- Submitted order: `ORD-S53-CUSTOMER-002`
- Kitchen board derived `WK-ORD-S53-CUSTOMER-002` and `KT-ORD-S53-CUSTOMER-002`
- Kitchen transitions returned `transitioned: true` for prepare, ready, and served steps
- POS exposed payable check `CHK-ORD-S53-CUSTOMER-002`
- POS capture succeeded and customer detail became `paid`

### Waiter-origin flow

- Submitted order: `ORD-S53-WAITER-002`
- Waiter activity reflected the new submission immediately
- Kitchen board derived `WK-ORD-S53-WAITER-002` and `KT-ORD-S53-WAITER-002`

## Accepted Runtime Note

The live demo still contains historical records created before the collision-safe kitchen ID fix. Those pre-fix rows remain visible until the restaurant demo is reseeded, but newly created orders now derive unique kitchen identifiers correctly.

## Stage Status

- Stage 48 blocked finding is resolved for the core restaurant flow.
- Stage 49 runtime rollout is complete.
- Stage 53 hardening is complete for:
  - payment-to-order closure
  - collision-safe kitchen identifier derivation for new orders
  - truthful kitchen transition success reporting
- The remaining restaurant follow-up is demo reseed hygiene, not runtime propagation correctness.

## Recommended Follow-Up

- execute `ARC-RESTAURANT-DEMO-RESEED-1140` when we want the VPS database reset to a fresh deterministic walkthrough baseline
- optionally remove or archive pre-fix demo records after the reseed so the board starts from a cleaner demo state