feat(docs): add development documentation, prototypes, and war-room components

Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>

development-doc/plan/war-room-update/README.md

@@ -0,0 +1,90 @@
+# 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 结束前明确。
+