33 lines
1.2 KiB
Markdown
33 lines
1.2 KiB
Markdown
# Internal Kitchen Workflows
|
|
|
|
## Purpose
|
|
|
|
`kitchen-service` exposes workflow-shaped internal endpoints for the kitchen BFF while keeping ticket execution aligned with the shared restaurant lifecycle.
|
|
|
|
## Endpoint Surface
|
|
|
|
- `GET /internal/kitchen/queue?queueName=<contextId>&limit=<n>`
|
|
- `GET /internal/kitchen/board?contextId=<id>`
|
|
- `POST /internal/kitchen/orders/transition`
|
|
- `POST /internal/kitchen/work-items/claim`
|
|
- `POST /internal/kitchen/work-items/priority`
|
|
|
|
## Stage 46 Runtime Shape
|
|
|
|
This repo now orchestrates kitchen progression over persisted kitchen tickets from `kitchen-dal` and syncs restaurant order state back through `operations-dal`.
|
|
|
|
That means:
|
|
- board and queue reads come from persisted kitchen tickets
|
|
- claim and priority changes update persisted kitchen ticket state
|
|
- ticket transitions update both kitchen tickets and the linked restaurant order lifecycle
|
|
|
|
## Handoff Mapping
|
|
|
|
- `Preparing` -> restaurant order becomes `Preparing`
|
|
- `ReadyForPickup` -> restaurant order becomes `Ready`
|
|
- `Delivered` -> restaurant order becomes `Served`
|
|
|
|
## Remaining Limitation
|
|
|
|
- Payment opening is still owned by `operations-service`; this repo only advances kitchen execution and the linked restaurant order state.
|