The disable has to be the first line
The register’s forty buttons matched none of the office double-tap guard. Following the sale to the four buttons that send it found each one already safe.
The office got a document-wide guard against double presses, and the register did not, because the register is its own page and does not load the office's script. On a touchscreen, mid-service, where the writes are money, that looked like the worst possible gap. The fix wrote itself: move the listener into the file both surfaces load.
Measured first, and it would have done nothing
The register's main screen has forty visible buttons, and not one of them matches the selector the guard uses. The till names everything in its own vocabulary. Moving the listener would have changed nothing while letting "the till is guarded now" go into the notes. A selector that matches nothing reports zero, and zero is also what a broken feature reports.
Then we drove it with writes refused at the network layer. Tapping a dish added a line. Pressing Pay and Cash on the main screen sent nothing at all, because on that screen they are navigation, not the sale. That probe had measured the wrong buttons, so it said so instead of reporting a clean result.
Follow the write to the button that sends it
The sale is one request. We followed it backwards through the code to exactly four buttons, and every one of them disables itself as its first statement, before anything is awaited, and gives itself back on every refusal path. The register had been safe all along. The office was the surface that was not.
Nothing shipped for the till, because nothing needed to. What shipped was a test that those four buttons disable on their first line, not merely somewhere in the handler. A disable that comes after the first wait is a gap, and on that screen the gap is a second sale.