投递与定时：默认邮件，通道可插拔
一、把"生成内容"和"怎么送达"解耦
内容引擎只产出当日导读；投递层负责送到哪。通道可插拔：
- 邮件（默认）：每天到点发一封到用户邮箱。仪式感最强，像收到导师来信。
- 文档：写成 md/文档，给用户链接。
- 对话：直接在聊天里推送。
- 看板：更新进度看板（见 memory-and-continuity.md），适合不想被打扰的用户。
选哪个在设计阶段 Phase 3 问清；默认邮件。
二、定时任务的三条铁律
每日投递通过定时任务实现。注意：
1. 自包含（最关键）
定时任务每次运行都是全新会话、无记忆。所以任务提示词必须自带一切所需：计划框架、当周/当日安排、邮件模板、语气规则、钩子台账、版本/引用规则、起始日期与"如何从日期算出今天是 Day 几"。 不能依赖"上一次对话记得什么"。需要演化的状态（反馈、节奏、钩子回收）放记忆库，并在提示词里写明记忆库的绝对路径让 agent 去读/写。
2. 幂等（防重复发送）
每次运行先检查"今天是否已发过"。最稳的做法是用投递通道本身当状态：发邮件前先在收件箱/已发里搜今天的"Day N"主题，已存在就停止。 （cron 可能因为补跑、手动 Run now、或抖动而一天触发不止一次——幂等是必须的。）
3. 发送依赖与降级
- 邮件自动发送通常依赖浏览器自动化（如 Chrome 扩展）+ 已登录的邮箱；定时任务只在 App 开着时触发（关着则下次打开补跑）。这些依赖要明确告诉用户，别假装永远能发。
- 发送失败/通道不可用时降级：把当日内容存成文件并通知用户"未能自动发送，已存档，请手动发送"。绝不假装发成功了。
三、起始与编号
- 锚定起始日期；"今天的 Day 编号"从日期推算（注意时区：定时任务的 cron 按用户本地时区）。
- 若计划开始日与期望的"复盘日落在星期几"不对齐（如周中开始但想周末复盘），就让前几天作为过渡/轻量起步，把规律节奏从下一个完整周期接上——并把这个安排如实写清，别为对齐而硬切。
四、首次运行前的授权
- 自动发送/浏览器控制这类工具，定时任务首次运行可能需要用户授权。建议让用户先手动"Run now"一次预授权，避免之后每次卡在权限弹窗。
- 配合幂等检查：预授权那次若算出的是已发过的 Day，会安全跳过、不重复发。
五、反馈回路与投递的关系
- 用户的反馈走交互式对话，由交互式会话压缩进记忆库，并据此更新定时任务的提示词（如"用户嫌太短，后续加量"）或记忆库内容。
- 定时 agent 不要主动去读用户的邮件回复并据此行动（注入风险 + 安全红线）。投递是单向的；调整走对话。