# 演化路线图

> MVP 见 [mvp-design.md](mvp-design.md)。本文档只记录方向性结论与已知风险，到了对应阶段再细化设计。

## ① TUI 优雅降级（⏸ 挂起）

- **决策（2026-10-09）**：维持挂起，MVP **不为此预留任何抽象**；若日后成为真需求，按**重构**处理，届时再统一回传通道。
- 形态：TUI 无法内嵌显示，降级为提供一个本地端口，浏览器访问。
- 已知问题：回传通道变为「浏览器 → localhost → 插件 → 会话」，监听端口需要鉴权（同机任意进程可 POST）。
- 挂起的前置决策：是否把 MVP 的回传抽象为统一「HTTP POST + 一次性 token」通道（iframe/TUI 复用，演化零重写，代价是 iframe 内多一次 fetch）。
- 冻结的跨会话设计（Q10）：选择器候选仅限「已用 /webapp 打开且运行中」的会话 + 标准警告。

## ② 任意后端（方向 ✅，阶段化推进）

与 MVP 单 HTML 并存不悖（杀鸡焉用牛刀）。回传契约从「特定变量+组件」放宽为「向特定端口发请求 + 另一端监听」——判断正确，采纳。

阶段：

1. **2a 多文件静态站点**：仍是伺服目录，几乎免费，先做。
2. **2b 有限定要求的后端**：限定数据库/功能集合的部署形态，相对可控。前置调研：阿里 meoo、Kimi App 等同类产品实现（workbuddy 能把任意单端口部署上云，机制待查）。
3. **2c 完整后端进程**：已知风险——DSH 的 sandbox 是 pwsh/文件策略执行器而非进程容器；AI 写的服务器以用户权限常驻后台 = 安全事故面。端口分配、崩溃重启、会话结束杀进程、依赖安装 = mini-PaaS，工作量约 5-10 倍于 MVP。到这一阶段前必须单独评审沙盒方案。

## ③ 双向事件流（概念已修正，最后做）

- **采纳形态**：webapp 订阅**宿主侧**事件流（turn 结束、工具完成等宿主自己知道的事件），挂在 ② 的通道上加一条 SSE/WS 即可，不难。
- **删除形态**：「模型随时主动向 webapp 推」——模型逐 turn 存在，turn 外没有决策者，这等于 Agent 常驻化，超出插件范畴，不做。
- 从现实 AI 发展的实际历史看，这一点最晚做、相对最难，维持排期末位。

## 其他非 MVP 记录

- 外部独立使用：直接用浏览器打开（无回传）——天然成立，无需工作。
- 「回传时开一个新对话」：`sessionController.create` + `prompt` 路径可行，记录待排期。