diff --git a/迭代/README.md b/迭代/README.md
index 2fe0b96..5f25e77 100644
--- a/迭代/README.md
+++ b/迭代/README.md
@@ -5,6 +5,7 @@
 
 ```text
 迭代/
+├── plan.md                         # 当前阶段之后的总体路线和排期原则
 ├── 00.base/
 │   └── 00.base.md
 ├── 01.kernel/
@@ -27,6 +28,11 @@
 5. 已确认的结论需要回填主定义文档和验收项；评审记录保留原始意见，用于追溯，不能替代主定义文档；
 6. 迭代完成后的实现验收、发布复盘等文档也保留在对应目录内，并使用清晰的递增编号。
 
+## 后续总计划
+
+当前阶段之后的路线、迭代拆分、范围边界和完成标准见 [plan.md](plan.md)。该文件记录已确认的整体方向；
+每个具体迭代开始后，仍需在自己的目录中创建主定义文档和独立评审记录。
+
 ## 评审优先级与遗留问题
 
 评审问题使用 `P0`～`P5` 标示处理优先级。优先级表达的是“最晚何时必须解决”，而不是问题描述的
diff --git a/迭代/plan.md b/迭代/plan.md
new file mode 100644
index 0000000..fc2e169
--- /dev/null
+++ b/迭代/plan.md
@@ -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 代表性流程通过端到端验收；
+所有 P0～P3 评审问题清零。
+```
+
+## 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 类型建设。