Unguarded `rm -rf` after a silently-failed `mv` causes irreversible data loss on a cloud-sync (file-provider) mount

Summary
The agent ran a destructive cleanup on a live cloud-sync folder (Proton Drive,
macOS File Provider). It issued:
mv "$DIR"/.a "$DIR"/.b "$DEST"/
rm -rf "$DIR"
In zsh, a glob matching nothing triggers nomatch, which aborts the whole mv
before it runs. The rm -rf was on a separate line (not &&-guarded), so it
executed anyway and deleted the folder. Two sibling files were lost in the
operation and — unlike other deletions — did NOT appear in the cloud Trash,
making them unrecoverable.

Root cause

• rm -rf chained after mv with no success guard (&&).
• Destructive op run in-place on a live cloud-sync mount, where deletions

propagate server-side and can bypass Trash.

• No independent copy made before a destructive reorg of irreplaceable files.

Impact
Irreversible loss of user files.

Requests

1. Safer defaults / guardrails for destructive file ops (esp. rm -rf) on

cloud-sync / file-provider paths.

1. Encourage copy-then-verify-then-delete; never unguarded rm after mv.
2. Consider a warning when rm -rf targets a known file-provider mount.