A question beats a debounce
Refund, void and cancel sit outside our double-tap guard on purpose. Each asks a question first, and a question stops a wrong first press, not only the second.
We spent a day making sure that pressing a button twice sends one write, not two. The shared guard watches every dialog's footer and drops a repeat press inside four hundred milliseconds. Reading its selector, one thing stood out: it matches the primary buttons and the save buttons, and it skips the red ones. Refund, void, delete, cancel an order. A hole in precisely the wrong place, and a one-line fix to widen it.
All eight red buttons, read one at a time
Before widening anything we read every red button in the till. Three of them only change local state and write nothing. One ships disabled and is only enabled once the refund amount checks out. The other four each wait on a question before they write: a reason sheet, or a plain are-you-sure.
So the selector was right. A destructive action here puts a question between the press and the write, and that is a better protection than a debounce, because it also stops the first press being a mistake. A debounce only ever catches the second.
Why widening it would have done harm
The guard drops any repeat inside its window whether or not a write began. Add the red buttons and it would swallow the second press of "Remove item", which is exactly what somebody does to take two things off a bill. We would have shipped a protection that made the till worse at the most ordinary thing it does.
What shipped was a test. Five of those handlers hold their question by convention, and a refund with its confirmation deleted is a button that refunds twice. The test asserts each question exists and comes before the write, and, written as an assertion rather than a comment, that the guard still does not cover the red buttons, deliberately, so the next reader does not fix it.