Production / kitchen workflow — prep stations, courses, expo, floor monitor #4

New issue

Open

opened 2026-05-10 14:49:04 +00:00 by padreug · 0 comments

padreug commented

2026-05-10 14:49:04 +00:00

Owner

Tracks the kitchen-side operations of #2 (bistro light, full complete).

Background

DarthCoin's framing on what a real restaurant needs:

from raw material items inventory, to production, cooking, waiting
lines, serving etc.

ordering times, serving, servers monitoring, chef monitor

The current scaffold ships a single Kitchen Display (KDS) page. That's
fine for a café where every item is "make and hand over." It collapses
the moment you have:

prep stations (cold line, grill, fryer, expo) handing off to each
other,
courses (apps fire first, mains fire 8 min later),
waiters tracking which table is which order,
a chef wanting to see overall pace + bottlenecks.

This issue is the umbrella for everything that's beyond what KDS
already does.

Concepts

Prep stations

Each menu item / modifier can declare which station prepares it.
Stations are configurable per restaurant. A taco might be:

recipes.tacos
  ├── tortilla (cold prep)
  ├── meat fillings (grill)
  └── plating + garnish (expo)

The KDS splits one ticket into per-station cards. A station marks its
slice complete; the expo sees the aggregated state and only fires
"ready to serve" when all stations are done.

Course timing

An item can declare a course (appetizer | main | dessert | drink).
Operators set per-course offset rules: "fire mains 8 min after apps
clear." The KDS holds back later-course tickets until the rule fires.

ETA / waiting line

Each item carries an estimated prep time (operator-set; later
auto-tuned from observed actuals). Aggregating gives:

Per-ticket ETA shown on the customer's status page.
Per-station load gauge so the chef can see backups in real time.
Floor-wide "wait time" estimate the host can quote new walk-ins.

Roles + monitors

Three viewer roles, each its own page:

Cook — only sees their own station's queue. Big text, one
action ("done").
Expo — sees every station for every active ticket, aggregated.
Fires the "ready to serve" call.
Chef — global dashboard: load per station, slow tickets, items
hitting their estimated time, course pacing.
Waiter / floor — table → order map, status per table, a
one-tap "deliver" / "needs check" / "rerun" affordance.

Tables (new)

A new tables concept (per-restaurant) — name + seating + an
optional QR target for per-table ordering (cf. #1 stretch).
Orders carry an optional table_id.

Data model (additions, sketch)

stations                — id, restaurant_id, name, sort_order
recipe_lines.station_id — which station prepares this line
courses (enum or table) — id, restaurant_id, name, default_delay_sec

tables                  — id, restaurant_id, label, capacity
orders.table_id         — optional FK
orders.eta_seconds      — computed at place-time, refreshed live
order_item_states       — per-item, per-station status:
                          pending → fired → done; timestamps for each

Tiering (per #2)

bar — none of this. KDS works as today.
bistro — courses + per-table mapping + ETA. No multi-station
splitting (everything is one "kitchen" station by default).
full — full multi-station + chef + waiter monitors.

Stretch

Auto-tune ETA from observed actuals (rolling average per item).
Rush-hour pacing — gates new orders if every station is at
load > N. Customer's webapp gets back "we're 25 min behind, accept?"
Live chef whiteboard — large-screen dashboard, designed for an
in-kitchen tablet/TV.
NFC dining — tap a table NFC tag to open the menu in the
webapp pre-tied to that table's table_id.

Acceptance

stations, tables, order_item_states tables (mode-gated).
Per-item / per-modifier station_id, prep_seconds,
course columns on existing recipes (tied with #3).
Cook-, expo-, chef-, waiter-mode pages under
/restaurant/{slug}/kds/{role}.
ETA exposed on GET /api/v1/orders/{id} and on the
customer-facing status payload.
Course-fire rules in restaurant settings.
docs/kitchen-workflow describing roles + the data model.

References

Telegram conversation 2026-05-09.

Tracks the kitchen-side operations of #2 (`bistro` light, `full` complete). ## Background DarthCoin's framing on what a real restaurant needs: > from raw material items inventory, to production, cooking, waiting > lines, serving etc. > ordering times, serving, servers monitoring, chef monitor The current scaffold ships a single Kitchen Display (KDS) page. That's fine for a café where every item is "make and hand over." It collapses the moment you have: - prep stations (cold line, grill, fryer, expo) handing off to each other, - courses (apps fire first, mains fire 8 min later), - waiters tracking which table is which order, - a chef wanting to see overall pace + bottlenecks. This issue is the umbrella for everything that's *beyond* what KDS already does. ## Concepts ### Prep stations Each menu item / modifier can declare which station prepares it. Stations are configurable per restaurant. A taco might be: ``` recipes.tacos ├── tortilla (cold prep) ├── meat fillings (grill) └── plating + garnish (expo) ``` The KDS splits one ticket into per-station cards. A station marks its slice complete; the **expo** sees the aggregated state and only fires "ready to serve" when all stations are done. ### Course timing An item can declare a course (`appetizer | main | dessert | drink`). Operators set per-course offset rules: "fire mains 8 min after apps clear." The KDS holds back later-course tickets until the rule fires. ### ETA / waiting line Each item carries an estimated prep time (operator-set; later auto-tuned from observed actuals). Aggregating gives: - Per-ticket ETA shown on the customer's status page. - Per-station load gauge so the chef can see backups in real time. - Floor-wide "wait time" estimate the host can quote new walk-ins. ### Roles + monitors Three viewer roles, each its own page: - **Cook** — only sees their own station's queue. Big text, one action ("done"). - **Expo** — sees every station for every active ticket, aggregated. Fires the "ready to serve" call. - **Chef** — global dashboard: load per station, slow tickets, items hitting their estimated time, course pacing. - **Waiter / floor** — table → order map, status per table, a one-tap "deliver" / "needs check" / "rerun" affordance. ### Tables (new) A new `tables` concept (per-restaurant) — name + seating + an optional QR target for **per-table ordering** (cf. #1 stretch). Orders carry an optional `table_id`. ## Data model (additions, sketch) ``` stations — id, restaurant_id, name, sort_order recipe_lines.station_id — which station prepares this line courses (enum or table) — id, restaurant_id, name, default_delay_sec tables — id, restaurant_id, label, capacity orders.table_id — optional FK orders.eta_seconds — computed at place-time, refreshed live order_item_states — per-item, per-station status: pending → fired → done; timestamps for each ``` ## Tiering (per #2) - **bar** — none of this. KDS works as today. - **bistro** — courses + per-table mapping + ETA. No multi-station splitting (everything is one "kitchen" station by default). - **full** — full multi-station + chef + waiter monitors. ## Stretch - **Auto-tune ETA** from observed actuals (rolling average per item). - **Rush-hour pacing** — gates new orders if every station is at load > N. Customer's webapp gets back "we're 25 min behind, accept?" - **Live chef whiteboard** — large-screen dashboard, designed for an in-kitchen tablet/TV. - **NFC dining** — tap a table NFC tag to open the menu in the webapp pre-tied to that table's `table_id`. ## Acceptance - [ ] `stations`, `tables`, `order_item_states` tables (mode-gated). - [ ] Per-item / per-modifier `station_id`, `prep_seconds`, `course` columns on existing recipes (tied with #3). - [ ] Cook-, expo-, chef-, waiter-mode pages under `/restaurant/{slug}/kds/{role}`. - [ ] ETA exposed on `GET /api/v1/orders/{id}` and on the customer-facing status payload. - [ ] Course-fire rules in restaurant settings. - [ ] [[docs/kitchen-workflow]] describing roles + the data model. ## See also - #2 — tiered operator modes (parent) - #3 — inventory (gates "is this station available?") - #5 — loyalty (waiter monitor surfaces returning-customer status) ## References - Telegram conversation 2026-05-09.

padreug referenced this issue

2026-05-10 14:49:44 +00:00

Loyalty / customer fidelity — Nostr-native points and tiers #5

padreug referenced this issue

2026-05-10 14:53:49 +00:00

Deployment + monetization — review LNbits docs and pick a model #7

padreug referenced this issue from a commit

2026-05-11 15:16:36 +00:00

feat(restaurant): types + RestaurantAPI REST client

padreug referenced this issue from a commit

2026-05-11 15:32:07 +00:00

feat(restaurant): checkout + order placement + status polling