docs(blueprint-platform): record restaurant hardening validation

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