276 lines
9.7 KiB
Markdown
276 lines
9.7 KiB
Markdown
# 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 请求启动 Pomodoro 番茄时钟
|
||
→ Runtime 创建 App instance 和 App 子会话
|
||
→ 番茄时钟进入前台，Interact 进入后台
|
||
→ 计时在后台继续运行
|
||
→ 用户可以暂停、继续、取消或回到 Interact
|
||
→ 到时间后显示完成提醒并回传结果
|
||
→ 用户关闭 App，Runtime 收口未完成操作
|
||
→ 子会话结束并在 IM 中折叠保存
|
||
→ Interact 恢复
|
||
→ 用户查看历史或继续开始下一轮
|
||
```
|
||
|
||
### 3.2 主要工作
|
||
|
||
1. **接通 App 工作区界面**
|
||
- 显示当前前台 App；
|
||
- 支持 Interact、Pomodoro 番茄时钟、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. **让 Pomodoro 成为第一条完整用户流程**
|
||
- Agent 请求启动一个番茄钟；
|
||
- Runtime 创建计时实例和 App 子会话；
|
||
- 用户可以查看剩余时间、暂停、继续和取消；
|
||
- 番茄钟切到后台后仍能继续计时；
|
||
- 到时间后显示完成提醒并回传结果；
|
||
- 用户关闭番茄钟时，Runtime 正确取消未完成操作；
|
||
- 刷新或重启后根据 `ends_at` 恢复剩余时间；
|
||
- 完成记录和子会话可以在 Interact 中查看。
|
||
|
||
第一版只保留这些状态和数据：
|
||
|
||
```text
|
||
state = idle | running | paused | completed | cancelled
|
||
timer_id
|
||
duration_seconds
|
||
started_at
|
||
ends_at
|
||
remaining_seconds
|
||
```
|
||
|
||
建议的最小 Tool：
|
||
|
||
```text
|
||
pomodoro.start
|
||
pomodoro.pause
|
||
pomodoro.resume
|
||
pomodoro.cancel
|
||
pomodoro.status
|
||
```
|
||
|
||
番茄钟到时间后的普通完成提醒属于 MiniApp 自己的业务提示；如果以后需要系统通知，再通过
|
||
Runtime 的 Capability 请求，不能让 MiniApp 直接调用 Tauri 或操作系统接口。Agent 询问用户是否
|
||
开始下一轮时，仍然必须使用 Interact 的标准交互。
|
||
|
||
6. **补充端到端验收**
|
||
- Web Reference Host 完整验收；
|
||
- Tauri Desktop Host 至少完成一条代表性流程；
|
||
- 验证刷新、断线、重启、关闭、恢复和重复提交；
|
||
- 检查 Runtime 生命周期、交互、Tool 和恢复日志。
|
||
|
||
### 3.3 不在本迭代范围
|
||
|
||
- 应用市场和服务端 App Catalog；
|
||
- 远程下载、第三方发布和在线更新；
|
||
- 多 Agent 连接、切换和多 Agent 会话列表；
|
||
- Audio Mode 的真实媒体能力；
|
||
- Video Mode 的真实媒体能力；
|
||
- Whiteboard 的多人协作和复杂绘图能力；
|
||
- Task Dashboard 的完整项目管理功能；
|
||
- Pomodoro 的统计报表、多个计时器、日历和复杂提醒计划。
|
||
|
||
### 3.4 完成标准
|
||
|
||
```text
|
||
用户可以从 Interact 启动 Pomodoro 番茄时钟；
|
||
Runtime 可以正确创建、切换、后台化、关闭和恢复 App；
|
||
App 子会话能在 IM 中折叠、展开和继续处理；
|
||
标准交互在不同前台 App 下仍归 Interact；
|
||
关闭 App 时 Tool 和 outbox 收口正确；
|
||
刷新/重启后 App、焦点、子会话、计时剩余时间和待处理交互按规则恢复；
|
||
Web/Tauri 代表性流程通过端到端验收；
|
||
所有 P0～P3 评审问题清零。
|
||
```
|
||
|
||
## 4. 第五次迭代：第二个真正可用的隔离 MiniApp
|
||
|
||
建议迭代目录：
|
||
|
||
```text
|
||
迭代/05.first_isolated_miniapp/
|
||
```
|
||
|
||
第四次迭代完成工作区和 Pomodoro 后，再把另一个 MiniApp 从“参考实现”推进为“真实隔离运行的应用”。
|
||
|
||
### 4.1 推荐顺序
|
||
|
||
优先选择 Whiteboard 作为第二条安全和 Surface 验证流程；Task Dashboard 留到后续，避免任务管理业务影响 Runtime 核心设计。
|
||
|
||
### 4.2 Whiteboard 方向
|
||
|
||
- 受限 Surface 中的画布状态；
|
||
- 状态 patch；
|
||
- Artifact 导出；
|
||
- Artifact 元数据校验；
|
||
- 重启恢复；
|
||
- 验证不能访问 Host DOM、Tauri、认证状态、任意网络和其他 MiniApp 数据。
|
||
|
||
暂时不做多人协作、云端同步和复杂绘图工具。
|
||
|
||
### 4.3 Task Dashboard 的后续定位
|
||
|
||
Task Dashboard 仍然保留为后续普通 `bundled` MiniApp，但不作为 Runtime 的第一条验证流程。
|
||
等工作区、SDK、生命周期和 Surface 边界稳定后，再单独定义任务、项目、状态和历史等业务模型。
|
||
|
||
## 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 类型建设。
|