Design the object model and public APIs for the operations core of a single restaurant: the class graph that seats guests at tables, takes reservations and a walk-in waitlist, drives an order from placement through the kitchen to the bill, and keeps every table's status coherent while several staff act at once.

Operating context. One venue, 20-60 tables of varying capacity, open one service at a time. Hosts seat parties (reservation or walk-in) at a fitting table; servers open a check per table, add and modify line items, fire courses to the kitchen; the kitchen works a queue of tickets and marks items ready; on departure the server settles the bill, optionally splitting it. Reservations are booked against future time slots; when the floor is full, new walk-ins join a waitlist and are quoted a wait. Several hosts, servers, and kitchen displays touch the same floor concurrently, but everything runs in one process with no remote calls.

Out of scope. Persistence and any database schema, payment-gateway / card processing, staff scheduling and payroll, inventory and supplier ordering, and the UI / POS-terminal rendering (design the in-process object model, not the HTTP or screen layer).

What to produce. The class hierarchy (entities, value objects, services), the public API each class exposes, and the state machines for a Table and for an Order. Be explicit about: how a table's status transitions are enforced so two hosts cannot seat the same table twice, how the order-to-kitchen-ticket flow is modeled, how the bill and its split are computed as pluggable policy, and how the reservation-plus-waitlist seating logic stays testable without a real clock.