Adding is never a request, and a request says what it would do

[sridharkalaibala]

Two asks, both about the moment a customer changes their mind.

"if customer add new order no approval required. we can just send. if any cancel only need approval after few seconds based on settings."

"when customer aks for change. cancel then desktop or captain app clearly can see the changes. what was before and what change customer wahts? cancel item or cancel order."

More food needs nobody's permission

The asymmetry is real rather than a convenience. An extra naan costs the kitchen a naan it is glad to sell: nothing is wasted, nothing already cooked is thrown away, and the only answer anybody was ever going to give is yes. Holding that in a queue until somebody notices is a customer waiting on a decision that was not one.

Taking something away is the opposite. The biryani may be in the pan. That is food already paid for in labour and ingredients, and whether it can be called back is a judgement only somebody standing in the kitchen can make.

So the window now gates only the taking away. Inside it nothing has started and the order is still the customer's, exactly as before. Outside it, a request carrying both has its halves answered separately: "two more naan and drop the biryani" used to wait as a single wish until somebody looked - now the naan is already being made by the time the shop reads the question about the biryani.

A delivery or a hotel room is still refused outright in both directions. That is not the same argument: the window is about the kitchen having started, a venue commission is somebody else's money in the total, and adding to it moves what they are owed.

The bug that would have been

changeCustomerOrderItems reads its list as the order the customer wants, so a line left out of it is a line removed. Sending "just the additions" would have silently cancelled everything else - the exact opposite of a request to add something. There is a test named after it.

And the card says what it would do

It listed only the lines that moved. "Chicken Biryani: 2 to 1" tells a person nothing about whether that is most of the order or a detail of it, so they open the sales screen to find out - by which time they are no longer deciding in a hurry.

Every line is drawn now, the untouched ones stepped back, with what it was and what it would become side by side:

Chicken Biryani   2 → 1
Butter Naan       REMOVED
1 × Dal Tadka                 (dimmed: not changing)

A line going to nothing says REMOVED rather than "1 → 0", because zero is the single most skimmable-past number on a card full of numbers.

"Cancel item or cancel order"

Every request used to say "Asked to change", whether a customer had dropped one naan or emptied the order. Now that adding never becomes a request, every change request is something being taken away, so the card can finally name the question: Cancel the whole order / Remove everything on the order / Remove an item / Remove some items / Asked for fewer.

"Remove everything" matters on its own: a shop that says yes to that has no order left, and calling it "remove some items" would have somebody end an order thinking they were trimming it.

Two things caught while building

A request already in the queue can carry an addition made before this shipped, and one with no items at all predates the queue sending the whole order. The renderer reads both; the existing dock test now says so.

A code example inside a comment became a translation site again - the collision scanner reads the two-argument i18n.t form out of source, and a comment explaining that rule contained one. Same trap as three weeks ago, same fix.

Captain has no requests surface at all

You said "desktop or captain app". Desktop has the dock and this improves it. Captain does not have this at all - grep for change_requested, cancel_requested or any attention queue across that repo returns nothing. A waiter on a handset cannot see a customer's request today and this PR does not change that; it is a separate piece of work in another repo, and I would rather say so than half-build it here.

Checks

• 22 new tests: 11 driving the service with a mocked repository, 11 driving the real card in a DOM
• Root suite 2,672 of 2,675; the three remaining need frontend/public built, which CI does
• API suite 10,782 of 10,782
• 6 new lang_ keys in all 17 packs, each spelled out so the scanner can see it; English answers 3,393 of 3,393

[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.