# 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 结束前明确。