The transparent-photo ship script ends with this block, printed to my terminal after a successful push:
Cleanup of old desktop staging (run when ready):
rm -rf ~/Desktop/Images/Image\ *.png
rm -rf ~/Desktop/Images/about-photo-webp
rm -rf ~/Desktop/Images/about-photo-webp-q92
rm -rf ~/Desktop/Images/about-page-bundle
rm -rf "$HOME/Desktop/Images Transparent Website"
rm -rf ~/Desktop/Images/about-transparent-bundle
The script never runs any of those itself. The choice is deliberate.
Auto-deletion is one of those moves that always sounds reasonable in the abstract. The bundle has shipped, the assets are in the repo, the desktop staging is no longer needed. Why ask the user to clean up manually?
Because state on disk is the only state I might want to recover from. If the merge breaks in some way I haven’t anticipated, or if I want to re-run a step with a tweak, the staging folder is the source. If the script auto-deletes it, my recovery path depends on git history and Drive backups, both of which are slower and more brittle than just opening Finder.
There’s an asymmetry to operations like this. Pushing to remote is recoverable: I can revert the commit, push again. Running rm -rf is recoverable only if the deleted file existed somewhere else. The script can afford to be aggressive with the operations that are easy to undo. It should be conservative with the ones that aren’t.
The cleanup commands as printed text are also a documentation artifact. Six months from now, when I’m re-running a similar pattern, the script’s final output is a clean checklist of what should still exist and what shouldn’t.
The principle: a script can push code without asking, but it asks before it deletes. Reversibility is a property of operations.