文档：同步 platform-llm 工具调用契约

修正纯工具响应在尾部错误后的保留条件

补充非流式畸形 arguments 交由调用方 repair 的契约

同步两份 Runtime 文档与决策日志的 81 项测试口径

保留历史 52 项验证记录的时间语义

docs/project-memory/shared-memory/decision-log.md

@@ -5351,11 +5351,11 @@
 - 流式：三种协议的工具增量统一按槽位聚合成完整调用——Chat 用 `delta.tool_calls[].index`、Responses 用 `output_index`（`output_item.added` 给身份、`function_call_arguments.delta` 拼参数、`.done` 覆盖为权威值，并从 `response.completed` 的 `output[]` 再兜底一次）、Anthropic 用 content block `index`（`content_block_start` 给身份，`input_json_delta` 拼参数，`content_block_start` 里的空 `input` 不得用于初始化）。收尾必须校验参数为完整 JSON，截断流不返回半截参数。`LlmStreamDelta` 仍只承载文本，工具调用不进增量回调。上游已表明本轮是工具调用却一个都没聚合出来时返回 `StreamUnavailable`，让调用方回退非流式，不允许静默丢弃。
 - 兼容边界：旧 wrapper 与 text JSON parser 只保留为历史响应、确定性 fixture 和模型不守协议时的降级解析，**不再是任何 Provider 的正常请求路径**；`agent.runtime.tool_plan.protocol` 审计在 Anthropic 正常路径下取值为 `native_runtime_tools`。Chat 的 `ChatCompletionsToolCall` 字段放宽为可选并新增 `index`，否则流式后续分片（只带 `index` 与 `arguments`）会直接反序列化失败。
 - 影响范围：`server-rs/crates/platform-llm`、`apps/ai-game-creator-shell/src-tauri/src/agent/interaction.rs`、同目录 `runtime_actions/provider_request_builders.rs`，以及 Runtime V1.1 与 App 实施计划两份技术方案。取代 2026-07-16「使用 Provider 原生工具目录」中把 Anthropic 与历史 fixture 并列的兼容描述、2026-07-12 关于 Anthropic 文本 JSON 回退的补充，以及 2026-07-24「统一 Interaction Loop」中「非原生 tool Provider 使用同构严格 JSON envelope 适配」的表述。
-- 验证方式：`cargo test -p platform-llm` 52 项通过，其中 8 个流式工具用例的 SSE 原文取自真实抓包；`server-rs/crates/platform-llm/tests/live_stream_tool_calls.rs` 为默认 `#[ignore]` 的真实端点验收，靠 `PLATFORM_LLM_LIVE_*` 环境变量运行，已对 MiniMax(anthropic / openai_chat / openai_responses) 与 OpenAI(gpt-4.1 openai_chat / gpt-5.5 openai_responses) 五种配置确认流式解析出完整工具调用。App 侧回归用 stash 对比法确认无新增失败——本机该测试套件存在大量与改动无关的既有失败，不能直接看绝对失败数。
+- 验证方式（当时记录）：`cargo test -p platform-llm` 52 项通过，其中 8 个流式工具用例的 SSE 原文取自真实抓包；`server-rs/crates/platform-llm/tests/live_stream_tool_calls.rs` 为默认 `#[ignore]` 的真实端点验收，靠 `PLATFORM_LLM_LIVE_*` 环境变量运行，已对 MiniMax(anthropic / openai_chat / openai_responses) 与 OpenAI(gpt-4.1 openai_chat / gpt-5.5 openai_responses) 五种配置确认流式解析出完整工具调用。App 侧回归用 stash 对比法确认无新增失败——本机该测试套件存在大量与改动无关的既有失败，不能直接看绝对失败数。
 - 关联文档：`docs/technical/【技术方案】AI游戏创作Agent Runtime V1.1-2026-07-12.md`、`docs/technical/【技术方案】AI游戏创作智能体App实施计划-2026-06-24.md`。
 
 ## 2026-07-27 校正 platform-llm 流式工具验收证据边界
 
-- 更正：上一条把固定 SSE fixture 的真实抓包来源、确定性 parser 覆盖和真实端点 smoke 合并描述，并写成“证明转录没有偏差”，超出了实际测试证据。`cargo test -p platform-llm` 当前为 `52 passed / 0 failed`；其中固定 fixture 只验证 parser 归一结果，实时测试只验证最终归一后的工具名、id、完整参数 JSON 和文本增量字符数。
+- 更正：上一条把固定 SSE fixture 的真实抓包来源、确定性 parser 覆盖和真实端点 smoke 合并描述，并写成“证明转录没有偏差”，超出了实际测试证据。从仓库根目录运行 `cargo test --manifest-path server-rs/Cargo.toml -p platform-llm` 当前为 `81 passed / 0 failed / 1 ignored`；其中固定 fixture 只验证 parser 归一结果，实时测试只验证最终归一后的工具名、id、完整参数 JSON 和文本增量字符数。
 - 当前口径：`server-rs/crates/platform-llm/tests/live_stream_tool_calls.rs` 是默认忽略的真实端点工具调用 smoke；`on_delta` 只接收文本，工具调用从最终 `LlmRunResponse.tool_calls` 读取。现有测试没有原始 SSE 录制、事件类型/slot/分片顺序保存或逐事件比较，因此两类测试都不能证明 raw SSE fidelity 或抓包转录无偏差。
 - 现有确定性流式工具覆盖应与普通 Anthropic 文本流测试分开统计：三协议真实来源 fixture、Responses completed-only 恢复、并行 slot 聚合、截断参数和无片段 `StreamUnavailable` 等用例共同覆盖 parser 边界；未来若需证明转录一致性，必须另行增加受控原始 SSE capture/compare 能力。

docs/technical/【技术方案】AI游戏创作Agent Runtime V1.1-2026-07-12.md

@@ -1493,7 +1493,7 @@ V1.43 不放宽 V1.41 的文本型 `game-creator-provider-handoff.v1`，而是
 - 恢复验收必须在同一轮证明：同一 requestId 只闭合一次且不产生替代 requestId，proxy 的 `networkReplayCount=0`，protocol/repair audit compare-and-append 幂等，handoff 与恢复后 durable pending/action batch 的 plan fingerprint 对应；ACK、强杀和恢复消费前不得出现由目标计划产生的 action、pending、delivery、claim 或其它副作用。终局 retry/tool-plan handoff/provider handoff/finalization/confirmation 等 sidecar、重复 lifecycle/audit/action/message、临时 capability/Runner 资源与 AppData 残留均为 `0`，公共报告中的 Provider URL、headers、正文、凭据及项目/正式配置绝对路径泄漏命中也必须为 `0`。2026-07-20 的真实外部 Provider 单轮已证明 checkpoint、Runner boot 切换、同一请求零网络重放、恢复前零副作用与唯一生命周期闭合，但随后专业 Agent 连续连接失败使整轮 FAIL；另一独立轮首批工具数不满足 fixture，同样未通过。两轮不得拼接，当前仍无该 suite 的完整外部 PASS。
 - V1.43 仍不关闭“外部 Provider 已成功返回、但本地 handoff 尚未完成原子写入并回读”的 unknown-result 窗口；没有 Provider 级幂等键或结果查询能力时，该窗口继续进入人工 reconciliation，不能宣称端到端物理调用 exactly-once。手动 context-compaction 也不在本切片。
 - 2026-07-20 当前确定性证据：本轮 `tool_plan_handoff_` 为 `44/44`，Supervisor collaboration 相关过滤为 `55/55`，权威返工合同用例为 `1/1`；Tauri/Rust 串行全量 1058 tests 为 `1054 passed / 4 ignored / 0 failed`，Linux `cargo check --tests` 与 `x86_64-pc-windows-gnu cargo check --tests` 均通过。E2E self-test、typecheck、变更脚本 ESLint、encoding 与 `git diff --check` 通过。默认并发全量只作竞态诊断，不替代 `--test-threads=1`。Unix handoff 存储使用固定目录句柄、根/Agent 双层 `flock`、`RENAME_EXCHANGE` 安装回滚和 `RENAME_NOREPLACE` quarantine；Windows 使用相对父句柄、`GetFileInformationByHandleEx` 句柄枚举与独占 temp 句柄，并拒绝 junction/reparse point 与硬链接。非协作同 UID 进程仍属于宿主 OS 信任边界，不能据此宣称完整沙箱。真实 suite 的 checkpoint 已有单轮外部证据，但整轮仍无 PASS。
-- 2026-07-27 文档更正：本节及 V1.42 中的 `platform-llm 41/41` 是 2026-07-20 的历史门禁计数，不能代表本次工具协议修复后的当前结果；当前 `cargo test -p platform-llm` 为 `52 passed / 0 failed`。当前证据应区分为 checked-in SSE fixture 的 parser 覆盖和默认忽略的真实端点归一工具调用 smoke；两者都不录制或逐事件比较原始 SSE，不能据此宣称转录无偏差。
+- 2026-07-27 文档更正：本节及 V1.42 中的 `platform-llm 41/41` 是 2026-07-20 的历史门禁计数，不能代表本次工具协议修复后的当前结果；从仓库根目录运行 `cargo test --manifest-path server-rs/Cargo.toml -p platform-llm` 当前为 `81 passed / 0 failed / 1 ignored`（确定性测试 81 项，真实端点归一工具调用 smoke 默认 ignored）。当前证据应区分为 checked-in SSE fixture 的 parser 覆盖和默认忽略的真实端点归一工具调用 smoke；两者都不录制或逐事件比较原始 SSE，不能据此宣称转录无偏差。
 
 ## 验收命令
 

docs/technical/【技术方案】AI游戏创作智能体App实施计划-2026-06-24.md

@@ -702,7 +702,7 @@ game-project/
 - tool-plan arguments 只允许出现在 `0600` 原子 sidecar 及后续 pending/action batch，不得进入 task/event/Agent DB/CLI/report。公共 protocol/repair 审计共同保存 Agent/task/Session/run/source、loop/repair/slot、响应指纹、Provider request ID SHA-256 和 protocol；protocol 只保存 function call 数量、call ID SHA-256 数组、catalog-bound function names、response ID SHA-256/字符数及 normalization 元数据，repair 只保存 attempt/maxAttempts、协议错误/preview 哈希和 call ID/function name SHA-256，不保存原始 callId/callIds/responseId/providerRequestId，并在 Agent DB append 锁内按完整身份全历史幂等追加。为了保持执行语义，参数禁止静默脱敏；命中密钥、配置痕迹、敏感 JSON key、Provider ID 中的秘密/绝对路径、结构化可执行路径中的项目或其它绝对路径、大小/顺序/身份冲突时直接 reconciliation。源码正文和计划叙述只做密钥检查，不能把 HTML 闭合标签当绝对路径；未闭合 thinking 只留无正文无效元数据并继续 repair。账本保留到 run 终态或明确作废；steer/cancel/漂移/终态清理前先闭合整本账本的实际 requestId，Runner 恢复严格扫描 hash/primary/`.previous`/安全临时文件并回收合法终态残留，确保单动作、多动作、confirmation、协作 batch 与直接回复在下一 durable owner 建立前都有恢复来源；未知、冲突、primary、`.previous` 或损坏账本都阻止 Runner idle shutdown。
 - V1.43 的确定性门禁必须覆盖 base handoff 与 repair handoff 两个 lifecycle-completed 前断点，关闭 mock Provider 后恢复零网络、原 requestId 唯一闭合、repair/protocol audit 幂等、唯一 assistant/completed/committed stream及终局零 sidecar。独立非默认真实门禁 `supervisor-swarm-tool-plan-handoff-runner-kill` 已实现并完成 Shell/Root 两级注册：它使用 sentinel-owned sibling AppData 与 metadata-only zero-fault proxy，以每轮随机 capability 严格绑定 project/Agent/run/实际 request slot；只有 tool-plan handoff 原子落盘并回读一致、同一实际 requestId lifecycle 尚未 `completed` 时才 ACK，随后通过 pidfd `SIGKILL` 强杀 suite 自有 Runner。恢复必须证明同一 requestId 唯一闭合且 `networkReplayCount=0`、protocol/repair audit 幂等、handoff 与 durable batch plan fingerprint 对应、恢复消费前 action/pending/delivery/claim 等副作用为 `0`，并在终局把 sidecar、重复记录、临时 capability/Runner/AppData 资源及公共正文、凭据、URL、项目/正式配置路径泄漏全部清零。2026-07-20 的真实外部 Provider 单轮已到达并通过 checkpoint，但随后专业 Agent 连续连接失败使整轮 FAIL；另一独立轮首批工具数不满足 fixture，也未通过。两轮不得拼接，当前仍无该 suite 的完整外部 PASS。Provider 成功到 handoff 原子落盘回读前的 unknown-result 和手动 context-compaction 仍不在本切片承诺内。
 - V1.43 当前确定性实现已通过本轮 `tool_plan_handoff_ 44/44`、Supervisor collaboration 相关过滤 `55/55`、权威返工合同 `1/1`，以及 Tauri/Rust 串行全量 `1054 passed / 4 ignored / 0 failed`；Linux `cargo check --tests` 与 `x86_64-pc-windows-gnu cargo check --tests` 均通过。E2E self-test、typecheck、变更脚本 ESLint、encoding 与 `git diff --check` 通过；默认并发全量只作竞态诊断，不替代串行门禁。Supervisor 真实 E2E 报告已把 `toolPlanHandoffSidecarCount` 纳入终局残留。handoff 跨平台存储使用 Unix 固定目录句柄、目录 `flock`、exchange/quarantine 与 Windows 相对父句柄、句柄枚举、独占 temp，不再根据 PID 推断写入方是否存活；主动忽略锁的同 UID 进程仍属于宿主 OS 信任边界。
-- 2026-07-27 文档更正：上文 V1.42 的 `platform-llm 41/41` 保留为 2026-07-20 历史门禁计数；当前 `cargo test -p platform-llm` 为 `52 passed / 0 failed`。platform-llm 的验收证据分为 checked-in SSE fixture parser 覆盖与默认 `#[ignore]` 的真实端点归一工具调用 smoke；后者只校验最终工具名、id、完整参数 JSON 和文本字符数，未录制或逐事件比较原始 SSE，二者都不能证明转录无偏差。
+- 2026-07-27 文档更正：上文 V1.42 的 `platform-llm 41/41` 保留为 2026-07-20 历史门禁计数；当前从仓库根目录运行 `cargo test --manifest-path server-rs/Cargo.toml -p platform-llm` 为 `81 passed / 0 failed / 1 ignored`（确定性测试 81 项，真实端点归一工具调用 smoke 默认 ignored）。platform-llm 的验收证据分为 checked-in SSE fixture parser 覆盖与默认 `#[ignore]` 的真实端点归一工具调用 smoke；后者只校验最终工具名、id、完整参数 JSON 和文本字符数，未录制或逐事件比较原始 SSE，二者都不能证明转录无偏差。
 - 2026-07-21 起，同一 Runtime 文档的“V1.44 自主可玩塔防确定性真实门禁”增加独立 loopback OpenAI Chat Provider 和 wrapper 命令。Provider 只返回原生 function calls，不直接修改项目、不伪造工具 observation；wrapper 在仓库外创建带 sentinel 的临时配置，复用正式 `supervisor-autonomous-playable-lane-defense` suite，并在终局停止 Provider、删除配置和 disposable 项目。
 - V1.44 固定验证两份首轮并行专业委派、只读验收回复因 revision 更新而重新规划、程序 Agent 写入并通过静态自检、首轮真实浏览器因隐藏 canvas 失败、Supervisor 直接修改被 orchestrator-only 策略拒绝，以及后续程序委派产生新 revision。若旧失败仍在父验证门且后续 delivery 已 ready，必须先用 `agent.run_status` 认领回执，再对当前 revision 完成 `game.static_smoke + preview.validate`，最后只由 Supervisor 回复；已有 3 个 active/ready delivery 时不得创建第四次委派。试玩 liveness 只以当前 revision 可归属的最新 `preview.validate` 结果收束：新 revision 的成功会取代历史失败，当前 revision 最新失败仍继续强制专业返工；每个固定 `data-playtest-id` 必须唯一匹配一个可见、启用且真实可点击的 HTMLElement。
 - 本轮 V1.44 wrapper 与正式子 suite 均为 **PASS**：Provider 共 `17` 次 planning、异常请求 `0`；项目从 revision `0` 推进到 `2`，最终 `game/index.html` 为 `4924` 字节；`lane-defense-v1` 的植物选择、放置、敌人移动与受伤、胜利、下一关和重开共 `37/37` 断言通过，桌面与移动浏览器验证通过；三份专业回执全部认领，Supervisor assistant 唯一，pending、confirmation、user-input、provider batch/retry/handoff、tool-plan handoff、finalization journal、reconciliation、重复和泄漏计数均为 `0`，隔离 Runner、AppData、配置和项目已清理。该确定性 loopback PASS 不能替代外部 Provider 可用性验收；外部路由仍须单独形成同轮完整 PASS。

server-rs/crates/platform-llm/README.md

@@ -39,14 +39,14 @@ Responses 如果只发送 `response.completed`，解析器会从其中的 `respo
 1. `LlmStreamDelta` 只包含 `accumulated_text`、`delta_text` 和 `finish_reason`，工具调用不会进入 `on_delta`；纯工具响应允许 `text` 为空。
 2. 工具片段按协议索引聚合：Chat 使用 `delta.tool_calls[].index`，Responses 使用 `output_index`，Anthropic 使用 content block `index`。Responses 的 `.done` 和 `response.completed` 完整 arguments 是权威值，可以覆盖之前的分片拼接。
 3. 流结束固化工具调用时，缺少 id 或函数名返回 `Deserialize`；空参数默认保存为 `{}`；非空参数必须能反序列化为完整 JSON，截断或半截 JSON 不会交给业务层。这里是 JSON 语法完整性检查，不是针对 `parameters` 的 JSON Schema 业务校验。
-4. 非流式 Anthropic `tool_use.input` 缺失时同样按 `{}` 归一；Chat / Responses 非流式响应的 arguments 仍以各自上游字段为准，调用方不能把缺失字段自动假定为统一 schema 校验通过。
+4. 非流式工具调用采用不同的参数边界：缺失或空白 `arguments` 统一归一为 `{}`；Chat / Responses 的非空畸形 `arguments` 不在平台层做 JSON 校验、修复或静默丢弃，而是保留参数内容（仅按统一归一策略去除首尾空白），连同 call id 和函数名交给调用方的 repair 循环。Anthropic `tool_use.input` 缺失时同样按 `{}` 归一；调用方不能把非流式参数自动假定为统一 schema 校验通过。
 
 ## 5. 错误边界
 
 1. `Deserialize`：上游 JSON、SSE 或 UTF-8 无法解析，Chat 非流式缺少 `choices[0]`，流式工具调用缺少 id / name，或流式工具参数不是完整 JSON。
 2. `StreamUnavailable`：仅用于流式响应已声明 `tool_use` / `tool_calls`，但一个工具 slot 都没有聚合出来的协议兼容失败；调用方可以据此回退一次非流式请求，不能把已收到的解说文本当成最终回复。
 3. `EmptyResponse`：最终文本为空且工具调用也为空。只有文本为空但存在有效工具调用时，响应才是合法的纯工具响应。
-4. 流尾部出现 `Timeout`、`Connectivity`、`Transport` 或 `Deserialize` 时，只有已形成非空文本、完成原因且工具参数完整的响应才会保留；工具参数半截或没有可保留文本时继续返回错误。
+4. 流尾部出现 `Timeout`、`Connectivity`、`Transport` 或 `Deserialize` 时，只有已形成非空文本或至少一个工具调用、观察到协议完成信号、已有完成原因且工具参数完整的响应才会保留；纯工具响应即使 `text` 为空也可以保留。工具参数半截或既没有文本也没有工具调用时继续返回错误。
 
 ## 6. 核心导出