blueprint-platform/docs/consumption/restaurant-demo-flow-validation.md

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.