docs(iteration): add post-sdk roadmap

This commit is contained in:
2026-08-06 12:06:04 +08:00
parent 359dc1bb66
commit ef528a147b
2 changed files with 259 additions and 0 deletions
+6
View File
@@ -5,6 +5,7 @@
```text ```text
迭代/ 迭代/
├── plan.md # 当前阶段之后的总体路线和排期原则
├── 00.base/ ├── 00.base/
│ └── 00.base.md │ └── 00.base.md
├── 01.kernel/ ├── 01.kernel/
@@ -27,6 +28,11 @@
5. 已确认的结论需要回填主定义文档和验收项;评审记录保留原始意见,用于追溯,不能替代主定义文档; 5. 已确认的结论需要回填主定义文档和验收项;评审记录保留原始意见,用于追溯,不能替代主定义文档;
6. 迭代完成后的实现验收、发布复盘等文档也保留在对应目录内,并使用清晰的递增编号。 6. 迭代完成后的实现验收、发布复盘等文档也保留在对应目录内,并使用清晰的递增编号。
## 后续总计划
当前阶段之后的路线、迭代拆分、范围边界和完成标准见 [plan.md](plan.md)。该文件记录已确认的整体方向;
每个具体迭代开始后,仍需在自己的目录中创建主定义文档和独立评审记录。
## 评审优先级与遗留问题 ## 评审优先级与遗留问题
评审问题使用 `P0``P5` 标示处理优先级。优先级表达的是“最晚何时必须解决”,而不是问题描述的 评审问题使用 `P0``P5` 标示处理优先级。优先级表达的是“最晚何时必须解决”,而不是问题描述的
+253
View File
@@ -0,0 +1,253 @@
# LineUp App 后续迭代计划
**更新时间:** 2026-08-06
**计划状态:** 已确认,作为后续迭代拆分和排期依据
## 1. 计划结论
前三个阶段已经建立了 LineUp App 的基础:Runtime 托管 IM、Runtime 具备应用编排能力、MiniApp SDK v1
和两个内置 MiniApp 参考实现已经完成验证。
下一步不建设应用市场,也不马上扩展多 Agent、语音或视频。下一阶段先把已有的 Runtime、SDK 和 MiniApp
契约做成用户真正可以使用的“应用工作区”。
当前推荐路线:
```text
Runtime 工作区与应用闭环
→ 第一个真正可用的 MiniApp
→ 本地 App 管理与签名 Bundle
→ 再评估应用分发和市场
```
## 2. 已完成的基础
### 2.1 Runtime 托管 IM
`00.base` 已建立客户端基础闭环:
- Runtime 独占网络连接、同步循环、消息存储、outbox 和 App Inbox
- 登录、同步、本地回显、Markdown 和 Agent 状态保持稳定;
- 入站消息经过作用域校验、去重和恢复;
- Chat 只能通过 SDK 和 Runtime Action 工作。
### 2.2 Runtime 应用编排基础
Runtime 已具备应用实例、焦点和生命周期的核心模型:
- App Registry
- App Instance Manager
- App Focus Manager
- App Lifecycle Manager
- Tool Router 和 App Orchestrator
- App 子会话、前后台切换、关闭和恢复的契约。
### 2.3 MiniApp SDK v1 与参考实现
`03.sdk_and_coreapp` 已完成并通过自动化测试和浏览器验收:
- Interact 是唯一的 `system` MiniApp
- Task Dashboard 和 Whiteboard 是普通 `bundled` MiniApp
- MiniApp 通过 SDK 接收 Inbox、Tool、进度、结果、生命周期、Surface 和 Capability 请求;
- 标准 `notice / choice / confirm / input` 属于 Interact 的人与 Agent 交互,不是 MiniApp 内部表单;
- App 子会话、交互归属、关闭收口、继续处理和重启恢复已有明确规则;
- 当前单 Agent MVP 边界保持不变。
需要注意:当前完成主要证明了 Runtime 契约和参考实现正确,用户可见的完整应用工作区仍需下一阶段收敛。
## 3. 第四次迭代:Runtime 工作区与应用闭环
建议迭代目录:
```text
迭代/04.runtime_workspace/
```
### 3.1 目标
把 Runtime 的生命周期和会话模型接到真实 Web/Tauri 界面,跑通一条完整的用户流程:
```text
进入 Interact IM
→ Agent 请求启动 Task Dashboard
→ Runtime 创建 App instance 和 App 子会话
→ Task Dashboard 进入前台,Interact 进入后台
→ Agent 发送任务进度或向用户提问
→ 用户回答、查看任务或关闭 App
→ Runtime 收口未完成 Tool,可靠发送已提交结果
→ 子会话结束并在 IM 中折叠保存
→ Interact 恢复
→ 用户查看历史或继续处理
→ 继续处理创建新的 instance 和新的子会话
```
### 3.2 主要工作
1. **接通 App 工作区界面**
- 显示当前前台 App
- 支持 Interact、Task Dashboard、Whiteboard 的切换;
- 显示后台、挂起、关闭和恢复状态;
- App 启动失败时恢复 Interact
- 刷新或重启后恢复工作区。
2. **接通 App 生命周期**
-`AppLifecycleManager``AppFocusManager``AppOrchestrator` 接入真实 Host
- 区分后台、挂起和真正关闭;
- 关闭后停止新 Tool 投递;
- 将未终态普通 Tool 收敛为 `cancelled(app_closed)`
- 已提交结果继续通过 outbox 发送;
- 关闭后恢复前一个有效前台 App。
3. **完成 App 子会话展示**
- 主 IM 显示 App 子会话折叠卡片;
- 支持展开已结束子会话;
- 已结束子会话只读;
- “继续处理”创建新 instance 和新子会话;
- 不把 App 内部按钮、表单和编辑动作写入 IM。
4. **完成 Interact 交互覆盖层**
- Interact 前台时,在 IM 中以内联卡片显示标准交互;
- bundled MiniApp 前台时,可以在其上方显示 Interact 的交互层;
- 展示位置变化不改变交互归属;
- App 关闭不自动取消未回答的标准交互;
- Agent 可以通过 `interaction.dismiss` 远程取消交互。
5. **让 Task Dashboard 成为第一条完整用户流程**
- Agent 创建任务;
- Agent 更新任务进度;
- 用户查看任务状态;
- Agent 向用户提问;
- 用户回答;
- Tool 完成后 App 不自动关闭;
- 用户关闭任务面板;
- 任务子会话保存并可继续处理。
6. **补充端到端验收**
- Web Reference Host 完整验收;
- Tauri Desktop Host 至少完成一条代表性流程;
- 验证刷新、断线、重启、关闭、恢复和重复提交;
- 检查 Runtime 生命周期、交互、Tool 和恢复日志。
### 3.3 不在本迭代范围
- 应用市场和服务端 App Catalog
- 远程下载、第三方发布和在线更新;
- 多 Agent 连接、切换和多 Agent 会话列表;
- Audio Mode 的真实媒体能力;
- Video Mode 的真实媒体能力;
- Whiteboard 的多人协作和复杂绘图能力;
- Task Dashboard 的完整项目管理功能。
### 3.4 完成标准
```text
用户可以从 Interact 启动 Task Dashboard
Runtime 可以正确创建、切换、后台化、关闭和恢复 App;
App 子会话能在 IM 中折叠、展开和继续处理;
标准交互在不同前台 App 下仍归 Interact
关闭 App 时 Tool 和 outbox 收口正确;
刷新/重启后 App、焦点、子会话和待处理交互按规则恢复;
Web/Tauri 代表性流程通过端到端验收;
所有 P0P3 评审问题清零。
```
## 4. 第五次迭代:第一个真正可用的隔离 MiniApp
建议迭代目录:
```text
迭代/05.first_isolated_miniapp/
```
第四次迭代完成工作区后,再把一个 MiniApp 从“参考实现”推进为“真实隔离运行的应用”。
### 4.1 推荐顺序
优先选择 Task Dashboard 作为第一条产品流程,Whiteboard 作为第二条安全和 Surface 验证流程。
### 4.2 Task Dashboard 方向
- 真实 Surface 挂载;
- Agent Tool 和用户操作共存;
- 任务状态恢复;
- 任务子会话和继续处理;
- App enable / disable
- Inventory 随状态变化更新。
### 4.3 Whiteboard 方向
- 受限 Surface 中的画布状态;
- 状态 patch
- Artifact 导出;
- Artifact 元数据校验;
- 重启恢复;
- 验证不能访问 Host DOM、Tauri、认证状态、任意网络和其他 MiniApp 数据。
暂时不做多人协作、云端同步和复杂绘图工具。
## 5. 第六次迭代:本地 App 管理和签名 Bundle
建议迭代目录:
```text
迭代/06.local_app_management/
```
这一阶段仍然不建设在线应用市场,只解决本机的应用管理和安全运行边界:
- App Registry 管理界面;
- 本地安装记录;
- App enable / disable / remove
- 版本记录和回滚;
- 本地签名 Bundle
- Bundle 完整性和签名校验;
- 验证失败不污染当前可运行缓存;
- Inventory 更新和 Agent 可见性变化;
- App 删除时实例、焦点、Inbox、Surface 和私有数据的收口。
## 6. 第七次迭代之后:再评估应用分发和市场
只有在 Runtime 工作区、本地 App 管理、SDK、Surface 和签名 Bundle 都稳定之后,才评估:
- 服务端 App Catalog
- 应用搜索和详情;
- 下载和更新;
- 发布者身份;
- 第三方 MiniApp
- 审核、撤回和安全策略。
应用市场不是当前阶段的基础设施,而是建立在前面几层都稳定之后的分发能力。
## 7. 更后面的方向
### 多 Agent
在单 Agent 工作区稳定后再设计:
- Agent 列表和切换;
- 多 Agent 会话;
- 多 Agent outbox
- App 子会话归属;
- Inventory 和权限隔离。
### Audio Mode 与 Video Mode
语音和视频应复用当前 Runtime SDK、Tool、Capability、Artifact 和会话模型,不建立独立的 Agent
通信链路。它们需要单独处理媒体权限、设备选择、实时连接、中断和恢复,因此不进入当前两次迭代。
## 8. 当前排期原则
```text
先完成“真实可用的应用工作区”
再完成“一个真正隔离的 MiniApp”
再完成“本地安装和签名管理”
最后才评估“远程分发和应用市场”
```
任何新增功能都应先回答三个问题:
1. 它是否依赖 Runtime 已经稳定的生命周期和会话模型?
2. 它是否能通过现有 MiniApp SDK、Surface、Capability 和 Artifact 边界实现?
3. 它是否会把应用业务逻辑、网络通信或系统权限重新塞回 Interact 或 `main.ts`
如果前两个问题没有准备好,或者第三个问题答案为“会”,就不应提前进入应用市场或新的 App 类型建设。