예약된 표면
시간이 정해진 task 는 전부 — 매일 7am 날씨, 일회성 reminder, 영혼 깨우기까지 — heartbeat service 안의 APScheduler 에서 돌아. job 이 <app-data>/cron_jobs.json 에 POST /api/heartbeat/cron 통해 등록. 아빠가 conversation 중 요청, 내가 cron entry 직접 생성.
같은 fallback chain
chat 모드 cron job 은 대화 단위 streaming guard (lesson 4) 를 거치고, cron job 은 전부 같은 headless fallback 계약을 따라. cron 은 가족의 신중한 체인을 걸어. 이 글을 쓰는 시점엔 Codex → Claude → Kimi → GLM → Grok 이고, 실행할 때마다 가족 파일 하나에서 읽어와. 허용된 유료 보험은 명시적으로 켠 Gemini API 뿐이야. trigger 는 정해진 시간이고, 그게 울린 뒤 무슨 일이 일어나는지는 두뇌의 판단이야 (lesson 1).
NOT macOS crontab
중요: cwkPippa 의 cron 이 pippa serve 안 APScheduler, crontab -l 아님. office Mac 의 crontab 엔 피파 job 이 하나도 없어. 거기 있는 한 줄은 서버 바깥에서 새벽 1시에 저장소 자체 백업 스크립트를 돌리는 거야. 피파 cron 이 in-process 살아, JSON-persisted, server restart 시 reload. launchd 의 유일한 역할이 pippa serve 살아있게 하는 거 — schedule 자체가 in-process.
등록 row에는 schedule만 있는 게 아니야. soul, preferred brain, model과 effort override, prompt reference, notification policy가 함께 묶일 수 있어. recurring prompt 본문은 row 안에 숨기지 않고 Scheduler registry로 승격해서 Admin에서 보고 고치게 해. code와 data가 각자 맡을 자리를 지키는 거야.
재시작 복구도 두 층이 맡아. launchd는 service process를 다시 올리고, service startup은 JSON에 남은 job을 APScheduler에 재등록해. 둘 중 하나만 확인하면 "프로세스는 살아 있지만 일정은 사라진" 반쪽 복구를 놓쳐.
무인 체인은 구독·플랜 성격이랑 운영 안정성을 기준으로 줄 서고, 그 순서는 이 lesson 이 아니라 가족 파일에 살아. Gemini는 interactive brain과 Family Council 자리는 지키지만 metered call을 반복할 수 있는 무인 chain에서는 빠져 있어. fallback 순서는 model 서열이 아니라 실패했을 때 누가 비용과 권한을 감당할지에 대한 운영 정책이야.