app/迭代/03.sdk_and_coreapp/04.acceptance_review.md

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

评审编号：04 评审日期：2026-08-05 评审对象：03.sdk_and_coreapp.md 架构基线：APP架构设计.md 参考评审：01.design_review.md、02.design_review.md、03.design_review.md 评审方式：主 agent 交叉检查 + 独立子 agent 只读验收；检查构建、自动化测试、Runtime/MiniApp/Host 代码、SDK 契约、Manifest 和真实浏览器路径。 总体结论：功能回归通过，但架构与 SDK 验收不通过。发现的 P1 问题必须在本迭代修复后，才能把迭代标记为真正完成。

问题清单（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	已移除 Host 直接实例化；Task Dashboard/Whiteboard 业务逻辑改在 opaque sandbox 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:180-198、isolated-surface-host.ts	至少提供能代表业务边界的受限 Surface fixture，并验证 MiniApp 业务逻辑不能取得 Host DOM 或 Runtime 内部。
✅	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 个测试文件、131 个测试（含 Tool 契约、默认有效期、重启过期和答案 schema 回归）。
• git diff --check 通过。
• MiniApp progress 回归通过：状态机保存最新进度，Runtime 重启后恢复 percent/status/detail。
• 使用独立 agent-browser 会话登录本地测试账号成功。
• 主 IM 页面、同步状态、应用子会话区域和“启用任务面板”入口可见。
• 用户消息可以发送并显示“已发送”。
• AppServer 频道中的其他用户消息已能被 Runtime 安全忽略；真实页面不再出现此前大量的 scope_mismatch。

这些证据只能说明基础功能路径可运行，不能证明 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 也不是 system，必须使用受限 Surface/Bridge”不一致。若继续保留这种实现，必须把 它们改成明确的 Host 内建 System 代码并修改信任模型；不能继续同时声称它们是普通 bundled MiniApp。

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 看到的最终结果不一致，属于当前迭代必须修复的正确性问题。

3. 验收结论

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

功能回归：通过
基础构建与自动化测试：通过
真实登录和消息发送：通过
App 架构边界：部分通过（A1/A2/A5/A6 已实现，A2 待浏览器复验）
MiniApp 隔离与 SDK 规范：A1～A11 已通过。
标准交互终态契约：通过
迭代整体验收：不通过，剩余 A8 真实浏览器验收；A2 也需在最终浏览器复验中确认

本轮独立验收由子 agent 完成。A6 已在本轮修复并通过自动化验证，A7 已完成契约收敛并通过全量测试，A9 已完成进度持久化并通过重启回归，A10 已补齐生命周期事件上下文，A11 已删除旧 SDK 旁路；下一轮只需完成 A8 的真实浏览器验收并重新执行独立验收。 独立验收。P2/P3 不能被静默删除，必须在本迭代结束前解决或保留明确的延期记录。