本 Roadmap 把两条主线视为同等优先级并同步推进：
- 主线 A（对话入口）：OpenClaw relay + 飞书 ACK/进度/卡片交互，把复杂请求稳定变成“可追踪任务”
- 主线 B（任务内核）：OpenCroc scan/graph + pipeline（生成/执行/自愈/报告），把任务真正跑完并产出可交付物
节奏：每个 Sprint 2 周。日期以 2026-03-23 为 Sprint 1 起点，可按实际排期平移。
状态标记按 2026-03-23 当前主干代码保守判断：
已完成= 已落地；进行中= 已有部分实现或底层能力，但未达到该条目 DoD；未开始= 仓库中尚未看到对应实现闭环。
- 飞书侧体验：ACK p95 < 2s；进度投递成功率 > 99%；卡片更新乱序/重复 < 0.1%
- 任务闭环：一次复杂请求能在 Studio 看到任务链路，并能稳定产出 report/文件/可复现日志
- 工程质量：
npm test与 CI 绿；新增能力都有最小可回归用例与文档
- 新增/变更的接口有明确的契约（请求字段、鉴权、幂等、错误码）
- 单元测试覆盖关键分支（成功、失败、重试、鉴权失败、幂等重复）
- 关键路径有结构化日志字段（至少包含
taskId，涉及飞书时包含chatId/messageId） - 文档与示例可跑通（至少 1 条 smoke 流程）
目标：先把入口安全、投递稳态、幂等去重做扎实，再把 OpenCroc 的阶段进度与飞书展示对齐。
交付（主线 A：OpenClaw/飞书）
- 已完成：Topic 基座（strict-by-thread）：为每个 Feishu/OpenClaw 对话线程生成确定性的
topicId，并禁止跨topicId的自动关联，避免“莫名其妙把两件事混在一起” - 已完成：详情页增强：在
/tasks/:id详情中展示该话题的机器人 roster 与话题任务串（基于topicId/ 星球关系） - 已完成：手动关联作为补充：支持手动把不同话题的任务用星球关系关联（等价 topic merge 的最小形态）
- 已完成：
/api/feishu/webhook的安全校验与幂等去重“可持久”：支持 verification token / signature 校验，且重启后 TTL 内仍可持续去重 - 已完成：
/api/feishu/relay与/api/feishu/relay/event增加最小鉴权（共享密钥/HMAC），并有回放保护（timestamp/nonce） - 已完成：出站投递稳态：对 429/5xx/网络抖动的重试退避策略明确，可配置，且不会造成无限重试与消息风暴
交付（主线 B：OpenCroc scan/pipeline）
- 已完成：任务阶段与飞书展示对齐：scan/pipeline/execute/report 的 stage 文案与百分比策略统一（减少“跳进度/卡住”）
- 已完成：
scan与 Studio UI 的数据落盘/缓存策略明确（至少保证重启后能恢复最近任务与图谱快照）
Sprint 1 DoD（验收）
- 已完成：针对 webhook/relay 鉴权与去重的单测覆盖完成，并在 CI 里跑
- 已完成：本地 smoke：能在飞书看到 ACK -> 多次 progress -> done/failed；ACK 失败与出站重试场景由单测覆盖
- 已完成：文档：补齐“飞书鉴权与部署”专节，覆盖
.env -> config -> webhook/relay 鉴权 -> systemd -> smoke 验收
目标：让 waiting 不再只是“发一条文本提示”，而是可交互、可回填决策并驱动任务继续。
交付（主线 A：飞书卡片交互）
- 已完成：
waiting状态生成带按钮的卡片（例如：继续执行/停止/只生成报告/仅 scan），并支持回调；按钮点击已回填到统一决策流 - 已完成：增加决策提交接口（例如：
POST /api/tasks/:id/decision），支持 option id 与可选 free text - 已完成：卡片
card-live原地更新：waiting -> 点击按钮 -> 任务继续 的状态切换已接入完整决策流 - 未开始：Topic 决策门禁：机器人自动产出“会影响外部/会写入产物/会修改代码”的内容时，必须先进入
waiting，由你在飞书卡片里确认
交付（主线 B：任务编排）
- 进行中：为“有风险/有成本”的动作加决策点：已有 waiting 状态与入口，尚未覆盖 self-heal source mutation / PR 前确认
- 进行中：让 chat 意图分类（pipeline/scan/report/analysis）与可交互按钮保持一致（避免 UI/后端分叉）
Sprint 2 DoD（验收）
- 进行中：一条完整流程：飞书触发 -> 进入 waiting -> 点按钮 -> 任务继续 -> 最终在飞书收到完成摘要 + 任务链接；代码链路已打通，待真实飞书 smoke 验证
- 已完成：决策回调与任务状态变更有单测（覆盖 route / callback / signed webhook / 重复点击幂等）
目标：把“能跑”提升到“可长期跑、可排障、可监控”。
交付（主线 A：服务化与排障）
- 未开始：增加
/healthz（以及必要的/readyz）并明确判断标准（配置、存储、飞书凭据可用性） - 进行中：systemd 或 Docker 交付物完善：README/systemd 与基础排障文档已存在，完整交付清单仍待补齐
- 进行中：飞书相关关键错误可定位：已有基础排障文档，尚未形成完整生产诊断矩阵
- 未开始：Topic 可观测：能按
topicId聚合查看任务列表、成功率、耗时与失败原因分布（先做 server 侧聚合 + 基础 UI）
交付（主线 B：scan/graph 的可观测）
- 进行中：scan 过程输出阶段日志与耗时统计（扫描器已有 progress 回调与 duration，未见完整聚合展示）
- 进行中：为超大仓库提供降级策略（已有
maxDeepScan等底层参数，报告里的解释性输出未闭环）
Sprint 3 DoD（验收）
- 进行中：以“重启/故障/权限不足/429”作为必测场景，能给出明确可执行的排障建议
- 进行中：文档补齐：Troubleshooting + Deployment 两段可独立读懂并复现
目标：让飞书收到的不只是“完成了”，而是“可交付的结果”；让 pipeline/run 的质量结果可量化。
交付（主线 A：飞书回传内容升级）
- 进行中：done/failed 的最终摘要模板化：已有最终状态与基础摘要，产物链接与更完整模板仍待补齐
- 进行中：将 checklist/workorder/token usage（如有）作为可选附件回传（文本或卡片分块）；内核 reporter 已有，飞书侧回传未完全接通
- 未开始：Topic 知识图谱 v1：一个话题内支持沉淀
方案/需求/design/tasks/结论/风险/决策等节点，并在详情页或 Studio 中可视化（先从最小节点类型集开始）
交付（主线 B：执行与自愈质量）
- 进行中：执行质量门禁（quality gate）默认启用且可配置：内核能力已接入，默认启用/配置项与飞书侧呈现仍待补齐
- 未开始：自愈策略分级：config-only 默认优先，source mutation 需进入 waiting 并二次确认
Sprint 4 DoD（验收）
- 进行中：在飞书里能看到“可落地的下一步”：已有部分失败摘要与任务详情链路，报告链接与建议动作未完整闭环
- 未开始：至少 1 套端到端回归：pipeline -> execute -> (optional heal) -> report，数据在 Studio 可回看
目标：从“单任务互斥”走向“可控并发”，避免多 chat/多请求导致互相干扰。
交付（主线 A：多会话治理）
- 未开始：按 chatId/tenant 的并发与队列策略：默认串行，同 chat 不乱序；跨 chat 可并行但有全局上限
- 未开始：任务取消/超时：能在飞书触发取消，并在 Studio 与飞书都可见（含幂等）
- 未开始：Topic 自动归类与分配（增强）：基于话题图谱节点类型与标签，把工作自动分派给对应机器人维护（默认保守，只在同
topicId内工作）
交付（主线 B：远程 scan 与任务化运行）
- 未开始：支持把
opencroc scan <target>的能力任务化（本机路径或远端仓库），并把结果回传到飞书 - 未开始：明确缓存策略：同一 target 的重复 scan 可以复用（可配置禁用）
Sprint 5 DoD（验收）
- 未开始：压测式验收：并发 5 个 chat 触发任务，队列/并发策略符合预期，且不会把进度串线
- 未开始：取消/超时与恢复（重启后仍能看到任务最终态）有回归用例
目标：把“飞书桥接”和“OpenCroc 内核”边界明确，支持未来多渠道与多形态部署。
交付（主线 A：通知渠道插件）
- 未开始：抽象
NotificationChannel（send/update/ack/decision callback），飞书实现作为第一个插件 - 未开始：预留第二渠道占位（例如 stdout/webhook/slack 任一），验证核心不被飞书绑死
交付（主线 B：内核拆分与兼容）
- 未开始：明确包与命名策略：
openclaw-feishu-progress与opencroc的 CLI/配置兼容路线图（不破坏现有用户） - 未开始：将 scanner/graph/insight/pipeline/execution 的依赖关系写成“架构契约”（谁能依赖谁）
Sprint 6 DoD（验收）
- 未开始：新增渠道不会影响飞书能力，且新增渠道有最小 smoke
- 未开始：README 与配置文档更新，包含迁移/兼容说明
- OpenClaw 的
mode只支持daily|idle，没有真正的never。如需“等同只靠/new、/reset手动切会话”，用超大idleMinutes规避自动切会话。 - OpenClaw 侧配置生效通常需要重启正在运行的
openclaw/gateway进程或服务。
- 多租户与权限（Studio 鉴权、审计日志）
- 更强的 LLM 约束推理（链路规划/自愈策略更可控）
- 执行平台化（worker 池、任务分片、artifact 存储与检索）