Waters ChurchandClaude Opus 5
32f0d06536
The alerts were written for whoever was debugging them, not for whoever reads them on a phone on a Sunday. They led with the mechanism and left the reader to work out whether anything was actually broken. Each one now opens by saying what is and is not affected — the checklists and the website are almost always fine, and an off-site copy problem is not an emergency — then what happened, then what to do. The scary-sounding ones say plainly that previous backups are untouched, because that is the first thing worth knowing and it was never stated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deployment bits that live outside the app
org.waterschurch.checklist-drive-backup.plist
The LaunchAgent that runs the nightly off-site backup. It belongs in
~/Library/LaunchAgents/ on one always-on Mac — currently the ingest Mac
(NA-Ingest, account Studio). Install with:
cp deploy/org.waterschurch.checklist-drive-backup.plist ~/Library/LaunchAgents/
launchctl load ~/Library/LaunchAgents/org.waterschurch.checklist-drive-backup.plist
The path in it matters more than it looks. It points at ~/checklist-app, not
~/Documents/…, and that is not cosmetic: macOS TCC does not let launchd execute
anything inside ~/Documents, ~/Desktop or ~/Downloads. When the project lived in
~/Documents the agent failed instantly every night with
/bin/bash: …/backup-to-drive.sh: Operation not permitted
logging nothing, for eight days, because the script never started. Keep the checkout outside those folders on any machine that runs this agent.
The same restriction applies one level down: launchd can stat a named file under
~/Library/CloudStorage but cannot list the directory, which is why
backup-to-drive.sh checks explicit filenames instead of globbing.
A LaunchAgent only fires while that user is logged in. If the Mac is asleep at 04:15, launchd runs the job shortly after it wakes, so a missed night self-heals — but a Mac that is off, or logged out, backs nothing up and says nothing.