# `03.sdk_and_coreapp` 第 4 次验收评审记录

> 评审编号：04
> 评审日期：2026-08-05
> 评审对象：[03.sdk_and_coreapp.md](03.sdk_and_coreapp.md)
> 架构基线：[APP架构设计.md](../../设计/APP架构设计.md)
> 参考评审：[01.design_review.md](01.design_review.md)、[02.design_review.md](02.design_review.md)、[03.design_review.md](03.design_review.md)
> 评审方式：主 agent 交叉检查 + 独立子 agent 只读验收；检查构建、自动化测试、Runtime/MiniApp/Host 代码、SDK 契约、Manifest 和真实浏览器路径。
> 总体结论：本轮 P0～P3 问题已完成修复，并通过代码、自动化测试和真实浏览器闭环检查；独立验收 agent 已确认本迭代可以标记为“已完成”。

## 问题清单（Outline）

> **状态标记：** 🔴 未解决，必须处理；🟡 已提出修复方向，尚未实现；✅ 已解决；⚪ 可延期但必须保留记录。
>
> P0～P3 必须在当前迭代处理；P4～P5 可以延期，但要写清延期原因和重新评估条件。

| 状态 | 优先级 | 编号 | 问题 | 证据 | 当前结论 / 下一步 |
|---|---:|---|---|---|---|
| ✅ | P1 | A1 | MiniApp 的 Capability 请求绕过 Runtime 的 Manifest、Policy 和审计边界 | `tauri/src/runtime/coordination/lineup-runtime.ts`、`capability-audit.ts` | 已统一经过 Manifest 声明、Capability Registry/Policy、输入 schema、前台要求和审计记录，再进入普通 Agent 确认请求；拒绝原因也由 Runtime 返回。 |
| ✅ | P1 | A2 | `bundled` MiniApp 的业务逻辑仍在可信 Host JS 中运行，没有真正的受限执行边界 | `tauri/src/main.ts`、`isolated-surface-host.ts`、agent-browser | 已移除 Host 直接实例化；Task Dashboard/Whiteboard 业务逻辑运行在 opaque `sandbox="allow-scripts"` iframe 内，只能通过 Runtime Bridge 请求能力；真实浏览器已复验。 |
| ✅ | P1 | A3 | SDK 暴露完整 workspace，MiniApp 可看到其他 App 实例和全局焦点栈 | `lineup-runtime.ts`、`miniapp-sdk.ts` | 已从 `LineUpMiniAppSDK` 删除 `workspace()`，不再把全局实例和焦点栈交给 bundled MiniApp。 |
| ✅ | P1 | A4 | 同一个 App 的多个 instance 之间 Inbox 订阅没有隔离 | `lineup-runtime.ts` | 已按 `app_scope + conversation_id + instance_id` 过滤实时订阅，并补充双实例回归测试。 |
| ✅ | P1 | A5 | Interact 使用专用 `ChatRuntimeSDK` 旁路，没有和其他 MiniApp 共用 SDK v1 语义 | `tauri/src/runtime/app-management/app-sdk.ts`、`lineup-runtime.ts`、`main.ts` | 已明确为“通用 Runtime 操作 + 可信 UI 投影”：Interact 保留可信 DOM 和 IM 展示，但行为统一走 `sdk.runtime.*`，展示走 `sdk.ui.*`；旧扁平方法仅作兼容别名。 |
| ✅ | P1 | A6 | 标准交互的超时、dismiss、提交和答案 schema 没有由 Runtime 统一裁决 | `lineup-runtime.ts`、`agent-interaction-service.ts`、`standard-interaction-contract.ts` | 已让本地提交、取消、过期和 Agent dismiss 同步推进 Interaction 与 Kernel；notice 也会完成 Kernel；四种答案在 Runtime 按固定 schema 校验，默认有效期和重启过期均只写一条 outbox。 |
| ✅ | P2 | A7 | 迭代文档中的 Tool 名称和代码 Manifest 不一致 | 主文档 §5.2/§5.3；`reference-miniapps.ts` | 已统一为 `task-dashboard.open`、`task-dashboard.update`、`whiteboard.open`、`whiteboard.submit`；Manifest schema、MiniApp 实现、sandbox iframe、fixture 和测试均已同步。 |
| ✅ | P2 | A8 | 当前 Task Dashboard/Whiteboard Surface 主要是 Host 硬编码的静态页面，无法证明真实业务 UI 在各自受限 Surface 内运行 | `main.ts`、`isolated-surface-host.ts`、agent-browser Console/IM 结果 | 已修复 Bridge 方法校验不接受 SDK 的 camelCase `tools.reportProgress` 的问题。真实浏览器中分别注入并完成 `task-dashboard.open` 与 `whiteboard.open`：两者均经过 `tools.list → tools.reportProgress → surface.patch（如适用）→ tools.complete`，IM 中收到 completed 结果；两个 iframe 都是 `sandbox="allow-scripts"`、opaque origin，错误 iframe source 发送伪造 complete 不会产生 evil 结果。 |
| ✅ | P2 | A9 | MiniApp progress 没有进入可恢复的 Tool 状态记录 | `miniapp-tool-state.ts`、`lineup-runtime.test.ts` | 已在 Tool 记录保存最后一次 `percent/status/detail`，ConversationStore 随记录持久化；Runtime 重启后可恢复，且补充状态机和重启回归测试。 |
| ✅ | P3 | A10 | App session 记录和 opened/closed 事件没有显式保存 `agent_id` / `conversation_id` 字段 | `lineup-runtime.ts`、`lineup-runtime.test.ts` | opened/closed 事件现在都带 `agent_id`、`conversation_id`、`app_session_id`、`instance_id`、`app_scope`；并补充生命周期回归测试。 |
| ✅ | P3 | A11 | 旧的 `openExtensionApp` 公开入口仍提供较宽的旁路能力 | `lineup-runtime.ts`、`app-sdk.ts` | 已删除 `openExtensionApp()` 和 `ExtensionRuntimeSDK`；bundled MiniApp 只能通过统一的 `openBundledMiniApp()` SDK 和 Runtime Bridge 访问能力。旧测试已改为验证统一生命周期路径。 |

## 1. 已验证通过的部分

- `npm run build` 通过。
- `npm test -- --run` 通过：29 个测试文件、135 个测试（含 Bridge camelCase 方法、Tool 契约、默认有效期、重启过期和答案 schema 回归）。
- `git diff --check` 通过。
- MiniApp progress 回归通过：状态机保存最新进度，Runtime 重启后恢复 `percent/status/detail`。
- 使用独立 `agent-browser` 会话登录本地测试账号成功；AppServer `/login`、`/messages/send`、`/messages/sync` 均可用。
- 主 IM 页面、同步状态、应用子会话区域和“启用任务面板”入口可见。
- 用户消息可以发送并显示“已发送”。
- AppServer 频道中的其他用户消息已能被 Runtime 安全忽略；真实页面不再出现此前大量的 `scope_mismatch`。

这些证据与后续真实 Tool 闭环日志共同证明 MiniApp 隔离、统一 SDK 和状态机契约满足本轮架构要求。

## 2. P1 问题说明

### A1：Capability 请求没有经过 Runtime 的完整裁决（已修复）

现在 `sdk.capabilities.request(name, reason, input)` 只会进入 Runtime 的统一入口。Runtime 依次检查当前实例
对应的 bundled Manifest 是否声明该能力、Capability Registry/Policy 是否可用、输入是否符合 schema，以及
能力要求的前台状态；拒绝会返回明确原因，并写入不含敏感参数的审计记录。

通过检查后，Runtime 生成唯一 `call_id`，记录 pending 审计项，再进入普通 `lineup.v1.app.call` Agent 确认流程。
MiniApp 不会拿到 Host handler、Transport 或权限对象。

### A2：bundled MiniApp 实际仍是可信代码（已修复）

已删除 `main.ts` 中对 `TaskDashboardMiniApp` 和 `WhiteboardMiniApp` 的直接实例化。开发版 Surface 现在把
Task Dashboard/Whiteboard 的业务脚本放进 opaque sandbox iframe，iframe 只能发送经过校验的
`lineup.miniapp.v1.request`，由 Runtime 执行 Inbox、Tool、生命周期和 Surface 操作；Host 不再把 Runtime 对象、
Store 或 Transport 注入 MiniApp。

这与架构文档要求一致：`bundled` MiniApp 也必须使用受限 Surface/Bridge，不能因为随 Host 内置就取得
System MiniApp 的可信 DOM 或其他特权。Task Dashboard 和 Whiteboard 已按这一边界运行，真实浏览器验收也确认
它们的 Bridge 请求会经过 Runtime 的 instance/source 校验。

### A3/A4：SDK 数据边界没有做到 instance 级别（已修复）

`LineUpMiniAppSDK` 已不再提供 `workspace()`，因此 MiniApp 不能查看其他 instance 或 Runtime 焦点栈。

`inbox.list()`、ACK 和 `inbox.subscribe()` 现在都按 `app_scope + conversation_id + instance_id` 过滤；新增回归
测试验证同一 App 的两个 instance 不会互收消息。

### A5：Interact 的 SDK 语义没有统一（已修复）

Interact 仍然可以使用可信 DOM，但它的 SDK 已明确拆成两层：`sdk.runtime.*` 提供 Runtime 行为入口，
`sdk.ui.*` 提供 IM 和子会话的可信展示投影。标准交互、消息发送、草稿、任务操作仍由 Runtime 完成；UI
投影没有 Transport、Store、Agent 原始 Envelope 或 Host 特权。旧的扁平 `ChatRuntimeSDK` 方法只保留为
兼容别名，避免把 Interact 的 UI 适配误解成另一套协议。

### A6：标准交互有两套状态，可能互相打架（已修复）

已统一处理以下路径：

- 本地提交、取消、过期和 Agent dismiss 都同时更新 Interaction 与 Kernel Tool；任一侧不能迁移时会恢复另一侧的旧快照。
- notice 在呈现完成时也会同步完成 Kernel Tool，避免重启后出现 Interaction 已完成而 Tool 仍 pending。
- `choice` 只接受 `{ action_id }`，且 action 必须来自请求；`confirm` 只接受 `{ approved: boolean }`；`input` 只接受 `{ text: string }`，并校验必填和长度。
- 终态只创建一次对应的 Tool result/cancel outbox；重复提交、重复 dismiss 和已过期提交不会再次写出站消息。

现在 UI、持久化记录和 Agent 看到的最终结果由 Runtime 统一推进，重复终态不会再次写出站消息。

## 3. 验收结论

当前结论为（完成本轮 P1-1～P1-4，并收敛 A7 后）：

```text
功能回归：通过
基础构建与自动化测试：通过
真实登录和消息发送：通过
App 架构边界：通过（A1/A2/A5/A6 已实现，A2 已完成真实 iframe 复验）
MiniApp 隔离与 SDK 规范：A1～A11 已通过。
标准交互终态契约：通过
迭代整体验收：通过代码、自动化测试、真实浏览器闭环和独立验收；主迭代文档已标记为“已完成”。
```

本轮独立验收由子 agent `acceptance_round_08` 完成：29 个测试文件、135 个测试通过，构建和 `git diff --check` 通过；A8 的共享 agent-browser 日志确认 Task Dashboard 与 Whiteboard 均完成 `tools.list → tools.reportProgress → surface.patch（适用时）→ tools.complete`，错误 source/instance 请求未产生伪造结果。A1～A11 全部关闭，没有 P0～P3 遗留问题。