A customer is told when the kitchen usually has it ready

[sridharkalaibala]

A customer places an order, gets a token number, and then hears nothing. The list of this phone's orders says "With the kitchen" and that is the whole of it - which is the moment somebody walks up to the counter to ask, the single interruption an ordering channel exists to remove. Every food app they have ever used shows a time.

What is deliberately not being built

Nothing in this product knows when food is actually finished. No cook marks a ticket done, so there is no "ready" signal to report and this does not invent one - no fake progress bar, no "your order is being prepared" animation driven by a timer.

What the shop has told us is how long each dish takes and how many tickets were ahead of this one. Those two together are an honest estimate, offered as one. The word "usually" in "Usually ready by about 8:05" is doing real work and is not padding.

The slowest dish, not the sum of them

A kitchen does not cook the biryani, then the naan, then the dal. Several hands work at once and the order leaves the pass when the slowest thing on it is done.

Adding them up would quote an hour for a meal that takes twenty-five minutes, and an estimate that is always wrong in the same direction stops being read. The queue is added on top of that, because it is time the food spends not cooking.

Frozen at the moment it is made

Worked out once and stored on the order. A figure recomputed on every refresh would creep as other orders arrive, and a promise that moves while somebody watches it is worse than one that is a little wrong - they can plan around wrong; they cannot plan around moving.

Where it stays silent

• No prep times entered - no estimate at all, and the row looks exactly as it always has. Falling back to the queue alone would quote the time the food spends waiting and none of the time it spends cooking, which is smaller than the truth and the worst direction to be wrong in.
• Not accepted yet - a shop that holds orders for approval has not started cooking, so a clock time is a fiction. It says "About 25 minutes once the shop accepts it" instead, and the server counts from when the kitchen was told, not when the customer tapped.
• Already past - an estimate counting backwards at somebody still waiting reads as the shop being late rather than as an estimate being approximate, and there is nothing they can do with it. It stops being shown.
• Cancelled - nothing.

The clock is rendered on the customer's own device from an instant the server sends, so a guest ordering from a hotel in another timezone reads their own watch.

What wiring it found

The estimate was computed after the document that uses it. let in a temporal dead zone - it would have thrown on every single online order. Caught before it ran, but only because the line numbers were checked rather than assumed; node --check passes on it happily.

Checks

• 25 new tests: 13 on the rule itself, 12 driving the real sentence-writer in a DOM with a frozen clock
• Root suite 2,645 of 2,648; the three remaining need frontend/public built, which CI does
• API suite 10,754 of 10,754
• Both sentences in the ordering dictionary, and the two byte-identical copies verified

It needs #788 to be useful

This is the second half of the prep-time work. A shop with no prep times sees nothing here - which on production today is every shop, until somebody opens Tools → How long a section takes and sets three numbers.

[github-actions]

Merged to develop. Anyone can test this - you do not need write access.

Try it at https://develop.posnic.io, or run it yourself:

git fetch origin develop && git checkout develop
npm install && npm --prefix api install
npm run dev   # then http://localhost:3000

When you have tested it, say what you did and what happened, and set
QA passed or QA failed. If you cannot set labels, just comment -
a maintainer will.

Reporting that something is broken is as useful as fixing it. It is
better found here than by a shopkeeper.