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

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