recurring-checklist

8 Commits 1 Branch 0 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
Waters ChurchandClaude Opus 5	ff6785b800	Send backup alerts to a person, not just the shared inbox Deploy web to NAS / deploy (push) Successful in 1m2s Details Failures went to REPORT_EMAIL, which is the media@ shared inbox the Sunday digest already uses. An alert competing with a routine weekly mail in a shared inbox is an alert that gets scrolled past, which is most of the way back to the logfile nobody read. ALERT_EMAIL is now a separate, comma-separated list for breakage only, falling back to REPORT_EMAIL so a machine whose .env predates this still alerts somewhere rather than silently not at all. Verified by sending one test alert, which arrived. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-24 14:18:47 -04:00
Waters ChurchandClaude Opus 5	3d82e46951	Make the off-site backup find Drive, and say so when it cannot The nightly copy to Drive had been dead since 15 September. DRIVE_DIR pointed at Apps/Backups/Checklist Backups; the folder is Apps/Checklist Backups, with no Backups level. The guard for a missing folder did its job and exited — into a logfile nobody reads, so from the outside a broken backup and a healthy no-op looked identical. Eight days were missing; this run copied them. That is the second time the same failure has hidden in the same place. The header comment already records the first: ten weeks stale in July, found in September. Correcting the path alone would leave the mechanism that hid it untouched, so: - The Drive folder is probed rather than hard-coded, across every mounted GoogleDrive-* account and both known folder layouts. The laptop mounts christian@ where the Studio mounts media@, and the folder has moved once already, so a literal path is the wrong thing to depend on. - Every failure now emails as well as logs, via scripts/alert.js, which reuses the server's own SMTP settings. A failed alert never masks the failure it was reporting. - A run that does not error but leaves the newest off-site copy more than STALE_DAYS old now alerts too. That is the check that would have caught both incidents; the error paths only fire when the script actually runs. What this still cannot catch is the script never running at all — a sleeping Mac or an unloaded LaunchAgent is silent by construction. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-24 14:16:50 -04:00

Author

SHA1

Message

Date

Waters ChurchandClaude Opus 5

ff6785b800

Send backup alerts to a person, not just the shared inbox

Deploy web to NAS / deploy (push) Successful in 1m2s

Details

Failures went to REPORT_EMAIL, which is the media@ shared inbox the Sunday digest
already uses. An alert competing with a routine weekly mail in a shared inbox is
an alert that gets scrolled past, which is most of the way back to the logfile
nobody read.

ALERT_EMAIL is now a separate, comma-separated list for breakage only, falling
back to REPORT_EMAIL so a machine whose .env predates this still alerts somewhere
rather than silently not at all.

Verified by sending one test alert, which arrived.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-09-24 14:18:47 -04:00

Waters ChurchandClaude Opus 5

3d82e46951

Make the off-site backup find Drive, and say so when it cannot

The nightly copy to Drive had been dead since 15 September. DRIVE_DIR pointed at
Apps/Backups/Checklist Backups; the folder is Apps/Checklist Backups, with no
Backups level. The guard for a missing folder did its job and exited — into a
logfile nobody reads, so from the outside a broken backup and a healthy no-op
looked identical. Eight days were missing; this run copied them.

That is the second time the same failure has hidden in the same place. The
header comment already records the first: ten weeks stale in July, found in
September. Correcting the path alone would leave the mechanism that hid it
untouched, so:

- The Drive folder is probed rather than hard-coded, across every mounted
  GoogleDrive-* account and both known folder layouts. The laptop mounts
  christian@ where the Studio mounts media@, and the folder has moved once
  already, so a literal path is the wrong thing to depend on.
- Every failure now emails as well as logs, via scripts/alert.js, which reuses
  the server's own SMTP settings. A failed alert never masks the failure it was
  reporting.
- A run that does not error but leaves the newest off-site copy more than
  STALE_DAYS old now alerts too. That is the check that would have caught both
  incidents; the error paths only fire when the script actually runs.

What this still cannot catch is the script never running at all — a sleeping
Mac or an unloaded LaunchAgent is silent by construction.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-09-24 14:16:50 -04:00