73 lines
3.5 KiB
Markdown
73 lines
3.5 KiB
Markdown
# Restaurant Demo Flow Validation
|
|
|
|
## Scope
|
|
|
|
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
|
|
|
|
- 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`.
|
|
- 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 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
|
|
|
|
- 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-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-S53-WAITER-002`
|
|
- Waiter activity reflected the new submission immediately
|
|
- Kitchen board derived `WK-ORD-S53-WAITER-002` and `KT-ORD-S53-WAITER-002`
|
|
|
|
## Accepted Runtime Note
|
|
|
|
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 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
|
|
|
|
- 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
|