diff --git a/docs/consumption/restaurant-demo-flow-validation.md b/docs/consumption/restaurant-demo-flow-validation.md index 95fbd39..124ab1f 100644 --- a/docs/consumption/restaurant-demo-flow-validation.md +++ b/docs/consumption/restaurant-demo-flow-validation.md @@ -2,7 +2,7 @@ ## Scope -This document records the Stage 48 validation pass for the deployed restaurant demo hosted behind the public `dream-views.com` demo domains. +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 @@ -17,42 +17,59 @@ This document records the Stage 48 validation pass for the deployed restaurant d ## 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. +- 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`. -- UI copy now describes the intended restaurant flow: - - order accepted - - kitchen preparation - - ready for handoff - - served and payable - - payment captured +- 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 will not accurately exercise the deployed session behavior because those cookies do not round-trip on localhost. +- 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. -## Current Limitation +## Validation Evidence -The deployed demo still does not fully propagate a newly submitted order through the shared restaurant lifecycle: +### Customer-origin flow -- `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. +- 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` -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. +### 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 -The blocked Stage 48 finding now rolls into Stage 49: - -- `plan/2026-03-31-s49-master-restaurant-propagation-and-runtime-alignment.md` -- `docs/architecture/stage49-52-restaurant-propagation-guardrails.md` - -Execution focus: - -- replace remaining static or summary-only restaurant read projections with lifecycle-backed projections sourced from the shared operations and kitchen stores -- redeploy aligned restaurant runtime images before re-validating the public demo -- keep the seeded PostgreSQL data as deterministic walkthrough material, not as proof of the runtime mutation path +- 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