A fix that never reached the fourth screen
A shared button guard was wired onto three surfaces and never loaded on the fourth. Nothing was red. The screen that needed it most was the till.
A few weeks ago we built a small shared thing: a helper that takes a button and the work behind it, disables the button the instant somebody presses it, changes the label to say what is happening, and puts it back if the work fails. It is thirty lines. It exists because a double tap on a slow connection is not a user error — it is the most ordinary thing a person does when a screen does not answer.
We wired it onto the hall's tab controls, six buttons in the staff app, and the availability grid. We wrote the tests. We wrote it up. Everything we touched was better.
The file it lives in is not loaded on the till
That is the whole finding. The stylesheet and script list for the register is not the same list as the guest pages, and the file holding the shared helper was never added to it. So every button on the till, and every button in the back office, had been outside the reach of a fix we believed was general. Nothing failed. No test went red, because the tests check the screens the helper is on. The gap was not a bug in the helper; it was a gap in who could call it.
We found it by opening one screen. The morning "still out of stock?" question that a kitchen answers at opening had no guard of any kind on its Done button: no disable, no relabel, no in-flight flag. We measured it with a deliberate double tap against a real server. The first tap sent four requests to switch items back on and one to confirm the rest. The second tap sent all five again.
Why this is worth an operator's attention
Not because of this particular button. Because of the shape. A shared fix creates a belief — that is handled now — and the belief covers more ground than the code does. The gap is silent by construction: the screens that have the helper work, so the feature looks finished from every direction except the one nobody looked from.
If your supplier tells you a class of problem has been dealt with, the useful question is not whether they fixed it. It is which screens the fix is actually loaded on, and how they would know if one had been missed. In our case the honest answer was a list of script tags, and the till was not on it.
The guard on that morning question now uses the register's own idiom instead, and disables in the same instant as the tap rather than after the first request comes back. The wider job — walking the rest of the till and the back office button by button — is still a job. We have written down that it is a job, which is at least better than writing down that it is done.