taskflow-inbox-triage

TaskFlow 收件箱分流

通过 skills/taskflow/SKILL.md 中托管的 Lobster 运行/审批/恢复流程，使用 skills/taskflow/examples/inbox-triage.lobster。默认批次为合成数据，且已完成分类。工作流会将所有项目分流到 business、personal 和 later ID 列表中，暂停以等待实际审批，然后返回这些列表，不会发送任何内容。

输入和结果

每个项目都必须包含非空的 id（最多 80 个字符）和 route（business、personal 或 later）。批次最多包含 20 个项目。无效输入会明确失败；空批次会生成三个空列表。在初始运行时使用 argsJson 覆盖默认值，例如：

{
  "items": [
    { "id": "demo-business-1", "route": "business" },
    { "id": "demo-personal-1", "route": "personal" },
    { "id": "demo-later-1", "route": "later" },
    { "id": "demo-business-2", "route": "business" }
  ]
}

将此对象序列化为 argsJson 字符串传入。尝试示例时请使用合成 ID。审批仅确认预览，不会授权或执行实际发送。

明确连接真实收件箱工作流

真实控制器需要一个收件箱读取器和分类器来生成上述有界输入，还需要为这些路由提供适配器：

路由	真实控制器职责
business	通过已授权的 Slack 适配器发帖，保存返回的 thread ID，然后等待匹配的人工回复。
personal	通过已授权的渠道适配器通知所有者，并记录发送结果。
later	保留有界的摘要引用，以供明确安排的日终运行使用。

示例不提供这些适配器。每个项目在分流前都要完成分类；不要根据批次中的第一个项目来决定如何处理混合批次。请使用可直接调用的分类工具或真实适配器，不要假定存在内嵌的 openclaw.invoke 桥接。真实副作用发生前必须先审批。

对于业务回复，控制器会注册事件监听器，在 waitJson 中调用 setWaiting 并设置有界的线程关联信息，且仅在收到匹配的回复后恢复运行。Lobster 审批令牌、回显的等待 JSON 或单独调用 setWaiting 都不会安装该监听器。不支持内嵌的 Lobster 输入/ask 请求。

如果分类使用脱离当前流程的任务，请先通过公开的请求方绑定插件路径启动任务，然后再使用 runTask 建立关联。等待任务实际完成后再解读结果；pending 或观察超时不代表任务最终失败。失败时，记录流程结果为失败/受阻并报告。若启动或建立关联被拒绝，不要合成子任务。

只保留继续流程所需的 ID、简短摘要和游标。重启后或遇到修订冲突时，重新加载绑定到所有者的流程并完成对账，然后再应用下一次状态转换。检查每次变更的结果，包括 finish；不得根据未经检查的结果报告成功。有关由控制器驱动的恢复和取消，请参阅 Task Flow。