At my old job we had some unsafe-ish operations, mostly you needed to do --force or --really. Typically you would invoke without it, then it would say "heres what I am gonna do, do this again with --really and I will do it for sure"
There was one tool that had '--yolo', because if you're at that point of an operational crises - you might as well give it a shot.
I too have written force features. You've likely never seen this, but in tool design, prefer git push's --force-with-lease design.
Force With Lease says "I believe X is true, and because of that, force". The tool can check that X is indeed true, and if so force, but if it's not true the human was wrong and they ought to re-consider and obtain a new "lease" before we make the change.
In Git this "lease" is the current ref of a remote, if we specify this, but actually it's wrong, that means the state of the remote system has changed, and we need to re-consider whether our forced change is still appropriate. e.g. While you and Bill were quickly changing colors.js to hackily disable dark mode, turns out Sarah guessed the actual bug, and replaced main.css with a patched version that works fine even in dark mode, if you force-push your change, instead of zapping the broken change it zaps Sarah's fix!
This approach works best where you can actually take some sort of "lock" and avoid clashes at the tool level, but there's some benefit even without that at the human level.
--force-with-lease is great, but I really wish it was --force and the current force was --force-without-checking-if-its-safe or something. The more dangerous one being the shorter one is unfortunate, and I think it's worth the breaking change to swap them (with some sort of config option to gradually do the switch).
An even better design is to have the command write out essentially a script file for what it is about to do, then the —-force flag would execute that script rather than start from scratch. That way you avoid having things come up between when you do a dry run and the real deal. This isn’t always applicable but sometimes can be a really nice pattern.
this works well for things that are shell scripts, and we certainly had at least one " check the output and then pipe it into sh". But for the most part that falls away when you have a lot of objects and abstractions and stuff.
I am going to have to steal --yolo. Love it. At a past job it was basically our team slogan (extremely tongue in cheek... has anyone ever said YOLO seriously?) any time we were deploying a change we were at all nervous about. I can't believe we never codified it into our tooling.
There was one tool that had '--yolo', because if you're at that point of an operational crises - you might as well give it a shot.