E7｜Automations：时刻表叫醒 Session，不是另一条 run_turn
先别把定时任务当成 Goal，也别当成 codex exec 循环
C5 把 Goal 钉成「挂在 thread 上的完成条件」。读到桌面 Automations 的人，会以为那是 Goal 的 cron 版，或以为 core/ 里有一个 scheduler 在 tokio::time::interval。搜不到 cron，就开始在 tasks/ 里加 AutomationTask。
判断先说清楚：Automation 是桌面（或云端入口）按时刻表/事件把一条已有 harness 叫醒。 跑起来仍是 Regular turn + 同一套沙箱。本仓库几乎没有调度器：只有 ThreadSource::Feature("automation") 标记来源（protocol.rs:2782-2796），以及企业闸 InAppLocalAutomation（requirements-only，features/src/lib.rs:254-257, 1423-1426）。闹钟在闭源 App 壳里；GitHub/Slack 触发往往是云端任务（E3），不是本机 cron。
触发源（时间、GitHub、Slack、Gmail…）以当时产品为准。工程师该抄的是：叫醒之后走哪条 Session、cwd 落在哪、和 Goal 差在哪。
1. 两种产品形状：独立跑 vs 同一条 thread 心跳
官方 Automations：
- Standalone： 到点开一次新跑，结果进 Triage。适合每次独立、或跨多个项目。
- Thread automation： 同一条 thread 上的周期叫醒，保留上下文。适合轮询 Slack/GitHub、盯长命令、固定节奏的 review loop。
两者都是 把 prompt 再送进 harness，不是新的 TaskKind。遥测用 thread_source = automation 和用户点的 User、子代理、Guardian、记忆整合分开（ThreadSource 枚举）。C2 跳过子代理和短会话抽记忆；automation 跑出来的 thread 是否进记忆，仍过 C2 的 idle/额度门，不会因为是定时就绕过。
Slack 里 @Codex 开的是 云端任务（E3），不是本机 Automations。GitHub Action 的 openai/codex-action 跑的是 CI 里的 codex exec。三套「自动」：
| 调度在哪 | 执行在哪 | |
|---|---|---|
| 桌面 Automations | 本机 App 壳 | 本机 harness（常 worktree） |
| Slack/GitHub @codex | 云端 | 云端 VM |
| GitHub Action | Actions cron/event | runner 上 codex exec |
不要把 webhook 写进 codex-rs/core。
2. 默认 worktree：别冲人手的 Local
官方 worktree 文档：Git 仓库上，自动化默认 专用后台 worktree；非 git 项目才打在项目目录。Automations 页也写：可选 Local 或新 worktree，两种都在后台；worktree 把改动和未完成的人手工作分开。
这就是 E2 的产品主客户。WorktreeManager 不认识「automation」这个词，只认识第二份 checkout + codex-thread.json。频繁日程会堆很多树——官方建议归档不需要的 run、不要随意 pin。CLI 不自动清理（E2），桌面有 keep-count。
没有默认 worktree 会怎样？每天早上的 triage 在你正在打字的 cwd 里 apply_patch，和并行 Goal 同一类事故。隔离单位仍是 checkout，不是把 automation 拧成 ReadOnly。
非 git 目录没有第二份树：自动化等于和人手抢文件。要隔离，先把项目放进 git，或别在脏工作区开 Local 模式自动化。
3. 时刻表 ≠ 完成条件
| Goal（C5） | Automation | |
|---|---|---|
| 问题 | 怎样才算做完？ | 什么时候再跑一次？ |
| 挂在 | 可持久化 thread | 调度器 + 一条或一串 thread |
| 停 | Complete / clear / pause | 关掉日程、归档 run |
| 人在回路 | 仍可 steer | 后台跑；外发动作仍要批（官方：draft only，你批了再发） |
| ephemeral | 不能挂 Goal | 叫醒需要能落盘的 session；ephemeral 不适合当心跳 |
把「直到测试绿」写成 cron，会在绿了之后还每小时再改一次。把「每天早上扫 Sentry」写成 Goal，没有完成条件，thread 会一直 Active。先在普通 thread 里把 prompt 调对，再「把这条变成 automation」——官方 bug-triage / teammate 用例都是这个顺序。
/goal pause 停的是完成条件驱动的续跑，不停桌面日程。两个开关不要当成一个。
4. 额度、失败、企业闸
Automation 每次叫醒都是一次（或多次）模型和工具消耗，走同一 ChatGPT 额度。C2 在剩余额度低于 25% 时跳过记忆抽取；日程不会因此自动停——低额度时自动化可能直接失败或降质，需要在产品里看 Triage / 失败重试，本仓库没有 automation retry 循环。
InAppLocalAutomation 是托管闸，注释写明不该出现在用户 config.toml。企业关掉它，桌面就不能跑本机日程；云端 Slack 任务是另一条产品开关。
失败重试、cron 语法、时区、多项目 standalone，都在壳里。core 只保证被叫醒的 thread 仍过 B3 审批和沙箱——后台不等于 --yolo。
5. 结语：带走一句话
Automations 是壳上的时刻表：到点叫醒同一套本地（或云端）harness，Git 仓库默认进后台 worktree，免得冲掉人手 Local——它回答「何时再跑」，Goal 才回答「何时算完」；调度器不在 codex-rs/core。