WIN-JHFT4D3SIVT\caoxiaozhu
21c869db62
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
91 lines
3.8 KiB
Markdown
91 lines
3.8 KiB
Markdown
# 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. 每一阶段都要求有明确验证物，而不是只交页面视觉变化。
|
||
|
||
## 阶段依赖图
|
||
|
||
```text
|
||
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 结束前明确。
|
||
|