Chef guide

This guide covers what a chef or kitchen manager can do in Lucille Order Center, screen by screen, as the application is built today. Desktop is the primary target — a kitchen terminal or the back office — but every screen is responsive down to a 375px phone, including the cart, which becomes a bottom bar that opens a dialog. There is no mobile app.

1. Signing in

1. Open the Order Center. The sign-in page has a single Sign in button.
2. You are sent to Lucille's identity provider (Zitadel). Enter your work email and password, plus a second factor if your account has one.
3. You land back on the dashboard. If you were following a deep link, you are returned to it rather than to the dashboard.

Accounts are created for you in Zitadel by the administrator — there is no self-registration. If sign-in bounces you back to the login screen, or the app says your account has no role, that is an identity-provider configuration problem rather than something you can fix; report it to the administrator. The technical cause is in troubleshooting.

Your access token is short-lived and renewed silently in the background; the refresh cookie behind that renewal lasts seven days, so a week of regular use never asks you to sign in again. Closing the tab does not sign you out. The Sign out item in the account menu does.

2. Choosing your restaurant

The dashboard shows three cards — the restaurant you are ordering for, what is in your cart, and your account with the number of restaurants assigned to you — above your five most recent orders.

• Assigned to one restaurant? It is selected for you and there is nothing to choose; the header simply shows its name.
• Assigned to several? Use the restaurant switcher in the header. Until you pick one, ordering is blocked and the catalog tells you so.
• Assigned to none? You can still browse the catalog, but you cannot order. Ask an administrator to assign you.

caution

Switching restaurants empties your cart, and you get a toast saying so. A cart is a list of items destined for one kitchen, and carrying it across would place someone else's order. The restaurant is recorded on the order and cannot be changed afterwards.

3. Browsing the catalog

Open Catalog. Items are shown as cards, 24 to a page, with a search box (it waits until you stop typing) and a category filter built from the categories that actually exist. Changing either filter returns you to page one.

Each card shows the item's name, its category, its ordering unit, its pack size when one is recorded, and up to three lines of description. Nothing else — the projection the API returns to a chef has no supplier field at all, so there is no supplier to display even accidentally. Two items that look similar may well come from different vendors; that has no bearing on how you order them.

Only orderable items appear: active items that have an active supplier mapping whose supplier is also active. If an item you used to order has vanished, either the administrator deactivated it or its mapping was removed — in both cases it could not be dispatched, so you are not offered it.

4. Building a cart

1. Set a quantity with the stepper on the card and click Add. Quantities are in the item's own unit, so 2 on a case item means two cases. Adding an item you already have merges the lines and the card shows a badge with the quantity in your order.
2. The cart panel sits beside the item grid on a wide screen; on a narrow one, tap the bar at the bottom to open it. You can change quantities or remove lines from either.
3. Click through to Review order when you are ready.

The cart is held in memory only — no local storage, no server-side draft. Reloading the page starts a fresh cart, and so does switching restaurants.

5. Reviewing and submitting

The review page lists every line with a quantity stepper and a remove button, a Notes for this order box (up to 2,000 characters, sent to every supplier the order fans out to), and a summary panel with the restaurant, the line count and the total quantity. Place order submits.

The API validates before it creates anything, and the page turns each failure into something you can act on:

If	You will see
The cart is empty	An empty-order screen pointing you at the catalog
No restaurant is selected	A warning, and Place order stays disabled
A line fails validation	The problem listed against the item's name
An item disappeared from the catalog while you shopped	"An item is no longer in the catalog", naming it — remove and resubmit
An item was deactivated while you shopped	An error naming the item
An item has no active supplier mapping	An error naming the items the administrator must map
The network dropped	"No connection", and an explicit note that retrying is safe

Nothing is created in any of those cases — an order is all-or-nothing.

Submitting twice cannot create two orders. Each submission carries a key that the API remembers for 24 hours: pressing Place order again after a failure reuses it and replays the original response, while editing the cart or the notes mints a new one. On success you are taken straight to the order page.

6. Reading order status

The order page refreshes itself every few seconds while dispatch is in flight and stops on its own once the order settles; a small "Updating…" pill shows when it is polling. Two levels of status matter.

The order as a whole:

Status	What it means for you
dispatching	Accepted, and at least one supplier submission is under way
completed	Every supplier submission on the order succeeded
partial	Some submissions succeeded and some failed — check the line list
failed	No submission succeeded; the administrator has been alerted
pending	Rare: the order was recorded but the hand-off never happened. Tell the administrator

A freshly placed order is dispatching, never pending — the fan-out has already been attempted by the time the page loads.

Each individual line:

Status	What it means for you
pending	Recorded, not yet on the wire
submitted	Sent to the supplier
confirmed	The supplier acknowledged it (Sysco only, via EDI)
backordered	The supplier cannot fill it
rerouted	It was back-ordered and has been sent to the alternate supplier
dispatch_failed	Sending failed after all retries; the administrator has been alerted
backorder_no_alternate	Back-ordered with no alternate configured — needs the administrator

Any line in one of the last four states is pulled into a banner at the top of the page, so you cannot miss it.

Below the lines you get supplier dispatches — one card per dispatch, with its status, the reference the channel returned, when it was submitted and confirmed, the attempt number if it was retried, and the failure reason if it failed. The cards are titled by their reference or a short id: no supplier name appears, and no placeholder pseudonym is invented either, because a stable pseudonym would still tell you which lines share a supplier. Where the system archived a purchase-order PDF for a dispatch, a View PDF button opens it through a short-lived link.

Last is the audit trail, newest first: who placed the order, each submission and what reference came back, every back order and reroute, and every status change. Supplier-identifying fields are stripped out of these entries before they reach you. This is the record the operations team uses when a delivery does not match the order.

note

Delivery dates are not part of this build. The system stores no requested or promised delivery date on an order or a line, and none is shown here — dates are imposed by suppliers on their own paperwork. Adding them would require a new field on the line item and a place to read it from in the inbound acknowledgment.

7. What a back order looks like

Suppose you ordered eight cases of Roma tomatoes and Sysco can only ship five.

1. Sysco's acknowledgment reaches the system on the next inbound poll — they run every 15 minutes.
2. The line becomes backordered and appears in the attention banner.
3. If the administrator configured an alternate supplier for that item, the system dispatches to the alternate immediately and the line becomes rerouted. The audit trail records the reroute.
4. If no alternate is configured, the line stops at backorder_no_alternate and the administrator is emailed. This is the only back-order case that needs a human, and the human is the administrator, not you.

You never confirm or approve a reroute, and the reroute button on the line table is only rendered for administrators. The whole point is that a shortfall does not sit unnoticed until the delivery arrives.

8. Order history

Orders lists every order you can see, newest first, 25 to a page. Filter by status and by date range; a restaurant filter appears only if you are actually assigned to more than one. Click any row to open its detail page.

The identifying column is a shortened form of the order id with the full value on hover. The database does hold a human-readable purchase-order number — it is what suppliers see on the email subject and the PDF header — but no endpoint returns it yet, so the UI cannot show it.

Where to go next

• Order lifecycle — the full state machines behind those statuses.
• Roles and permissions — exactly what your role can reach.
• Product overview — why the system works this way.