76 lines
3.8 KiB
Markdown
76 lines
3.8 KiB
Markdown
# 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
|