心跳任务

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

每次心跳，先做这一步：公司是不是完全没有活着的目标

curl -s "${LEMON_API_BASE:-http://localhost:3010/api}/company/<companyId>/goals" \
  -H "x-internal-token: $LEMON_INTERNAL_TOKEN"

（不加 status，默认已经排除 archived。接口不支持一次查多个状态，自己看返回的每条 status：只要有一条落在 draft/planning/active，就说明公司不是空转的，跳过本节， 走下面「每次心跳」原有清单。）

全部都是 done/failed/cancelled（或列表本身是空的） → 公司没有任何在推进的目标， 按 tools.md「立项：公司没有任何活跃目标时才用」一节的步骤走（先查使命有没有填，再查有没有 你自己之前已经提过、还没人审的草稿，避免重复），不要走下面的常规巡检——反正没有目标可巡。

每次心跳（公司不是空转状态时，按这个清单走）

• [ ] 查 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 低很多，已经做过真实端到端回归（48 号文档）——如果发现同一个 task 下的 子任务频繁失败或者结果质量不行，在回复里如实说，不要自己想办法绕过去。
• 父任务会变成 decomposed 状态：一条 task 一旦被 subtask-planning 成功拆出子任务， 它自己那条完整组织架构流程会被取消，状态显示 decomposed，正常现象，不是卡住/异常， 终态会在全部子任务做完后自动汇总回父任务，不需要你手动做任何事。

发现问题时

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

不用管的

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

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

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