初始化 agent_ops 文档治理体系

02.架构设计/00.整合说明/01.设计整合说明与优先级.md

@@ -0,0 +1,62 @@
+# 设计整合说明与优先级
+
+**版本：** 2026-08-07  
+**范围：** 原 `lineup-app/设计/` 与原 `agent_ops/设计/`
+
+## 1. 当前采用的整合规则
+
+本目录下的“当前有效设计”统一采用以下优先级：
+
+1. `01.当前有效设计/APP架构设计.md`
+2. `01.当前有效设计/02.正式方案/*.md`
+3. `90.历史设计归档/02.正式方案快照/*.md` 中与当前实现不冲突的补充内容
+4. `90.历史设计归档/01.前期分析与设计/*` 与 `00.阶段记录/*` 的历史背景
+
+一句话概括就是：
+
+**如有冲突，在结合项目当前实际实现的前提下，优先采用已经迁入 `01.当前有效设计/` 的原 `lineup-app/设计/` 文档。**
+
+## 2. 为什么这样定
+
+对比两边设计目录后，可以看到：
+
+- 原 `lineup-app/设计/` 已经形成“权威入口 + 正式方案”的稳定结构；
+- `APP架构设计.md` 明确声明自己是当前权威设计基线，并声明替代关系；
+- 文档内容与当前 `lineup-app` 代码、当前 Host 基线、当前 Runtime 方向更一致；
+- 原 `agent_ops/设计/` 中的大量文档属于更早阶段的探索、协议草案或设计快照。
+
+因此，本轮不再让两处旧目录平行竞争“谁代表当前设计”，而是让已迁入 `01.当前有效设计/` 的文档负责当前设计，让 `90.历史设计归档/` 负责背景、来源和历史演进。
+
+## 3. 当前设计资料的角色划分
+
+### 3.1 当前有效设计
+
+主要回答“现在应该按什么实现”的问题：
+
+- App、Runtime、Host 三者边界；
+- MiniApp、Tool、Surface、Capability 的正式约束；
+- 当前客户端基线；
+- 当前 Tool 和运行时语义。
+
+### 3.2 历史设计来源
+
+主要回答“之前为什么那样想、后来怎么演进到现在”的问题：
+
+- 直连 WebSocket 方案；
+- 早期工具协议三分法；
+- 早期移动端 / Web 方向；
+- 阶段记录和早期架构草图。
+
+## 4. 本轮之后应如何使用两套来源
+
+### 4.1 看当前实现时
+
+优先阅读本目录下的新整合文档，再回溯 `lineup-app/设计/` 的细节来源。
+
+### 4.2 查历史背景时
+
+回看 `90.历史设计归档/` 中的前期分析与阶段记录，但默认它们不再自动对当前实现生效。
+
+## 5. 后续清理方向
+
+本轮已经完成物理迁移；后续不再恢复旧的两处分散设计目录。

02.架构设计/00.整合说明/02.设计冲突与演进顺序.md

@@ -0,0 +1,130 @@
+# 设计冲突与演进顺序
+
+**版本：** 2026-08-07  
+**用途：** 说明两处设计文档的先后关系、冲突点和整合后的取舍依据
+
+## 1. 设计演进的三个阶段
+
+当前已迁入 `02.架构设计/` 的材料，大致对应三个阶段。
+
+### 第一阶段：早期探索阶段
+
+主要来源：
+
+- `90.历史设计归档/00.阶段记录/`
+- `90.历史设计归档/01.前期分析与设计/`
+
+这一阶段的特征是：
+
+- 仍以局域网直连 WebSocket、未来移动端等思路为主；
+- 工具协议与消息协议处于早期草案阶段；
+- 主要目标是确认产品定位和最小可行方向。
+
+这一阶段保留了很多重要背景，但不再直接作为当前实现依据。
+
+### 第二阶段：正式方案快照阶段
+
+主要来源：
+
+- `90.历史设计归档/02.正式方案快照/`
+
+这一阶段已经开始形成 Runtime、App、SDK、Surface、Capability 的正式方案，但它仍然是一次较早的设计快照，并不完全等于今天的代码基线。
+
+### 第三阶段：当前有效设计阶段
+
+主要来源：
+
+- `01.当前有效设计/README.md`
+- `01.当前有效设计/APP架构设计.md`
+- `01.当前有效设计/02.正式方案/`
+
+这一阶段与当前 `lineup-app` 实现最贴近，也明确声明了权威入口和替代关系，因此作为今天的主设计基线。
+
+## 2. 主要冲突点与取舍
+
+### 2.1 连接主线
+
+早期设计强调：
+
+- 局域网 App 直连 Agent 插件 WebSocket
+
+当前有效设计强调：
+
+- `Tauri Desktop Host + Web Reference Host`
+- `AppServer / Runtime / Adapter` 的运行时模型
+
+整合结论：
+
+- 保留早期直连方案作为历史探索背景；
+- 当前实现和后续设计都以 Runtime 中心化的 Host / AppServer / Adapter 主线为准。
+
+### 2.2 客户端形态
+
+早期设计强调：
+
+- Web / 未来移动端
+
+当前有效设计强调：
+
+- Tauri Desktop Host 与 Web Reference Host 的统一代码基线；
+- 不再以独立 Android/Kotlin 客户端作为当前主线。
+
+整合结论：
+
+- 早期移动端方向作为历史背景保留；
+- 当前产品和实现基线以 `lineup-app` 当前 Host 体系为准。
+
+### 2.3 工具模型
+
+早期设计强调：
+
+- `app / toolset / action` 三分法；
+- 工具协议作为较独立的一层来描述。
+
+当前有效设计强调：
+
+- Agent Tool、Inventory、Tool Call、进度、结果、activation、operation；
+- Tool 是 Runtime 模型的一部分，而不是脱离 Runtime 的独立漂浮协议。
+
+整合结论：
+
+- 早期三分法保留为历史理解工具；
+- 当前实现与后续文档统一采用 Runtime 中心化 Tool 模型。
+
+### 2.4 设计重心
+
+早期设计更关注：
+
+- 能否连通；
+- 消息长什么样；
+- 工具如何被粗粒度定义。
+
+当前有效设计更关注：
+
+- Runtime 的唯一所有权；
+- MiniApp、Surface、Capability 的边界；
+- 生命周期、恢复、子会话、工作区和 Agent 调用闭环。
+
+整合结论：
+
+- 现在的设计讨论必须站在第三阶段的视角进行；
+- 第一、二阶段只用于解释“为什么演进到这里”。
+
+## 3. 当前采用的统一排序
+
+当同一主题在多份文档中出现冲突时，当前采用的优先顺序是：
+
+1. `01.当前有效设计/APP架构设计.md`
+2. `01.当前有效设计/02.正式方案/*.md`
+3. `02.整合结论/` 中已经写明的整合判断
+4. `90.历史设计归档/02.正式方案快照/`
+5. `90.历史设计归档/01.前期分析与设计/`
+6. `90.历史设计归档/00.阶段记录/`
+
+## 4. 这份文档的作用
+
+这份文档不是简单说明“哪个文件更新”，而是明确：
+
+- 哪些冲突是设计演进带来的；
+- 现在为什么优先采用当前有效设计；
+- 早期文档应该怎样被使用，而不是继续和当前设计平级竞争。