Stop.
Confirmation dialogs are dead UX. Users have been trained by internet browsers with pop ups and other poorly designed pieces of software with poorly worded dialog boxes to completely ignore dialog boxes. I've tested this several times. Users don't even consciously register that the dialog box ever appeared. You can watch them, right over their shoulder, and as soon as they close a dialog, they will turn to you and ask "what do I do now?" you will ask, "what did the pop-up box say to do?", and they will respond "what pop-up box?". Walk them through the process again, don't pre-warn them about when the dialog appears, and they will do it again.
This is also why crapware is so easy to install on any system that has wizard-based installers.
Do not use dialog boxes. It's better to hire two testing teams and set them against each other to break the software. Test and test and test again, then disallow bad behavior. The "plugger" example should not have allowed issuing a fire command on its own location, unless some explicit, completely out-of-band, one-time-use option would enable it so. Actually, better yet, it should not re-initialize the target location on start-up with the device's location. Just clear out the target, when the user tries to fire, they will see the lack of target and probably know "oh, must be because I changed the batteries". There is a reason they are called "fail-safe"s. You create failure modes that err on the side of safety. It's better if the device fails to fire than to fire at the wrong target.
I don't care if you can't afford it. If you cannot afford a large testing infrastructure, then you can't afford to make safety-critical software at all. You cannot solve this problem with software.
These situations come about when you have a management infrastructure that cares more about feature lists than correctness. I can hear them now, "we need to move faster", and "if it works, don't fix it."