先给判断
在 Scheduled 页面看到一个 Active 任务，只能证明调度配置已经保存。它不能证明任务真的创建了隔离 worktree、读到了最新远端、正确处理了无候选状态，或在第二次运行时保持幂等。无人值守是一个需要运行记录证明的系统属性，不是一个开关标签。
OpenAI 的官方说明确认，桌面端 Scheduled Task 可以使用本地项目，也可以在新的隔离 worktree 中运行；需要本机保持开机、桌面应用保持运行，项目路径仍然可用。官方也建议先观察最初几次运行，再调整提示词、工具或节奏。本文把这些要求转成一份可复查的验收方法，不把当前 Omnihex 的一次 Canary 运行外推成 Scheduled 已经稳定。
任务存在、任务可运行、任务可恢复
三个状态经常被混为一谈。第一是存在：任务有名称、Active 状态和下一次执行时间。第二是可运行：到点时它能打开正确项目，使用预期模型，建立隔离 worktree，并完成远程身份预检。第三是可恢复：进程中断后，下一次运行能从 durable receipt 继续，而不是生成第二篇文章或第二个发布回执。
对本地项目而言，桌面端和电脑本身是执行前提。一个服务器上的 cron 可以在机器关机时继续触发，但本地 Scheduled Task 不具备这个假设。项目路径、Git 凭证和网络权限也会影响结果；它们不应被隐含在一次手工成功里。
隔离 worktree 解决什么，不能解决什么
worktree 可以把定时运行的工作目录和手头未提交的修改分开。它减少了“自动任务改到人正在编辑的目录”的风险，也让每次运行有明确的分支边界。但 worktree 不是权限沙箱，不会自动限制网络、GitHub 写入或 Cloudflare 部署。隔离目录仍然需要显式的最小权限和发布门。
一个可靠入口至少应先 fetch、核对 main 与 production，再从指定基线建立临时 worktree。状态分支应单独 fetch，并用 compare-and-swap 写入 claim、run 和 publication receipt。任务不能把上一次 worktree 中的 ignored 文件当作队列或激活状态。
首轮观察矩阵
最小的三次观察不是重复跑同一条成功路径，而是覆盖三种决策：
- 没有合格候选：零文章、零素材提交、零 push、零部署，并清理锁。
- 有一个低风险候选：只处理一个 logical candidate，写入唯一 run 与 publication receipt。
- 证据不足：保留
draft: true，记录一个可恢复原因，不要求 Founder 在中间补操作。
每次都应记录 worktree 路径、开始和结束状态、锁状态、远端 SHA、候选身份和最终 action。第二次使用同一 run_id、source hash 或 slug 时，结果必须是 resume、already published 或 no-op，而不是新的文章、资产或提交。
一个可复制的验收清单
任务 Active 且下一次执行时间正确
电脑和桌面端在执行窗口可用
canonical 仓库干净，main/production 身份可解释
新 worktree 不依赖上一轮 ignored 状态
state branch schema 与 activation 可读取
最多处理一个 logical candidate
无候选零写入，低风险才进入发布链
中断后由 run/publication receipt 恢复这份清单的重点是把“无人值守”拆成可观察的契约。当前材料只证明产品支持这些运行方式；它没有证明任何 Omnihex 任务在所有未来执行中都不会失败。
什么时候不应自动发布
出现来源不可访问、claim 没有 evidence、许可证不清楚、生产 route delta 无法精确计算、Git 身份漂移或状态 CAS 冲突时，自动任务应保留草稿并停止。观测链如 GSC、Analytics 或浏览器控制可以降级，但生产身份、草稿隔离、CI 和 live smoke 不能降级。
来源与边界
OpenAI 文档支持 Scheduled Task、本地项目和隔离 worktree 的运行模型；本文关于 Omnihex 的状态分支、receipt 和首轮三路径，是当前仓库的工程设计与验收方法，不是 OpenAI 对该仓库结果的证明。