principle-make-operations-idempotent

Make an operation idempotent by designing it to converge to the correct end state no matter how many times it runs. Scan for existing state at startup, clean stale artifacts by content equivalence, and add reconciliation steps wherever partial state would change the next run's outcome.

Handle stale locks with PID-based stale lock detection: record the owning process ID in the lock and check whether that process is still alive before honoring it. If the PID is dead, the lock is reclaimed automatically instead of blocking forever.

Ask three questions: what happens if it runs twice in a row, what happens if the previous run crashed at every possible point, and does re-execution converge to the same end state. If any answer depends on leftover state, add a reconciliation step.

Idempotent design fits state-mutating commands, lifecycle operations, and processing loops where crashes and retries are normal. It does not replace transactional guarantees for operations requiring strict atomicity across external systems you do not control.