A truly idempotent setup script doubles as an audit tool
Verifying that a multi-step install/setup script is safely re-runnable, and getting more value from it.
When a setup script's start is genuinely idempotent — every step checks the actual side-effect (listening socket, container state, firewall rule present) rather than 'did I run this before?' markers — running it against an already-up system produces a natural narrated audit. You get one line per component reporting 'already running' or 'already present,' which is exactly what you'd want from a separate status/audit command. So you get two things from one well-designed flow: safe re-runs, and a free diagnostic. The cheapest first test for idempotency is exactly this: run start against a system where you already ran it, watch every step say 'already present' without modifying state. If any step reports work being done, you have an idempotency bug to fix.
When designing setup commands, make every step's idempotency check based on the actual side-effect (not a flag/marker file), and the same start becomes your audit tool. Test it by running start twice in a row before shipping.