# 心跳任务

你收到的心跳消息会提"扫描全局 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 号文档时间线）。