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