# Restaurant Demo Flow Validation

## Scope

This document records the restaurant demo validation passes across Stage 48 and the Stage 49 propagation follow-up 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`.
- A customer-origin order now propagates through the shared lifecycle:
  - `POST /api/customer/orders` accepts the order
  - customer status/detail show the new order
  - kitchen board derives a queued ticket for that order
  - kitchen transitions move the order into a payable POS check
  - POS capture succeeds for the payable check
- A waiter-origin order now propagates into waiter activity and the kitchen board through the same shared lifecycle.

## 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-STAGE49-001`
- Customer detail moved to `accepted`
- Kitchen board derived ticket `KT-49001`
- Kitchen transitions advanced the order to `served`
- POS exposed payable check `CHK-ORD-STAGE49-001`
- POS capture succeeded and reduced open balance to `0`

### Waiter-origin flow

- Submitted order: `ORD-STAGE49-WAITER-001`
- Waiter activity reflected the new submission immediately
- Kitchen board derived a queued ticket for the waiter-origin order

## Residual Limitations

The runtime is now connected, but two important limitations remain:

- Customer order detail remains `served` after POS capture instead of advancing to a paid or closed order state.
- Derived kitchen identifiers can collide across orders with similar numeric suffixes. During validation, both `ORD-STAGE49-001` and `ORD-STAGE49-WAITER-001` projected to `KT-49001`/`WK-49001` at different times.
- Kitchen transition responses still report `transitioned: false` even though the persisted restaurant and kitchen state clearly change.

These do not block the proof that the apps now work together, but they should be treated as follow-up hardening items before we present the restaurant flow as fully production-shaped.

## Stage Status

- Stage 48 blocked finding is partially resolved.
- The core propagation gap is closed: new orders now move across customer or waiter entrypoints into kitchen visibility and POS payable state.
- Stage 49 runtime rollout can be considered complete.
- Final demo validation should remain tracked until the residual limitations above are either fixed or explicitly accepted.

## Recommended Follow-Up

- add a payment-to-order closure projection so paid checks can move customer-facing order state beyond `served`
- replace the current derived kitchen ticket/work-item identifier scheme with collision-safe IDs
- correct kitchen transition response semantics so `transitioned` reflects successful state mutations
- execute the reseed task only if we want the VPS database reset to a fresh deterministic walkthrough baseline