112 lines
4.1 KiB
Markdown
112 lines
4.1 KiB
Markdown
|
# WR-0 当前状态与目标边界
|
|||
|
|
|
|||
|
|
## 1. 现状盘点
|
|||
|
|
|
|||
|
|
### 1.1 已有能力
|
|||
|
|
|
|||
|
|
1. 前端已有路由 `frontend/src/app/router/routes.ts -> /war-room`。
|
|||
|
|
2. 页面主体已存在于 `frontend/src/pages/war-room/index.vue`。
|
|||
|
|
3. 页面已有较完整的科幻视觉语言：
|
|||
|
|
- 顶部指挥栏
|
|||
|
|
- 左侧资源面板
|
|||
|
|
- 中央主舞台
|
|||
|
|
- 右侧 Inspector
|
|||
|
|
- 底部 Runtime Strip
|
|||
|
|
4. 页面已经有四组静态展示数据：
|
|||
|
|
- `fixedOps`
|
|||
|
|
- `studioNodes`
|
|||
|
|
- `teams`
|
|||
|
|
- `runFeed`
|
|||
|
|
|
|||
|
|
### 1.2 当前缺口
|
|||
|
|
|
|||
|
|
1. 页面仍是单文件实现，结构、状态、样式全部耦合在一个 SFC 内。
|
|||
|
|
2. 当前数据全部 hardcoded，没有 Pinia store、没有 composable、没有 API 层。
|
|||
|
|
3. Inspector 并不真正跟随画布选中项变化。
|
|||
|
|
4. STUDIO 只是示意图，没有拖拽、连线、缩放、平移、删除等 spec 级交互。
|
|||
|
|
5. TEAMS 模式只有静态卡片，没有成员拓扑、协作协议详情、操作入口。
|
|||
|
|
6. Runtime feed 只有静态列表，不反映真实运行记录。
|
|||
|
|
7. 顶部按钮没有闭环：
|
|||
|
|
- `NEW AGENT`
|
|||
|
|
- `LAUNCH FLOW`
|
|||
|
|
8. 文案中存在乱码，说明页面内容还未进入可交付质量线。
|
|||
|
|
9. 现有页面多出 `RUNS` 模式，与批准 spec 不一致。
|
|||
|
|
|
|||
|
|
## 2. 设计与实现的差距
|
|||
|
|
|
|||
|
|
| 维度 | Spec 要求 | 当前状态 | 结论 |
|
|||
|
|
|------|-----------|----------|------|
|
|||
|
|
| 模式数量 | FIXED / STUDIO / TEAMS | fixed / studio / teams / runs | 需要收敛模式定义 |
|
|||
|
|
| 数据来源 | API + 可持续维护的数据结构 | 本地 mock | 必须抽离 |
|
|||
|
|
| 组件结构 | WarRoomPage + 子组件 | 单文件 | 必须拆分 |
|
|||
|
|
| FIXED | 模板浏览与实例化 | 静态卡片 | 可复用现有视觉，但要接真实数据 |
|
|||
|
|
| STUDIO | 可编排画布 | 仅示意图 | 需要实做交互层 |
|
|||
|
|
| TEAMS | 群组协作视图 | 静态卡片 | 需要补数据与拓扑 |
|
|||
|
|
| Runtime | 实时事件滚动 | 静态假数据 | 需要接执行记录 |
|
|||
|
|
| /chat handoff | 可运行当前编排 | 未落地 | 必须定义接口 |
|
|||
|
|
|
|||
|
|
## 3. 目标边界
|
|||
|
|
|
|||
|
|
本轮计划的目标是把 `/war-room` 做成“可维护、可接真实数据、可触发执行”的页面，而不是一步做完所有高级编排能力。
|
|||
|
|
|
|||
|
|
本轮完成标准：
|
|||
|
|
1. 页面结构完成组件化和状态分层。
|
|||
|
|
2. FIXED / STUDIO / TEAMS 三模式与 spec 对齐。
|
|||
|
|
3. 至少一条最小编排链路可以保存并交给 `/chat` 执行。
|
|||
|
|
4. Inspector、Runtime、资源面板不再是纯静态展示。
|
|||
|
|
5. 现有乱码文案清理完成。
|
|||
|
|
|
|||
|
|
本轮不强求：
|
|||
|
|
1. 完整 BPMN 级流程设计器。
|
|||
|
|
2. 真正的多人实时协同编辑。
|
|||
|
|
3. 复杂权限系统。
|
|||
|
|
4. 高级运行回放或可视化 tracing。
|
|||
|
|
|
|||
|
|
## 4. 建议目标架构
|
|||
|
|
|
|||
|
|
### 4.1 前端
|
|||
|
|
|
|||
|
|
建议拆分为：
|
|||
|
|
- `frontend/src/pages/war-room/index.vue`
|
|||
|
|
- `frontend/src/pages/war-room/composables/useWarRoomPage.ts`
|
|||
|
|
- `frontend/src/pages/war-room/components/ModeStrip.vue`
|
|||
|
|
- `frontend/src/pages/war-room/components/ResourceBay.vue`
|
|||
|
|
- `frontend/src/pages/war-room/components/InspectorBay.vue`
|
|||
|
|
- `frontend/src/pages/war-room/components/RuntimeStrip.vue`
|
|||
|
|
- `frontend/src/pages/war-room/components/stage-fixed/*`
|
|||
|
|
- `frontend/src/pages/war-room/components/stage-studio/*`
|
|||
|
|
- `frontend/src/pages/war-room/components/stage-teams/*`
|
|||
|
|
- `frontend/src/api/warRoom.ts`
|
|||
|
|
|
|||
|
|
### 4.2 后端
|
|||
|
|
|
|||
|
|
建议按职责拆分：
|
|||
|
|
- `backend/app/routers/agent.py`
|
|||
|
|
- 扩展模板读取接口，或显式挂载模板子路由
|
|||
|
|
- `backend/app/routers/orchestration.py`
|
|||
|
|
- `backend/app/routers/team.py`
|
|||
|
|
- `backend/app/schemas/war_room.py`
|
|||
|
|
- `backend/app/services/war_room/`
|
|||
|
|
|
|||
|
|
### 4.3 状态
|
|||
|
|
|
|||
|
|
建议建立统一页面状态：
|
|||
|
|
- 当前模式
|
|||
|
|
- 资源列表
|
|||
|
|
- 当前选中项
|
|||
|
|
- 当前编排图
|
|||
|
|
- 团队列表
|
|||
|
|
- 运行态 feed
|
|||
|
|
- 加载与错误状态
|
|||
|
|
|
|||
|
|
## 5. 前置决策
|
|||
|
|
|
|||
|
|
1. 以批准 spec 为准，移除或降级当前 `RUNS` 模式。
|
|||
|
|
2. 先不引入新依赖；STUDIO 默认使用原生事件 + SVG 方案。
|
|||
|
|
3. Agent templates 与 orchestrations 的 API 职责分离，不把所有 war-room 数据都塞进一个接口。
|
|||
|
|
4. `/chat` 执行链先走最小方案：
|
|||
|
|
- 选择当前 orchestration
|
|||
|
|
- 生成执行 payload
|
|||
|
|
- 跳转 `/chat` 并带上 orchestration id 或 execution context
|
|||
|
|
|