Kitchen Display System Phase 5
Phase 5 adds a tenant-local live KDS board for station routed POS orders. It uses the existing POS send flow, kitchen station metadata, browser KOT printing, shared Blade UI components, Swal confirmation/loading flows, and appToast result notifications.
Routes
/r/{tenant}/kdsshows the all-station kitchen command board with metrics, filters, timers, and delay warnings./r/{tenant}/kds/stations/{station}focuses one station, such as grill, bar, pastry, prep, or main kitchen./r/{tenant}/kds/feedis the polling fallback used when Reverb or a Pusher-compatible driver is not configured./r/{tenant}/kds/settingsstores delay thresholds, polling cadence, sound alerts, and density defaults.
Ticket Flow
When POS sends an order, each sent order item is grouped by kitchen_station_id. KDS creates one ticket per station and one ticket item per POS order item. The order_item_id is unique in KDS, so repeat sends are idempotent and cannot duplicate kitchen items.
Statuses And Timers
Tickets move through new, queued, preparing, ready, and served. Items support queued, preparing, ready, served, delayed, cancelled, and voided. Delay scans compare the item due time against station prep targets and open auditable warning records.
Realtime And Fallback
KDS events are dispatched on tenant-scoped private broadcast channels for the main board, station board, and waiter notifications. If broadcasting is not configured, the board uses the polling feed and still stores every event in kds_events.
KOT Printing
KDS ticket print uses a browser 80mm view and includes branch, ticket, order, station, table, item notes, modifiers, seat labels, and current print time. No printer driver or hardware bridge is required in this phase.
Loader And Navigation Fixes
The shared page loader is deduplicated and suppressed during Swal-managed in-page actions. Documentation, tenant, and admin navigation now scroll the active selected item into view after load.