心跳任务

你收到的心跳消息会提"扫描全局 OKR 目标状态"——那是通用触发文案，对你不适用。 你要看的是本公司的 goal/task 板（tools.md 里的读接口），不是 OKR。

每次心跳

• [ ] 查 GET /tasks?status=blocked 和 ?status=failed，看有没有需要处理的
• [ ] 查 GET /goals?status=active，扫一眼有没有明显该调整优先级的
• [ ] 查 GET /tasks?subtaskKind=decomposed_work&status=draft，看有没有等你派发的子任务 （46 号文档 Phase 3：subtask-planning 拆出来的步骤，落库就是普通 draft task， 不会自己跑起来，要你判断"现在放不放"）
• [ ] 都正常就直接回复"心跳正常"，不要为了"用一下工具"而用工具

子任务怎么派（decomposed_work）

• 看到的每一条都已经是具体到"这一步做什么"的粒度（subtask-planning 已经拆过了）， 不需要你再判断"这条该不该做"——只需要判断节奏：现在放，还是等前置步骤先跑完再放。
• 想知道前置步骤是谁：任务详情里的 dependsOn 数组。不用你自己排队——depends_on 没完成的，enqueue 了也会被调度器自动拦成 blocked，一次性把一条 task 下所有 draft 的子任务全部 enqueue 是安全的，先后顺序、并发几个都是调度器的活，不是你的。
• 派一条：POST /tasks/<taskId>/enqueue（跟你派自己提的草稿任务是同一个端点，同一条权限）。
• 这批子任务会走一张轻量图（只有实现+验证两步，不是公司完整的组织架构那套）， 成本比一条顶层 task 低很多，但目前还没有正式跑过真实验证——如果发现同一个 task 下的 子任务频繁失败或者结果质量不行，在回复里如实说，不要自己想办法绕过去。

发现问题时

• 具体判断依据见 tools.md 的"什么时候该提新任务、什么时候该改优先级"一节
• 新提的任务一律带 draft:true，判断确实清楚、值得马上跑再 enqueue
• 不确定的情况，把观察写进正文回复，不要瞎猜着动手改数据

不用管的

• 正在排队 / 正在跑但没超时的 task——那是调度器的活，不用你盯
• 纯技术性的失败（比如基础设施抖动）——引擎自己有重试和熔断机制（sweepOrphanedRunningNodes + sweepStaleRunningAgentCalls，见 45 号文档 Part A；后者是持续性扫描，25 分钟自动处理一次， 心跳例行扫描不用替它兜底，不要主动去查每条 running task 卡了多久）

用户直接把"这条任务卡住了"转给你时该怎么办

心跳例行扫描不用管上面那条，但如果是用户主动转发过来、明确让你看一条卡住的任务，按 tools.md「卡住的 run 节点」一节的两步处理（先查、再用 force-fail 端点）。不要自己对着 卡住的 run/节点拉起一个新的 agent 会话去亲自跑一遍——那是绕过引擎，会跟卡住的状态打架； 上一次这么干直接陷入了工具调用死循环，最后靠人手动中断才停下（见 45 号文档时间线）。