同步 Anthropic 原生工具的技术方案与决策记录

App 实施计划与 Runtime V1.1 更新为三种协议统一使用原生工具目录，补充 Anthropic 的 input_schema 与对象形态 tool_choice 约定
旧 wrapper 与 text JSON parser 只描述为历史响应、确定性 fixture 和模型不守协议时的降级解析，不再写成任何 Provider 的正常请求路径
decision-log 追加 2026-07-27 取代性决策，并给 2026-07-16、2026-07-12 与 2026-07-24 三处受影响描述加上后续更正标记

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

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

@@ -99,6 +99,8 @@
 
 ## 2026-07-16 AI 游戏创作 Agent Runtime 使用 Provider 原生工具目录
 
+> 后续更正：本条把 Anthropic 与「历史 fixture 和旧响应」并列为 wrapper/text JSON 兼容对象的描述，已由 2026-07-27「Anthropic 与流式统一使用 Provider 原生工具」取代；Anthropic 现在与 Chat / Responses 一样发送原生工具目录，text JSON 只剩历史响应与 fixture 兼容。下文保留作历史记录。
+
 - 背景：OpenAI-compatible planning 虽已使用 function calling，但只向 Provider 提供 `submit_agent_tool_plan` 包装函数，真实工具藏在 `actions[].tool + input` 中，具体工具名和参数主要依赖长提示词，Provider 不能按工具 schema 约束选择与输入。
 - 决策：OpenAI Chat / Responses 直接获得稳定的 `update_agent_plan`、`respond_to_user`、每个内置 Runtime action 和动态 MCP function。内置名称从规范 tool id 映射，MCP 名称从 server/tool 身份派生；真实 MCP binding 与 fingerprint 由 Runtime 注入。每个 action 携带非空 reason 与独立 input schema，一轮最多 1 次计划更新和 3 个动作，或计划更新加最终回复；动作与回复不得共存。plan-only 是合法持久 checkpoint，应用后继续同一 run planning，未完成计划和项目验证门禁继续阻止最终化。
 - 兼容与安全：新请求和 repair 不广告旧 wrapper；parser 只为 Anthropic、历史 fixture 和旧响应保留 wrapper/text JSON 兼容。未知函数、重复 call id、重复计划/回复、四个动作、正文与 function calls 共存、MCP binding 冲突和非法参数均在副作用前失败。公共审计只保存协议、call 数量、函数名和 call id，不保存 arguments、正文或 MCP 参数。
@@ -405,7 +407,7 @@
 - 2026-07-11 调整，2026-07-15 收口：后台结构化 planning 使用独立的 4,000 输出 token 上限，最终回复使用 2,400；两者显式请求 low reasoning effort 和 low text verbosity。`platform-llm` 会把 reasoning effort 同时映射到 OpenAI Responses 的 `reasoning.effort` 与 Chat Completions 的 `reasoning_effort`，未设置时不新增字段。低推理强度和较大的可见输出余量只用于降低空响应概率；`EmptyResponse` 仍按单次 lifecycle 的歧义失败处理，不再自动原样重放。
 - 2026-07-11 补充：后台单 Agent 的工具计划响应只接受可反序列化为计划 schema 的 JSON object。解析器提取模型输出中的首个完整对象并允许对象后带普通说明；未找到完整 JSON 对象，或提取对象无法反序列化为工具计划时，Runtime 最多追加 2 次自动格式修复请求。每次修复只携带限长、脱敏后的上一次无效输出，并写入 `agent.runtime.tool_plan.repair` 审计。两次修复后仍无有效对象则按工具规划失败处理；工具规划阶段的普通文本不得转换为默认的空 actions + response，也不得据此把任务标记为完成。
 - 2026-07-11 调整：工具计划顶层 `thinkingSummary / plan / actions / response` 四个字段必须同时存在，未知顶层字段、空 thinkingSummary 和空 tool 均属于协议错误并进入同一格式修复预算，`{}` 或前置无关 JSON 对象不能再触发空计划收束。空 actions 表示 planning 收束；response 非空时直接采用，response 为空时进入独立的最终回复生成。`agent.runtime.project.verify` 审计同时保存 `runId / actionId / actionFingerprint`，使并行 Agent 的失败与通过记录能够精确归属到发起动作。
-- 2026-07-12 补充：OpenAI Chat / Responses 的后台 Agent 工具 planning 改用唯一 `submit_agent_tool_plan` 原生 function tool，字符串 `tool_choice=required` 和 strict schema；只接受恰好一次同名调用，arguments 继续经过本地计划 schema、工具白名单和权限策略校验，错误函数、多调用或非法 arguments 进入原有两次格式修复预算且不产生副作用。Anthropic 保留文本 JSON 回退；planning 非流式，最终回复仍可流式。每轮成功协议写 `agent.runtime.tool_plan.protocol`，修复审计记录 protocol、callId 和 functionName。
+- 2026-07-12 补充，2026-07-27 更正：OpenAI Chat / Responses 的后台 Agent 工具 planning 改用唯一 `submit_agent_tool_plan` 原生 function tool，字符串 `tool_choice=required` 和 strict schema；只接受恰好一次同名调用，arguments 继续经过本地计划 schema、工具白名单和权限策略校验，错误函数、多调用或非法 arguments 进入原有两次格式修复预算且不产生副作用。本条原写「Anthropic 保留文本 JSON 回退；planning 非流式」，已由 2026-07-27「Anthropic 与流式统一使用 Provider 原生工具」取代——Anthropic 同样发送原生工具目录，planning 不再因协议强制非流式。每轮成功协议写 `agent.runtime.tool_plan.protocol`，修复审计记录 protocol、callId 和 functionName。
 - 2026-07-10 补充：后台 Agent Runtime 的白名单工具继续扩到 `preview.start`，让 Agent 在完成写盘或静态自检后能按策略自行启动当前项目的 `127.0.0.1` 本地 HTTP 预览。该工具复用 `preview.start` 权限策略、项目写锁、共享 `PreviewRegistry`、manifest 预览状态、`.agent/logs/preview.log` 和 run trace 追加逻辑；写入 `.agent/agent.db` 的审计类型为 `agent.runtime.preview.start`。发给 LLM 的 observation 只包含 localhost URL 和端口，不包含用户项目绝对路径。
 - 2026-07-10 补充：后台 Agent Runtime 的白名单工具继续扩到 `canvas.asset_generate`，让美术类 Agent 可在 loop 中自行请求生成首版美术素材。该工具读取 AppData / Tauri 配置中的 `editorApi`，复用 `canvas.asset_generate` 权限策略、项目写锁、External Editor API 生成和下载链路、manifest 资产登记以及 `canvas.asset_generate` 本地索引记录；另写 `agent.runtime.canvas.asset_generate` 记录到 `.agent/agent.db`，标明触发的 agent 与本地素材路径。API Key 不进入 prompt observation、manifest、agent.db 或日志；策略要求确认或拒绝时不会调用外部 API。
 - 补充：规范 Agent ID 统一使用 manifest taskId，例如 `art-asset-plan` 和 `code-prototype`；历史前端曾使用的 `group-role` 别名只在 Tauri command 层兼容并映射到规范 taskId。主窗口 Agent 状态列表通过 `read_game_creator_agent_runtimes` 批量读取 `.agent/runtime/agents/<taskId>.json` 和最近任务，把每个 Agent 的 Runtime 状态、当前动作和最近 task 直接显示在状态卡片和 `/agents` 汇总里。
@@ -5288,6 +5290,8 @@
 
 ## 2026-07-24 Supervisor 与部门 Director 使用统一 Interaction Loop
 
+> 后续更正：本条「非原生 tool Provider 使用同构严格 JSON envelope 适配」的描述已由 2026-07-27「Anthropic 与流式统一使用 Provider 原生工具」取代；三种协议都提供原生 tool，interaction loop 不再存在按协议切换 JSON envelope 的分支，开启流式时也能拿到流式工具调用。下文保留作历史记录。
+
 - 背景：`--swarm-chat` 曾在模型调用前用字符串包含判断选择 Chat / Execute / Resume，否定句、复合请求和未列入词表的工作请求都会误路由；busy Runtime 期间的裸聊天还可能绕过 Agent lane 并与原 run 交错写同一 Session。
 - 决策：删除自然语言关键词分类和硬编码自然语言直答。Project Supervisor 与角色目录中 `role.id=director` 的六个部门负责人使用统一 interaction loop；自然语言回复与 `project_location / runtime_execute / runtime_resume` 都来自同一次 Provider turn 的直接文本或原生 function tool。叶子专业 Agent 保持合同执行者，不接入该外层决策能力。
 - Canonical 输入：`runtime_execute` 不允许模型提交 task 参数，真正入队始终使用用户原始消息，避免模型改写时丢失否定、范围和验收条件。非原生 tool Provider 使用同构严格 JSON envelope 适配；模型只能提出 intention，不能选择 runId、越过权限或直接执行项目副作用。
@@ -5338,3 +5342,14 @@
 - 并发补验：确定性 Provider 只在 Runtime 明确返回 revision blocker、专业 verification-only repair、成功验证 observation，或项目锁 / repository context drift 这两类可恢复 observation 时重放终态；每个 logical run 最多 16 次。只读职责不得借补验调用未授权命令，验证失败或缺少 `ok` observation 不能交付，Provider completion 计数始终 exactly-once。
 - 画布审计：资源 manifest 可以保留生成 prompt 作为本地来源元数据，但公开 `asset.register / asset.update` 审计记录必须移除 `source.prompt`，只保留 canvas/resource/task/model 等身份字段，避免完整生成正文进入公开 Agent DB 表面。
 - 当前测试事实：已有回归覆盖固定画布合同不允许被模型改写、已登记 spritesheet 禁止先删除、只有静态 repair 可原位替换、替换期间原文件 fingerprint 漂移时拒绝覆盖，以及 `design-foundation` 对 `game/index.html` 的 write / patchset / delete 和预览工具均被 Runtime 策略阻断。2026-07-27 的独立 75 分钟上限外部真实 E2E 已按上一节单轮证据完整 **PASS**；后续合同变化仍须新起独立轮次，不能复用这次结果替代未来验收。
+
+## 2026-07-27 Anthropic 与流式统一使用 Provider 原生工具
+
+- 背景：`platform-llm` 的 Anthropic 分支从未实现工具——请求体没有 `tools` / `tool_choice` 字段，`validate()` 还会以「Anthropic api_kind 暂不支持 function tools」本地拒绝，响应解析只取 `text` block 并硬编码 `tool_calls: Vec::new()`。App 侧因此在 `provider_request_builders.rs` 与 `interaction.rs` 用 `api_kind != Anthropic` 绕开原生工具，改用长提示词描述工具并要求模型输出单个 JSON object，等于让 Anthropic 退回 V1.26 之前的状态。三种协议的流式路径同样恒返回空工具调用，靠「无文本 → EmptyResponse → 非流式重打」兜底；模型若在工具调用前先输出解说文本，该兜底不触发，工具调用会被静默丢弃并把解说当成最终回复。
+- 前提验证：MiniMax 的 Anthropic 兼容层与真实 OpenAI 均完整支持工具调用，说明这是本地实现缺口而非上游限制。实测覆盖 `tools` + 四种 `tool_choice`、并行多工具、`tool_result` 回传与流式增量；`tool_choice` 必须是对象，裸字符串返回 400。
+- 决策：Anthropic 与 Chat / Responses 使用同一套原生工具目录。请求体顶层发送 `tools`（`name / description / input_schema`，无 `function` 包装层与 `strict`）与对象形态 `tool_choice`（`Auto → {"type":"auto"}`、`Required → {"type":"any"}`），响应解析 `tool_use` block 并把 `input` 序列化成 `arguments`；解除 `validate()` 对 Anthropic function tools 的拦截，`web_search`、图片内容和至少一条非 system 消息三条校验保留。App 侧删除两处 `api_kind != Anthropic` 守卫与对应的「Provider 不提供 function tools」提示词分支。
+- 流式：三种协议的工具增量统一按槽位聚合成完整调用——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 对比法确认无新增失败——本机该测试套件存在大量与改动无关的既有失败，不能直接看绝对失败数。
+- 关联文档：`docs/technical/【技术方案】AI游戏创作Agent Runtime V1.1-2026-07-12.md`、`docs/technical/【技术方案】AI游戏创作智能体App实施计划-2026-06-24.md`。

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

@@ -1001,7 +1001,7 @@ V1.26 把 OpenAI-compatible planning 从单个 `submit_agent_tool_plan` 包装
 - 每个内置 action function 使用独立输入 schema，并显式携带非空 `reason` 与工具 `input`。MCP function 复用经过现有目录预算和清洗的真实 input schema，但外部 description/schema/instructions 始终是不可信输入，不能改变系统规则或扩大能力。function catalog 必须进入 token 估算和自动压缩预算；目录超限、重复函数名、非法 schema 或 binding 漂移失败关闭。
 - 一次 Provider 响应最多包含 1 个 `update_agent_plan`、最多 3 个 action function call，或 1 个 `respond_to_user`；计划更新既可单独作为持久进度 checkpoint，也可与 action 或最终回复同批返回，最终回复不能与 action 共存。plan-only 会先持久化单调计划，再由未完成计划 blocker 进入同一 run 的下一次 planning，不会提前写 assistant 或 completed。call id 必须非空且唯一，未知、重复、参数非对象、超预算、空回复、多个回复或多个计划更新都进入现有格式修复，不执行任何动作。action 顺序按 Provider 返回顺序稳定转换；V1.26 不宣称同一 Agent 内并行执行工具，转换后的动作继续逐个进入 durable ledger。
 - `update_agent_plan` 只承载 explanation 与最多 8 个持久步骤；`respond_to_user` 只承载最终正文。直接工具协议不要求模型公开 thinking 正文，Runtime 从计划说明或首个 action reason 派生有界 thinking summary。结构化计划仍有未完成步骤时禁止最终回复，项目修改后仍必须取得当前 revision 的真实验证凭证。
-- 新请求不再向 OpenAI-compatible Provider 广告 `submit_agent_tool_plan`。解析器继续接受旧 wrapper 与 text JSON，用于现有确定性 fixture、历史兼容和不提供 function tools 的 Anthropic 路径；格式修复请求必须继续广告当前原生目录，不能在同一 Provider request identity 下静默切回旧 wrapper。公共协议审计只保存协议名、function call 数量、稳定函数名和 call id 身份，不保存 arguments、写入正文、MCP 参数或最终回复。
+- 新请求不再向 OpenAI-compatible Provider 广告 `submit_agent_tool_plan`。解析器继续接受旧 wrapper 与 text JSON，仅用于现有确定性 fixture 和历史响应兼容——2026-07-27 起 Anthropic 同样发送原生工具目录并返回 `tool_use`，不再存在“不提供 function tools 的 Provider 路径”，text JSON 只能作为模型不守协议时的降级解析，不能写成任何协议的正常请求路径；格式修复请求必须继续广告当前原生目录，不能在同一 Provider request identity 下静默切回旧 wrapper。公共协议审计只保存协议名、function call 数量、稳定函数名和 call id 身份，不保存 arguments、写入正文、MCP 参数或最终回复。
 - 确定性验收必须覆盖完整内置目录、函数名稳定性、核心 schema、动态 MCP binding、计划 + 多 action、计划 + reply、顺序、未知/重复/冲突/超预算拒绝、旧 wrapper/text 兼容、repair 后仍使用原生目录、token 预算和公共零 arguments。真实 Provider 必须在无工具名和参数配方的任务下自主选择至少一个只读工具、一个项目修改工具和真实验证工具，完成唯一目标文件交付；最终还要证明协议全程为原生目录、action/receipt/Provider lifecycle 唯一、无 wrapper fallback、唯一 assistant/completed、零正文/密钥/路径泄漏和隔离现场完整清理。
 
 2026-07-16 正式 `openai_chat / gpt-5.5` 的 `project-skill` suite **PASS**。首轮真实执行在匹配 Skill 读取后暴露旧 parser 拒绝 plan-only，保留现场复验进一步证明模型会先单独调用 `update_agent_plan`；Runtime 空动作分支原本已能持久化计划并安全进入下一轮，因此移除矛盾的 parser 拒绝并补三轮确定性闭环。最终加强门禁复跑记录 31 条 task、57 条 event、94 条 Agent DB、6 个成功工具动作和 2 个确认动作；9/9 个成功工具计划与 6/6 个格式修复全部使用 `native_runtime_tools`，旧 wrapper 与 text JSON fallback 均为 0。Agent 在首个项目修改前读取匹配 Skill 1 次、无关 Skill 0 次，只修改 1 个目标文件，Agent `project.verify` 与宿主复验均通过；15 个 tool-plan 加 1 个 final-reply Provider lifecycle 全部唯一闭合，最终 assistant/completed 各 1，重复 message/receipt、遗留 finalization、Skill 正文、API Key、诱饵、项目/正式配置路径和报告泄漏均为 0，隔离 Runner、AppData 与一次性项目完整清理。确定性 Tauri 全量为 822 passed / 4 ignored；V1.26 真实行为门禁至此完成。

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

@@ -194,7 +194,7 @@ Agent Runtime 负责：
 - 2026-07-11 调整：后台任务的可执行正文上限统一为 4,000 字符。入队 JSONL、启动后的 `currentTask/currentGoal`、planning prompt、待确认动作 task context、确认续跑和重启恢复都保留同一份正文；对话仍保存用户原始消息。状态事件、列表卡片和 `agent.db` 摘要可继续使用较短安全预览，但不能再反向作为后续 LLM 执行输入。这样长任务末尾的验收标记和输出格式要求不会在队列边界被 180 字符截断。
 - 2026-07-11 调整，2026-07-12 由 Runtime V1.2 更新：后台 planning 使用 4,000 输出 token，最终回复使用 2,400，并继续叠加最多 3 次 EmptyResponse 重试。推理档位不再硬编码为 `low`：planning、普通单 Agent 聊天和最终回复统一使用解析后的 `llm.reasoningEffort`，`agentLlm.<agentId>.reasoningEffort` 有值时覆盖全局、缺省时继承全局；取值只允许 `default / low / medium / high`，发布默认 `high`，`default` 表示不向 Provider 发送推理档位。
 - 2026-07-11 补充，2026-07-15 由 V1.17 更新：后台单 Agent 的工具 planning 响应必须提供可反序列化为 `thinkingSummary / planUpdate / plan / actions / response` schema 的 JSON object。Runtime 从模型输出中解析首个完整对象，因此对象后的尾随说明可以忽略；只有普通文本、没有完整对象，或对象无法反序列化时都不构成有效工具计划。对于这两类无效输出，Runtime 最多追加 2 次自动格式修复请求；同一次 planning 的私有 repair 请求可携带限长且经过统一敏感信息过滤的上一条模型输出或 function call 预览与协议错误，以便 Provider 真正修正格式。`.agent/agent.db` 的 `agent.runtime.tool_plan.repair` 公共审计只写 attempt/maxAttempts、protocol，以及错误、输出/调用体预览、callId 和 functionName 的 SHA-256、字符数或计数，不保存原始模型正文、错误或 function arguments。修复预算耗尽后进入既有工具规划失败路径，不得把普通文本折算为空 actions + response，也不得因此进入 completed；最终回复阶段仍按其独立的普通文本契约处理。旧文本协议可省略 `planUpdate`，但只能继续走 legacy `plan` fallback。
-- 2026-07-12 补充，2026-07-15 由 V1.17 更新：OpenAI Chat / Responses 的后台工具 planning 优先注册唯一的 `submit_agent_tool_plan` function tool，并使用字符串形式 `tool_choice=required` 和 strict schema；Runtime 只接受恰好一次同名 function call，并把 arguments 复用现有 `AgentRuntimeToolPlan` 校验与两次格式修复循环。strict arguments 中 `planUpdate` 必须出现但可为 `null`，使用结构化更新时 legacy `plan` 必须为空。错误函数名、多次调用和非法 arguments 都不得执行工具。Anthropic 保留文本 JSON 回退，planning 强制非流式，最终普通回复继续按 Agent 配置决定是否流式。`platform-llm` 会在本地拒绝无 function tools 的 tool choice 和 Anthropic function tools，并把协议类型写入 `agent.runtime.tool_plan.protocol` 审计。
+- 2026-07-12 补充，2026-07-15 由 V1.17 更新，2026-07-27 由「Anthropic 与流式统一使用 Provider 原生工具」更新：OpenAI Chat / Responses 的后台工具 planning 优先注册唯一的 `submit_agent_tool_plan` function tool，并使用字符串形式 `tool_choice=required` 和 strict schema；Runtime 只接受恰好一次同名 function call，并把 arguments 复用现有 `AgentRuntimeToolPlan` 校验与两次格式修复循环。strict arguments 中 `planUpdate` 必须出现但可为 `null`，使用结构化更新时 legacy `plan` 必须为空。错误函数名、多次调用和非法 arguments 都不得执行工具。Anthropic 自 2026-07-27 起与另外两种协议一致发送原生工具目录：请求体顶层携带 `tools`（schema 字段名为 `input_schema`，无 `strict`）与对象形态 `tool_choice`（`Auto → {"type":"auto"}`、`Required → {"type":"any"}`，裸字符串会被上游拒绝），响应解析 `tool_use` block 并把 `input` 序列化为 `arguments`。planning 不再因协议强制非流式，最终普通回复继续按 Agent 配置决定是否流式。`platform-llm` 仍在本地拒绝无 function tools 的 tool choice，但不再拒绝 Anthropic function tools；协议类型继续写入 `agent.runtime.tool_plan.protocol` 审计，Anthropic 正常路径的取值为 `native_runtime_tools` 而不是 `text_json`。
 - 2026-07-11 调整，2026-07-15 由 V1.17 更新：工具计划五个顶层字段均为必填并拒绝未知顶层字段；`thinkingSummary`、结构化计划的 `explanation / step` 与 `action.tool` 必须非空。`planUpdate` 只接受 `null` 或最多 8 个唯一步骤，状态限于 `pending / in_progress / completed` 且至多一个 `in_progress`。这样 `{}`、前置无关 JSON 或结构不完整对象会触发格式修复，不会成为假完成信号。空 actions 只有在 verification、process/join/delivery 和结构化计划完成门禁都通过后才表示 planning 收束；response 非空时直接采用，response 为空时进入独立最终回复生成。`agent.runtime.project.verify` 记录补充 `runId / actionId / actionFingerprint`，用于在多 Agent 并行验证时把命令终态与具体 Runtime 动作关联。
 - 2026-07-15 V1.17 公共审计收紧：`thinking_summary` event 只保存固定摘要、正文 SHA-256 与字符数，legacy `plan` event 只保存步骤数；结构化计划审计只保存 explanation 的哈希与字符数，以及 step 标题哈希、状态和数量。模型 thinking、legacy plan 标题、repair 错误和调用体只允许出现在对应私有 Runtime 上下文或有界 repair 请求中，不得复制到公共 event、task 或 Agent DB 正文字段。
 - 2026-07-10 补充：Agent Runtime state / result 新增 `taskQueue`，从 `.agent/runtime/tasks/<agentId>.jsonl` 中每个 `runId` 的最新记录汇总 `total / pending / running / completed / failed / latestRunId`；开发窗口 Runtime 面板、主窗口 Agent 状态列表、`agent.run_status` observation 和下一轮 planning prompt 都读取该摘要，用于判断同一 Agent 是否仍有排队任务。该字段是运行观测摘要，不新增调度器、SQLite 或独立 worker。
@@ -652,7 +652,7 @@ game-project/
 - 2026-07-16 V1.24 已完成真实验收：正式 `openai_chat / gpt-5.5` 的 `scoped-agents` suite 在无规则正文、期望内容和工具配方的任务下，让同一 Agent 只修改 `alpha / beta` 两个兄弟目录交付文件；根、父、各自叶规则全部精确命中且兄弟串用为 0，Agent `project.verify` 与宿主复验均通过。最终脚本复跑的 8 组 Provider lifecycle 唯一闭合，最终 assistant/completed 各 1，重复持久化，以及最终回复/公共审计/报告中的规则正文、API Key、诱饵、项目/配置路径泄漏均为 0，隔离现场完整清理；不再把 prompt 可见性代替模型遵循证据。
 - 2026-07-16 起，同一 Runtime 文档的“V1.25 Codex 式项目 Skill 发现与渐进加载”作为项目工作流加载事实源。仓库启动上下文升级为 `repository-startup-context-v3`，只发现项目内 `.codex/skills/<name>/SKILL.md` 与 `.agents/skills/<name>/SKILL.md` 直接入口，同名时 `.codex` 优先；首轮 prompt 只注入清洗后的 `name / description / entryPath / contentSha256`，正文必须在任务命中后通过现有 `file.read` 按需读取。Skill 不能扩大工具、权限、确认、沙箱、隐私或完成门禁，与适用路径的 `AGENTS.md` 冲突时后者优先；active Skill 变化推进 repository fingerprint 并阻断旧 pending 动作后重规划。
 - 2026-07-16 V1.25 已完成真实验收：正式 `openai_chat / gpt-5.5` 的 `project-skill` suite 先让 hash-only 原始验收真实失败；Agent 在首个变更前精确读取匹配 Skill 1 次、无关 Skill 0 次，以 1 个变更动作只修改目标文件，Agent `project.verify` 与宿主复验均通过。最终脚本复跑记录 25 条 task、41 条 event、57 条 Agent DB 和 5 个成功工具动作；4 组 tool-plan Provider lifecycle 唯一闭合，最终 assistant/completed 各 1，Skill 正文、API Key、诱饵、项目/配置路径泄漏和重复持久化均为 0，隔离 Runner/AppData/项目完整清理。
-- 2026-07-16 起，同一 Runtime 文档的“V1.26 Provider 原生工具目录”作为 OpenAI-compatible planning 协议事实源。Chat / Responses 不再只广告 `submit_agent_tool_plan` 包装函数，而是直接提供 `update_agent_plan`、`respond_to_user`、全部内置 Runtime action 和动态 MCP function；每个函数使用独立 schema，Runtime 继续负责身份、权限、确认、沙箱、revision、验证、恢复与副作用防重放。Anthropic 与历史 fixture 保留 text JSON / wrapper 解析兼容，但新请求和 repair 不能静默降级。plan-only 是合法持久 checkpoint，未完成计划仍阻止最终化。
+- 2026-07-16 起，同一 Runtime 文档的“V1.26 Provider 原生工具目录”作为 OpenAI-compatible planning 协议事实源。Chat / Responses 不再只广告 `submit_agent_tool_plan` 包装函数，而是直接提供 `update_agent_plan`、`respond_to_user`、全部内置 Runtime action 和动态 MCP function；每个函数使用独立 schema，Runtime 继续负责身份、权限、确认、沙箱、revision、验证、恢复与副作用防重放。2026-07-27 起 Anthropic 也走同一套原生工具目录，text JSON / wrapper 解析只作为历史响应与确定性 fixture 的兼容入口，不再是任何 Provider 的正常请求路径；新请求和 repair 不能静默降级。plan-only 是合法持久 checkpoint，未完成计划仍阻止最终化。
 - 2026-07-16 V1.26 已完成真实验收：正式 `openai_chat / gpt-5.5` 的 `project-skill` suite 中 9/9 个成功工具计划与 6/6 个格式修复全部使用 `native_runtime_tools`，wrapper/text fallback 均为 0。Agent 自主读取匹配 Skill、只改唯一目标文件并完成 Agent/宿主双重验证；15 个 tool-plan 和 1 个 final-reply lifecycle 唯一闭合，最终 assistant/completed 各 1，重复、Skill 正文、API Key、诱饵、项目/配置路径和报告泄漏均为 0，隔离 Runner/AppData/项目完整清理。
 - 2026-07-16 V1.26 后重新加强并复验 `goal-runtime`：Goal suite 现在把成功计划、repair、call metadata、wrapper/text fallback 和协议审计零 payload 纳入硬门禁。正式 `openai_chat / gpt-5.5` 最终复跑的成功计划 21/21、repair 17/17 全为 `native_runtime_tools`；Goal edit、旧动作失效、真实失败修复、pause、Runner 强杀、显式同 run resume、verification、finalization 和唯一回复全部 PASS，重复、重放、正文、密钥、诱饵与路径泄漏均为 0。Goal 阶段等待同时增加 terminal fail-fast，Provider transport failure 不再占满 30 分钟验收超时。
 - 2026-07-24 补充：`agc:test:chat / autonomous-game-build` 不再只因 `game/index.html` 可试玩就跳过已配置的画布能力。有效运行时配置存在 `editorApi.apiKey` 且项目尚无规范 `canvas / image/* / art-spritesheet` 本地素材时，缺省 Supervisor 首批协作固定加入 `art-asset-plan`，并要求真实交付 `assets/art-spritesheet.png`；该 Agent 继续通过 `canvas.asset_generate` 把结果同时写入 External Editor 画布、素材库、本地 assets 与 manifest。已有有效首版素材的后续修复轮不重复生成或扣费。该工具仅在自主构建 profile 的 `design-foundation / art-asset-plan` 视觉职责中作为固定 auto-safe 动作，Supervisor、程序和其他非视觉 Agent 一律拒绝，避免同一路径并发生成和重复扣费；普通模式和显式 deny 不变，Key 缺失时不伪造图片产物。