kitchen-service/docs/api/internal-kitchen-workflows.md

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 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.