The empty-folder check is a good safeguard, but I think there’s another failure mode worth considering: a stale build artifact.

Imagine a CI pipeline where a failed build leaves the previous dist/ directory intact. The deployment job still succeeds, runs rsync --delete, and removes pages and assets that were added in a newer release. The source directory isn’t empty, so the usual safety check won’t catch it.

Would it make sense to generate a manifest containing the build’s Git commit SHA and file hashes, then validate it against the intended release before calculating the deletion set? I’d also keep the previous release available for an atomic rollback. That way, the deploy process verifies not just that files exist, but that the source actually represents the version we intend to publish.