# Restaurant Core Foundation v47

## Purpose
Restaurant orders are long-running operational documents and are intentionally distinct from finalized `sales.sales`.

## Foundation
- Fulfillment: `dine_in`, `takeaway`, `delivery`.
- Source: `pos`, `waiter`, `phone`, `web`, `whatsapp`, `platform`, `kiosk`.
- Floor and dining-table master data scoped to branch.
- One live dine-in order per table enforced by PostgreSQL partial unique index.
- Optional waiter, customer and register assignment.
- Delivery contact/address snapshot.
- Restaurant order items with price snapshot, notes and course.
- Item modifiers with optional catalog variant link.
- Immutable order-event history.
- Optimistic version counter on operational order mutations.

## Lifecycle
`open -> submitted -> in_progress -> ready -> served -> finalized`

Supported early cancellation:
`open/submitted/in_progress/ready -> cancelled` where allowed by service rules.

Finalization currently closes the restaurant order but does not manufacture a fake payment or stock transaction. Linking/converting the restaurant document to a finalized Sale is a later explicit integration step.

## Table/order operations
- Transfer order to another active table.
- Merge one live order into another in the same tenant/branch.
- Split part of an item quantity into another live order.
- Merge/split generate immutable event records.

## Deferred to restaurant/KDS bundles
- KDS stations/tickets and send-delta semantics.
- Seat-level assignment.
- Fire course timing.
- Sent-item cancellation/waste policy.
- Packaging stock.
- Delivery driver/COD settlement.
- Sale conversion/payment orchestration.
- Multi-printer routing.