waiter-floor-bff/docs/api/waiter-floor-workflows.md

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.