长任务依赖与验收编排助手

核查任务依赖和总预算，保留已验收结果，避免不确定外部操作被重复执行

把长任务拆成可以独立验收的节点，保留已经验收的结果，只对失败节点安排返工。特别处理「外部操作可能成功，但本地没有收到结果」的情形，避免重复发送、发布或付款。

这是本地任务规划与检查工作流，不是 Kortix、Suna 或 Flowith 的官方集成，也不复刻其运行环境。讨论这些产品的长任务需求时可使用本流程；实际连接方式和可用能力必须另查对应产品当前官方说明。本包不要求 AI-HIVE 账号或外部服务。

将目标变成可验收的图

1. 明确最终交付物、截止时间、预算币种、每一步已有工具以及不能自动执行的动作。
2. 每个节点写唯一 id、依赖 depends_on、预期 deliverable、验收条件 acceptance、预留费用 reserve_cost。
3. 依赖描述数据来源，不是泛泛的「先做研究」：例如 compare 依赖 vendor-a 和 vendor-b 各自的有来源事实表。
4. 把对外操作设为 external_write: true，为同一个业务动作分配稳定 effect_key，记录用户授权 authorization_ref。修改措辞、重试网络或换执行器不应生成新的业务动作键。
5. 初始预算 spent 包括已产生的费用，reserved 包括正在执行节点的预算，不能通过清空它们让后续节点获得预算。

参考 计划样例。不需要为简单的一步任务构造复杂图。节点输入不得包含密码、Token 或整份私人账户数据。

运行前检查

在技能目录运行：

bash

python3 -B scripts/next_tasks.py examples/plan.json
python3 -B -m unittest discover -s tests -v

检查器只读计划并输出 JSON：依赖是否有效、当前可执行节点、被挡住的原因及是否具备合并条件。它不启动任务、不连接网络、不发消息、不调度唤醒、不花费预算，也不验证外部证据真伪。ready 是计划建议，不是执行授权。

对于多个可执行节点，按输入顺序在剩余预算内预留，防止每个节点单独不过预算、同时执行却超支。需要其他优先级时，先与用户明确后调整计划顺序。

节点状态与返工

状态	下一步
pending	依赖全部 accepted、预算足够后才可开始
running	等当前执行结束；不得另起同节点
needs_review	查看产物，按 acceptance 核验；不能供下游使用
accepted	保留产物及 evidence_ref；下游可引用
failed	记录原因；本地只读任务可提出 retry_decision=approved 的返工计划
uncertain	只查远端结果/回执；禁止重发或换 effect_key

外部写入失败即使收到「允许重试」，检查器也不将其自动放进 ready。先核对平台状态；已完成则补回执并进入验收，明确未发生才由用户批准新的执行步骤。遇身份错误、权限拒绝或平台审核限制，不能把它当网络故障反复执行。

验收与合并

每个 accepted 节点必须有实际产物引用 evidence_ref；外部写入还要有 receipt_ref。人工或宿主必须读取这些引用，检查是否满足 acceptance，然后才能把状态设为 accepted。

最终交付包含：依赖图、节点状态、可复用产物、当前阻塞项、已花费/预留/剩余预算，以及下一步需要谁采取什么动作。只有所有节点 accepted 才标记 merge_ready；这仍是结构检查结果，不是质量保证。缺一个来源的研究分支就只返工该分支，不重跑已经成功的外部动作。

工具不具备后台运行能力时，交付可恢复检查点并明确已停止。只有用户明确授权、且宿主实际提供调度能力时，才另行设置定时任务。使用 验收场景 检查上述边界。