Files
JARVIS/development-doc/plan/war-room-update

War Room 实施计划索引

本目录用于沉淀 War Room 页面的分阶段实施计划。目标不是重写一份设计稿,而是把已经批准的规格文档与仓库当前实现状态对齐,形成一套可直接执行、可验证、可拆分的交付路线。

规格来源:

  • docs/superpowers/specs/2026-04-09-war-room-design.md

当前仓库锚点:

  • frontend/src/pages/war-room/index.vue
  • frontend/src/app/router/routes.ts
  • frontend/src/pages/agents/
  • frontend/src/pages/chat/
  • frontend/src/api/
  • backend/app/routers/

文档说明

文件 说明
README.md 总览、阶段关系、设计原则、风险与推荐顺序
phase-wr-0-current-state.md 当前实现盘点、差距分析、目标边界
phase-wr-1-shell-and-fixed-mode.md 页面骨架、组件拆分、FIXED 模式落地
phase-wr-2-studio-foundation.md STUDIO 模式画布、节点交互、本地编排状态
phase-wr-3-data-contract-and-api.md 前后端数据契约、API、状态管理与 mock 替换
phase-wr-4-teams-runtime-chat-handoff.md TEAMS、Runtime、/chat 执行链与联调收口
checklist.md 供 Codex 或人工执行的勾选清单

推荐阅读顺序

  1. phase-wr-0-current-state.md
  2. phase-wr-1-shell-and-fixed-mode.md
  3. phase-wr-2-studio-foundation.md
  4. phase-wr-3-data-contract-and-api.md
  5. phase-wr-4-teams-runtime-chat-handoff.md
  6. checklist.md

当前总体状态2026-04-10

Phase 状态 说明
WR-0 已完成 已完成现状盘点与目标拆分
WR-1 待开始 先把单文件样机收敛成可扩展页面骨架
WR-2 待开始 补 STUDIO 的真实交互和画布状态
WR-3 待开始 接入真实数据契约与 API
WR-4 待开始 完成 TEAMS、Runtime 与 /chat 执行闭环

当前实现结论

  1. /war-room 页面已经存在,但本质上仍是静态样机。
  2. 主要数据来自 index.vue 内部硬编码数组,尚未接任何 war-room 专用 API。
  3. 页面目前额外存在 runs 模式,这与已批准 spec 的三模式 FIXED | STUDIO | TEAMS 不完全一致。
  4. 当前文件存在中文文案乱码,说明在编码或文案维护链路上已有质量问题。
  5. 页面代码集中在单个 SFC 中,后续接 API、拖拽和 Inspector 交互时维护成本会迅速放大。

总体实施原则

  1. 先拆骨架再接能力,避免在超大单文件上继续叠加逻辑。
  2. 先保留现有视觉语言,再把 mock 数据逐步替换成真实状态。
  3. 先建立最小可运行的本地编排模型,再接后端编排 API。
  4. /war-room/agents 保持风格连续,但不强行共用不稳定实现。
  5. /chat 执行链路必须在计划中尽早定接口,否则 运行 按钮只能长期停留在占位态。
  6. 每一阶段都要求有明确验证物,而不是只交页面视觉变化。

阶段依赖图

WR-0 -> WR-1 -> WR-2 -> WR-3 -> WR-4

不建议跳阶段。尤其是:

  • 没有完成 WR-1 的组件化拆分WR-2 的画布交互会持续堆积技术债。
  • 没有完成 WR-3 的数据契约WR-4 的运行态和 /chat 交接无法闭环。

预估工作量

Phase 预估
WR-1 1.5 天
WR-2 2 天
WR-3 2 天
WR-4 1.5 天
总计 7 天

关键风险

  1. 现有 war-room 样机和批准 spec 在模式定义上已有偏差,实施前需要以 spec 为准清理页面信息架构。
  2. STUDIO 模式若引入拖拽库或画布库,会触发“无新依赖”的约束;默认应优先使用现有能力或原生方案。
  3. GET /api/agents/templates 与现有 agent.py 路由职责边界需要先定,避免后端语义混乱。
  4. /chat 如何接受编排执行上下文目前仍是待确认项,必须在 WR-3 结束前明确。