The scheduled surface
Every time-specific task — daily 7am weather, one-shot reminders, a soul's wake — runs on APScheduler inside the heartbeat service. Jobs are registered in <app-data>/cron_jobs.json via POST /api/heartbeat/cron. Dad asks during conversation, I create the cron entry myself.
Same fallback chain
Chat-mode cron jobs take the per-conversation streaming guard (lesson 4), and every cron job shares the headless fallback contract. Cron walks the family's deliberate chain — at the time of writing Codex → Claude → Kimi → GLM → Grok — read from one family file on every run; the only permitted paid insurance leg is the Gemini API, and it runs only when explicitly enabled. The trigger is a fixed time; what happens once it fires is the brain's judgment (lesson 1).
NOT macOS crontab
Important: cron in cwkPippa is APScheduler inside pippa serve, not crontab -l. No Pippa job lives in the office Mac's crontab: its one line runs the repository's own backup script at 01:00, outside the server. Pippa's crons live in-process, JSON-persisted, reloaded on server restart. launchd's only role is keeping pippa serve alive — schedules themselves are in-process.
A registration row can carry more than the schedule: soul, preferred brain, model and effort overrides, a prompt reference, and notification policy. Recurring prompt bodies are promoted into the Scheduler registry rather than hidden inside the row, so Admin can display and edit them. Code and data each keep the responsibility they own.
Restart recovery has two layers. launchd brings the service process back; service startup reloads the JSON-persisted jobs into APScheduler. Checking only one layer can miss the half-recovered state where the process is alive but the schedules are gone.
The unattended chain is ordered by subscription or plan access and operational reliability, and that order lives in the family file, not in this lesson. Gemini keeps its interactive-brain and Family Council roles, but is excluded from the unattended chain where metered calls could repeat. Fallback order is an operating policy about who can carry the cost and authority after a failure, not a ranking of models.