From 5c0408fa1c9a740f2dae09f595ffd7a47f13f45c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Ren=C3=A9=20White=20Enciso?= Date: Tue, 31 Mar 2026 20:32:14 -0600 Subject: [PATCH] docs(blueprint-platform): record restaurant hardening validation --- .../restaurant-demo-flow-validation.md | 59 +++++++++---------- 1 file changed, 28 insertions(+), 31 deletions(-) diff --git a/docs/consumption/restaurant-demo-flow-validation.md b/docs/consumption/restaurant-demo-flow-validation.md index 124ab1f..9ef5562 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 restaurant demo validation passes across Stage 48 and the Stage 49 propagation follow-up hosted behind the public `dream-views.com` demo domains. +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 @@ -19,13 +19,16 @@ This document records the restaurant demo validation passes across Stage 48 and - 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 +- 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 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. + - 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 @@ -37,39 +40,33 @@ This document records the restaurant demo validation passes across Stage 48 and ### 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` +- 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-STAGE49-WAITER-001` +- Submitted order: `ORD-S53-WAITER-002` - Waiter activity reflected the new submission immediately -- Kitchen board derived a queued ticket for the waiter-origin order +- Kitchen board derived `WK-ORD-S53-WAITER-002` and `KT-ORD-S53-WAITER-002` -## Residual Limitations +## Accepted Runtime Note -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. +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 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. +- 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 -- 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 +- 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