# 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=&limit=` - `GET /internal/kitchen/board?contextId=` - `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 plus lifecycle-derived ticket materialization for newly accepted restaurant orders - claim and priority changes update persisted kitchen ticket state - ticket transitions update both kitchen tickets and the linked restaurant order lifecycle - accepted orders can become kitchen-visible without waiting for a stack reset or a second write path ## Handoff Mapping - `Accepted` or `Submitted` restaurant order -> derived kitchen ticket starts in `Queued` - `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. - Downstream waiter, customer, and POS visibility still depends on the Stage 51 BFF alignment tasks consuming the updated runtime behavior.