用途：为定时或常规任务在轮询、等待长时间操作（如 CI、构建、部署、浏览器作业）时提供防护规则，防止心跳冲突、工作丢失、重复投递，以及因长时间持有外部作业而导致的会话失败。
主要能力与规则：
- 禁止使用 delaySeconds >= 300 的 ScheduleWakeup；短于四分钟的等待应执行一次最多 240 秒的有界 sleep 加一次状态检查，作为单个 shell 调用，然后交回 agent 回合。禁止把多次 sleep 批量放进一个 shell 调用。真正长时间的等待（CI 构建、发布、部署）优先使用持久化工作流或后续任务。
- 自动重试的任务必须带 reboot-retry 标签，手动重建丢失任务时也需加同一标签。
- 长时间轮询必须每两到三分钟调用 store-progress 记录进度，例如 polling CI status (attempt 3/10)。
- 同一心跳陈旧原因连续两次立即失败，通常说明基础设施或生命周期问题，不应创建第三次相同尝试，应通过升级渠道或任务交接机制上报。
- 投递前检查重复：按当前 schedule ID 或标签查询近期任务，并在目标历史中搜索相关时间窗内的等价投递；若已投递则停止并用 store-progress 记录。
- 交付物发出后应完成并退出，不要仅为观察 CI、合并等下游状态而调用 ScheduleWakeup。
- 慢速外部作业采用“先触发再跟进”：启动外部动作，用 store-progress 保存返回的 action/task ID、目标 ID 和一行恢复配方，并在 agent-fs 或持久化工作流步骤中保存恢复状态，随后在新任务中执行收集、过滤、去重与投递。
使用方式：规则以自然语言与示例命令给出，示例涉及 gh pr checks 的聚合判断，需按 bucket 聚合（pending/fail/cancel/passed），不能以退出码代替聚合；no checks reported 应视为 PENDING 而非失败。所有标识符应从当前任务或外部 API 响应解析，不得硬编码。
适用场景：轮询 CI、构建、部署、浏览器自动化、大数据拉取、媒体处理等可能超过约 20 分钟的外部异步作业。
限制：资料未提供具体平台、收费、价格或效果数据；规则依赖部署环境的心跳阈值与存储机制，需按实际部署调整。