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 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