# Waiter Floor Workflow API

## Purpose

This BFF exposes execution-facing waiter workflows over REST while delegating orchestration to `operations-service`.

## Endpoints

- `GET /api/waiter/floor/assignments?contextId=<value>`
  - Returns assignment summary, location context, current assignments, and recent activity.
- `GET /api/waiter/floor/activity?contextId=<value>`
  - Returns recent waiter activity projected from the same operations workflow snapshot.
- `POST /api/waiter/floor/orders`
  - Submits a waiter order snapshot for processing.
- `PUT /api/waiter/floor/orders/{orderId}`
  - Updates an existing waiter order snapshot using the same operations workflow contract.

## Upstream Dependency

- Base address configuration: `OperationsService:BaseAddress`
- Default runtime target: `http://operations-service:8080`
- Internal upstream routes:
  - `GET /internal/operations/waiter/assignments`
  - `POST /internal/operations/orders`

## Notes

- The update route currently reuses the operations order submission contract so waiter-floor can expose update semantics without introducing a new cross-repo dependency.
- Both order mutations project into the shared restaurant lifecycle owned by `operations-service`, which means kitchen and POS can observe the same order/check state through the same runtime path.
- Assignment and recent-activity reads are already lifecycle-backed through `operations-service`, so this BFF does not need a separate summary-projection fallback for the Stage 49 propagation wave.
- Correlation IDs are preserved through Thalos session checks and operations-service calls.