# Kitchen Ops Workflow API

## Purpose

This BFF exposes kitchen board, claim or release, transition, and priority workflows over REST while delegating orchestration to `kitchen-service`.

## Endpoints

- `GET /api/kitchen/ops/board?contextId=<value>`
  - Returns board lanes and available stations.
- `POST /api/kitchen/ops/work-items/claim`
  - Claims a kitchen work item.
- `POST /api/kitchen/ops/work-items/release`
  - Releases a kitchen work item using the current claim workflow path.
- `POST /api/kitchen/ops/work-items/transition`
  - Requests a kitchen work-item state transition.
- `POST /api/kitchen/ops/board/priority`
  - Updates kitchen priority for a work item.

## Upstream Dependency

- Base address configuration: `KitchenService:BaseAddress`
- Default runtime target: `http://kitchen-service:8080`
- Internal upstream routes:
  - `GET /internal/kitchen/board`
  - `POST /internal/kitchen/work-items/claim`
  - `POST /internal/kitchen/orders/transition`
  - `POST /internal/kitchen/work-items/priority`

## Notes

- `kitchen-service` currently exposes claim but not a dedicated release contract, so the release route reuses the claim validation path and projects a release-oriented response for the BFF edge.
- Transition requests now forward `ContextId` to `kitchen-service` so kitchen actions land in the correct shared restaurant lifecycle context.
- Board reads now rely on the lifecycle-driven kitchen ticket materialization in `kitchen-service`, which means newly accepted restaurant orders can appear without a stack reset.
- The BFF keeps temporary edge-state compatibility for existing web clients by translating `Cooking|Ready|Served` to the canonical kitchen-service states `Preparing|ReadyForPickup|Delivered`.
- Transition success at the edge is now sourced from the upstream `Applied` flag so operators see truthful mutation outcomes.
- Correlation IDs are preserved through Thalos session checks and kitchen-service calls.