合并master并保留AGC登录态续期修复

同步最新 master 代码并解决 AGC 客户端冲突保留模型 API 与 DirectProject 对话的自动续期重试补充续期边界测试与认证排障文档
2026-09-11 17:56:51 +08:00
parent 77892a8930 11c8cbdf67
commit 3b4c006dd5
249 changed files with 19338 additions and 37179 deletions
@@ -22,13 +22,15 @@
 - [LLM 累计额度结算](./technical/【技术方案】LLM累计额度结算-2026-09-05.md)：Router 累计额度、首次基线与原子钱包结算。

 - [AI 游戏创作智能体 App 实施计划](./technical/【技术方案】AI游戏创作智能体App实施计划-2026-06-24.md)：当前 DirectProject、受控语义工具、UI workflow、资源和运行时合同。
+- [策划会话 Runtime V2 接入与旧链路退役方案](./technical/【技术方案】策划会话RuntimeV2接入与旧链路退役-2026-09-03.md)：新单 Agent 策划会话、GDD 策略、未来 MCP/Skill 兼容插槽、阶段任务与退役验收合同。
+- [DirectProject Codex 原始历史与异常恢复](./technical/【技术方案】DirectProject%20Codex原始历史与异常恢复-2026-09-04.md)：原始 Responses item 持久化、线程注入与异常回合收尾。
 - [DirectProject 客户端 Skill 与 MCP 扩展导入方案](./technical/【技术方案】DirectProject客户端Skill与MCP扩展导入方案-2026-08-31.md)：客户端扩展导入、按独立 Skill/MCP 拆分、命名、启用和启动时注入边界。
 - [AGC 客户端更新检查与下载](./technical/【技术方案】AGC客户端更新检查与下载-2026-08-31.md)：启动版本检测、OSS 清单格式和下载约定。
 - [DirectProject 本轮附件路径映射](./technical/【技术方案】DirectProject本轮附件路径映射-2026-08-31.md)：Direct 首轮只映射附件原名与项目相对路径，不灌正文、不区别 GDD。
 - [Direct 回合行为审计账本](./technical/【技术方案】Direct回合行为审计账本-2026-08-31.md)：Direct GUI 回合把 native 读 / MCP / 写文件落成项目内有界时间线，用于判断有没有打开本轮附件。
 - [项目开发工作台 PRD](./prd/【AI游戏创作】项目开发工作台PRD-2026-07-20.md)：当前工作台页面和验收边界。
 - [AGC 错误报告与诊断上传](./technical/【技术方案】AGC错误报告与诊断上传-2026-08-31.md)：当前进程错误事件、应用级日志和管理员查看器合同。
- [立项策划 Agent（Fast GDD）](<./technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md>)：当前策划入口、审批和恢复合同。
+- [立项策划 Agent（Fast GDD）](<./technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md>)：旧 `project-supervisor-plan` / `project-planning` 历史会话的入口、审批和恢复合同；V2 切换时未完成旧会话强制失败。
 - [GameAgent 资源自由画板与快速编辑](./technical/【技术方案】GameAgent资源自由画板与快速编辑-2026-08-20.md)
 - [UI 工作流资源桥接与 Runtime 执行](./【技术方案】UI工作流资源桥接与Runtime执行-2026-08-24.md)
 - [UI 编辑器 Godot 容器布局](./technical/【技术方案】UI编辑器Godot容器布局模型-2026-08-18.md)
@@ -3372,8 +3372,14 @@
          },
          "sliceLayout": {
            "type": "string",
-            "enum": ["grid-2x2"],
-            "description": "可选固定图集切片合同。省略时沿用全图 alpha 连通域自动拆分；传 grid-2x2 时服务端要求生成四个固定象限，并按左上、右上、左下、右下各持久化一个独立切片。该模式适用于需要恰好四类核心运行时素材的游戏，不会猜测等分裁切。"
+            "deprecated": true,
+            "description": "历史兼容字段，新的调用请使用 sliceCount。"
+          },
+          "sliceCount": {
+            "type": "integer",
+            "minimum": 1,
+            "maximum": 100,
+            "description": "可选的目标切片数量；省略时按图像内容自动识别。"
          },
          "screenColor": {
            "type": ["string", "null"],
@@ -3597,15 +3603,21 @@
          },
          "iconImageSrcs": {
            "type": "array",
-            "description": "默认模式识别图集中全部有效 alpha 连通域并持久化的独立素材，按视觉阅读顺序命名为“素材 N”；数量由图集内容决定，不由 iconDescriptions 数量决定。sliceLayout=grid-2x2 时固定返回左上、右上、左下、右下四个格子的切片，各格内的零散视觉细节不会被拆成额外素材。",
+            "description": "识别图集中有效 alpha 连通域并持久化的独立素材，按视觉阅读顺序命名为“素材 N”；可通过 sliceCount 指定目标数量。",
            "items": {
              "$ref": "#/components/schemas/EditorIconSpritesheetIconResult"
            }
          },
          "sliceLayout": {
            "type": "string",
-            "enum": ["grid-2x2"],
-            "description": "仅当请求使用固定切片合同且主图完成透明化、切片持久化后返回。调用方可将该字段与 iconImageSrcs=4 共同作为固定四类素材的来源证明。"
+            "deprecated": true,
+            "description": "历史兼容字段。"
+          },
+          "sliceCount": {
+            "type": "integer",
+            "minimum": 0,
+            "maximum": 100,
+            "description": "实际生成的切片数量。"
          },
          "sliceWarning": {
            "anyOf": [
@@ -185,7 +185,7 @@ completed -> starting(nextSlice)
 idle -> focused(document|art|audio|version) -> idle
 ```

- 文档：合法 Agent 文本回执直接使用对话投影内容；项目文件只允许读取当前 manifest 已登记资产或已完成任务产物中的 Markdown、文本、JSON、YAML、TOML，必须经过 `file.read` auto 权限、相对路径、项目边界、普通文件、符号链接 / 硬链接、读取漂移、2 MiB、UTF-8 与扩展名白名单校验。正文使用不执行 HTML、不加载远程图片、不产生可点击外链的安全 Markdown 渲染，并在中央画布内独立滚动；读取失败显示错误空态。
+- 文档：合法 Agent 文本回执直接使用对话投影内容；项目文件只允许读取当前 manifest 已登记资产或已完成任务产物中的 Markdown、文本、JSON、YAML、TOML，必须经过 `file.read` auto 权限、相对路径、项目边界、普通文件、符号链接 / 硬链接、读取漂移、2 MiB、UTF-8 与扩展名白名单校验。正文使用不执行 HTML、不加载远程图片、不产生可点击外链的安全 Markdown 渲染，并在中央画布内独立滚动；读取失败显示错误空态。聊天侧 `/read` 回执中的文件正文必须作为代码块渲染为 `<pre><code>`，以便用户审阅源码字面量但不执行其中的 HTML；Markdown 渲染使用 `react-markdown` 的 `skipHtml`，依赖库对代码 span / fenced code 的文本转义；不得在整段 Markdown 上预转义 HTML，否则会把代码中的 `<tag>` 双重转义为字面量 `&lt;tag&gt;`。
 - 美术：PNG、JPEG、WEBP、GIF、SVG、AVIF、BMP、MP4、WebM、MOV 只在资源卡本体中按既有受控读取、文件签名与解码门禁展示；中央详情不重复加载或放大图片 / 视频本体。SVG 继续拒绝脚本、事件处理器、外部资源引用和实体声明。
 - 音频：只读取 manifest 已登记音频或已成功导入且登记到 manifest 的附件，按文件签名接受 MP3、WAV、OGG / Opus、M4A、AAC、FLAC；聚焦态展示实际格式、浏览器解码后的时长以及带播放进度和暂停能力的内置播放器。音频任务声明中的未登记路径继续不得读取或播放。
 - 版本：只展示 manifest 中正式、不可变的迭代版本记录；版本卡展示项目修订、创建原因与父版本，聚焦态同时展示直接子版本和资源绑定。点击版本卡后高亮仍存在于当前资源投影中的引用资源；缺失历史资源只保留绑定身份，不生成幽灵资源卡。资源替换仍留给后续切片。
@@ -15,6 +15,97 @@
 - 关联文档：相关 PRD、技术文档、提交或 Issue
 ```

+## 2026-09-05 Planning V2 一次性写路径对齐 V1 的项目锁等待窗口
+
+- 背景：V2 审批修改意见后立即 `continue_planning_session_v2`。审批、回合启动、策略落盘和 hydrate 原先无等待取锁，和 GUI 重灌或其它写操作撞车就返回 `项目正在被其他写操作占用`，前端再映射成总控失败。V1 已用完整/短窗口处理同一形状。
+- 决策：V2 审批、回合启动、策略落盘、失败投影和 GDD 认领使用完整等待窗口；V2 hydrate 使用短窗口。不引入可重入项目锁，不放宽失效回收。
+- 影响范围：`planning_policy_v2.rs`、`planning_session_v2.rs`、V2 hydrate 前端瞬时争用处理。
+- 验证方式：Rust 定向测试覆盖短暂占用下的审批、修订续跑和 hydrate。
+- 关联文档：`docs/technical/【技术方案】策划会话RuntimeV2接入与旧链路退役-2026-09-03.md`、`docs/project-memory/shared-memory/pitfalls.md`。
+
+## 2026-09-05 本进程新建 Windows 私有对象不因继承 DACL 自动 UAC
+
+- 背景：#211 要求 sidecar 满足当前用户独占、禁止继承的 DACL。新建文件会先继承父目录 ACE，生产路径把这种短暂不合格送进 UAC；`project.lock` 还在独占句柄上 harden。含空格项目路径上提权 ArgumentList 被拆开，修复以 exit 1 失败。GDD 审批改意见因此弹权限，V1 锁创建不会。
+- 决策：`harden_new_game_creator_private_path` 只在本进程收紧 owner/DACL，失败则删除刚创建的对象，不 UAC 接管。项目锁先写再释放句柄再 harden，并用内容回读防换绑；UAC 仍只用于允许范围内的已有外人本对象。提权 helper 的 ArgumentList 改为一条按 Windows 规则加引号的字符串。
+- 影响范围：`config.rs` 的新建 harden 与提权命令行、`project/write_lock.rs` 的项目锁创建；不改变锁竞争、失效回收、Drop 删除，也不放宽 symlink / reparse / 外人本 fail-closed。
+- 验证方式：Windows 定向测试覆盖 `Genarrative GameAgent\gameagent-*` 取锁与私有 DACL，以及带空格路径的 quoted ArgumentList。
+- 关联文档：`docs/technical/【技术方案】AI游戏创作智能体App实施计划-2026-06-24.md`、`docs/project-memory/shared-memory/pitfalls.md`。
+
+## 2026-09-05 Planning V2 的 3 轮策略与 8 个问题门禁有意不对称
+
+- 决策：模型提示最多提问 3 轮，并在达到 3 后要求出稿；Runtime `question_limit` 默认 8，对偏离模型策略的合法问题保留接收空间，达到 8 才拒绝新 question。前者是模型行为指令，后者是运行时接收边界，数值有意不同，不是缺陷或配置不一致。
+- 评审口径：Session/UI 的 8 是容量，不是必须问满的配额；正常路径在 3 轮或更早出稿符合设计。不得仅因数值不同，把模型提示改为按 `question_limit` 出稿、把 3 改成可继续到 8 的软目标，或把 Runtime 门禁收紧为 3。
+- 影响范围：仅补充文档解释，现有提示词、运行逻辑、校验和测试保持不变。
+- 关联文档：[策划会话 Runtime V2 接入与旧链路退役方案 §1.3](../../technical/【技术方案】策划会话RuntimeV2接入与旧链路退役-2026-09-03.md#13-问询策略与-runtime-门禁的不对称设计)。
+
+## 2026-09-04 Planning V2 将决定 ID 从 Provider 输入移回 Runtime
+
+- 背景：`plan_submit_gdd` 原先要求模型生成 `decisions[].id` 及原型验证项引用 ID。该字段既不是方案内容，又容易出现 `initial_request`、`initialRequest` 或错误层级，导致合法 GDD 在 Runtime 事后校验阶段失败。
+- 决策：Provider-facing `plan_submit_gdd` schema 和入参删除决定/原型验证项 ID。Runtime 按决定数组顺序生成首项 `initial-request`、后续 `decision-{序号}`，并按 `prototype_pending` 决定顺序给原型验证项绑定同一 ID。最终持久化 `plan-gdd.v2` 仍保留 ID，供审批、引用和 fingerprint 使用。V2 尚未上线，不为旧 Provider 输入或历史 V2 artifact 增加兼容转换；不符合新契约的历史数据按现有失败策略处理。
+- 影响范围：`planning_policy_v2.rs` 的工具 schema、Provider 入参解析、Runtime 产物构建与定向测试；Planning V2 技术方案。
+- 验证方式：定向 Rust 测试确认 schema 不含 ID、无 ID 输入可生成 Runtime ID；并运行 `cargo fmt --check`、`npm run check:encoding`、`git diff --check`。
+- 关联文档：`docs/technical/【技术方案】策划会话RuntimeV2接入与旧链路退役-2026-09-03.md`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_policy_v2.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_session_v2.rs`。
+
+## 2026-09-04 Planning V2 持久化每次 Provider 尝试的诊断产物
+
+- 背景：Provider 已成功返回但策略解析失败时，原 V2 只保留最终错误，无法核对实际请求、原始工具参数和单次重试结果。
+- 决策：在 `.agent/planning-v2/debug/<call-id>/` 保存每次尝试的 request、response 和分类事件；诊断文件不进入会话上下文，不参与恢复、重试或 GDD 业务判断，写入失败不改变主流程结果。
+- 影响范围：`planning_session_v2.rs` 的 Provider 调用外围和 Planning V2 技术方案持久化目录说明。
+- 验证方式：通过 Provider 请求/响应产物可还原每次尝试及 `toolCalls.arguments`，并确认主流程仍按原有解析、重试和状态转换执行。
+- 关联文档：`docs/technical/【技术方案】策划会话RuntimeV2接入与旧链路退役-2026-09-03.md`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_session_v2.rs`。
+
+## 2026-09-04 Planning V2 把 `gdd.vN.json` 创建成功当作提交点
+
+- 背景：V2 persist 先 create-only 写入不可变 GDD，再更新 index、Markdown、conversation 和 session。后续任一步失败会把 session 标成 `provider_failed`，但不回滚已创建文件；重试会重新生成 UUID/时间戳并撞上“已存在且内容不同”，hydrate 又只信 `current_artifact_version`，项目会卡死。
+- 决策：`gdd.v{N}.json` 创建成功即提交点，禁止回滚不可变文件。persist / hydrate / 回合启动若发现 session 指针的下一个连续版本已在磁盘，必须读取既有 GDD 补投影，不得用新的 LLM 入参重建身份。session 指针写成功前的投影失败仍可返回 persist 错误，但恢复路径必须认领该版本。
+- 影响范围：`planning_policy_v2.rs` persist/认领、`planning_session_v2.rs` hydrate 与回合启动；V2 技术方案。
+- 验证方式：Rust 测试覆盖孤儿 GDD 重试认领、hydrate 认领、成功提交后仍分配下一版本；`cargo fmt --check`、`npm run check:encoding`、`git diff --check`。
+- 关联文档：`docs/technical/【技术方案】策划会话RuntimeV2接入与旧链路退役-2026-09-03.md`。
+
+## 2026-09-04 PlanningSessionRuntime V2 用协议工具输出问询和 GDD
+
+- 背景：原型已验证 `plan_ask_question` / `plan_submit_gdd` 两个协议工具、深层 schema、提示词只留策略、`tool_choice=auto` 可跑通；生产 V2 仍解析正文 `{kind,question|gdd}` JSON，并把形状骨架写在 system prompt 里。浅 schema + 正文 JSON 会误导模型把 GDD 写成普通文本；`tool_choice=required` 与 DeepSeek thinking 不能同时使用。
+- 决策：V2 Provider 请求固定挂这两个协议工具，`tool_choice=auto`，`strict=false`。模型必须恰好调用其中一个；Runtime 解析 `toolCalls` 归一为 Question/Artifact，正文 JSON 视为非法。system prompt 只保留问询/出稿策略和当前问询进度，不再附 JSON 骨架或数量清单。入参不再要求模型回声 `schemaVersion`，落盘 GDD 仍由 Runtime 写入 `plan-gdd.v2`。既有结构门禁（含 `initial-request` 首项、`validate_plan_game` 数量/字数）不变，失败仍回灌一次。不把协议工具写入 `capabilities.tools`，不执行 MCP/Skill，不把 `tool_call`/`tool_result` 写入会话消息。
+- 影响范围：`planning_session_v2.rs` 请求构造、重试文案与 Provider 结果投影；`planning_policy_v2.rs` 工具 schema、解析和入参 `schemaVersion`；V2 技术方案。
+- 验证方式：Planning V2 定向 Rust 测试覆盖工具解析、缺 `schemaVersion` 的合法 GDD、正文 JSON 拒收、工具 schema 含嵌套 `game` 字段、提示词不再含骨架；`cargo fmt --check`、`npm run check:encoding`、`git diff --check`。
+- 关联文档：`docs/technical/【技术方案】策划会话RuntimeV2接入与旧链路退役-2026-09-03.md`。
+
+## 2026-09-03 新建策划会话采用 PlanningSessionRuntime V2，旧 Supervisor 链路直接退役
+
+- 背景：现有“做方案”依赖 `project-supervisor-plan` 根 Run、`project-planning` 子 Run、静态委派、delivery、Acceptance Graph 和审批前 evidence。新策划 Agent 只需要单 Agent 会话、问询、GDD 和审批；继续在旧 Runtime 上逐条放宽会保留身份/编排耦合。未来策划 Agent 可能支持无限多轮、MCP 和 Skill，需要避免把当前 8 题/GDD/no-tools 固化为 Runtime 根结构。
+- 决策：新增独立 `PlanningSessionRuntime`，复用 Provider/流式、会话持久化、项目锁、原子写和基础错误恢复；当前启用 `mode=gdd`、最多展示 8 个有效问题、GDD 审批和用户修改。新建“做方案”会话不创建 Supervisor root、planning child、delegation 或 acceptance evidence。V2 使用独立 `.agent/planning-v2/` 与 V2 schema，继续输出 `game/fast_gdd.md`；不自动转换旧会话。
+- 兼容性：Session 保存 `mode`、可空 `questionLimit`、`capabilities.tools/skills`；完整会话记录与 Provider 请求上下文分离；消息模型预留 tool/skill 事件类型但本期不执行 MCP/Skill。无限问询、上下文摘要、多产物和能力执行以后作为策略/能力层扩展，不重新引入 Supervisor 身份模型。
+- 当前进度：P0 合同冻结、P1 会话内核和 P2 GDD/审批核心已落地；P3 正式入口/UI 接入已开始，P5 旧链路退役尚未开始。
+- 退役：V2 切换时旧链路直接封存；所有未完成旧会话投影为 `legacy_retired` 失败，禁止继续问询、审批、恢复或 continuation。旧 GDD、approval、conversation 和 `.agent/planning` 文件只读保留；旧入口 caller 关闭，但不删除旧代码、旧测试或旧数据。
+- 影响范围：AGC 做方案入口、Rust/Tauri planning session/Provider adapter、GDD/审批 V2、前端 planning lane、阶段任务与 BDD 验收；做游戏/做素材 DirectProject 不变。
+- 验证方式：按 `docs/technical/【技术方案】策划会话RuntimeV2接入与旧链路退役-2026-09-03.md` 的 P0～P5 阶段验收执行；至少覆盖第 8 个问题、上限后 question 抑制、Provider 失败、非法输出、批准/修改/退回、重启恢复、旧会话切换强制失败、迟到 Provider 结果丢弃和当前空能力快照。
+- 关联文档：`docs/technical/【技术方案】策划会话RuntimeV2接入与旧链路退役-2026-09-03.md`、`docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md`。
+
+## 2026-09-03 PlanningSessionRuntime V2 统一 Agent 推断语义
+
+- 背景：旧 V1 使用 `default_pending` / `answerSource=default` 表示未提问时由 Agent 按默认建议补齐的字段；该语义会让 V2 的 Agent 推断看起来像产品默认值，也会造成原型与生产字段不一致。
+- 决策：V2 只使用 `confirmed`、`assumption_pending`、`prototype_pending` 三种决定状态；`assumption_pending` 的来源统一为 `agent_inferred`。`answerSource` 仍不是独立阻断项，缺失或不一致时按状态归一为 `user_freeform`、`user_option` 或 `agent_inferred`。V1 的 `default_pending` / `default` 校验和历史数据保持不动，不作为 V2 合同的一部分。
+- 问询策略：V2 出稿前必须确认玩家核心行为、单局目标/核心循环、MVP 制作边界；其中任一仅由 Agent 推断时继续问一个关键问题。`questionLimit` 是 Runtime 对已展示问题数的硬上限，提示词中的“默认最多三轮”只是策略偏好，不要求与硬上限数值一致。
+- 影响范围：V2 GDD 输入/产物、Provider system prompt、前端 V2 类型与决定状态展示；旧 Supervisor/V1 存储、校验和历史产物不变。
+- 验证方式：V2 解析 `assumption_pending` 不报错并落盘为 `assumption_pending/agent_inferred`；`default_pending` 不作为 V2 合法状态；核心三项未确认时提示词要求继续问询；相关 Rust/TS 定向测试、类型和编码检查通过。
+- 关联文档：`docs/technical/【技术方案】策划会话RuntimeV2接入与旧链路退役-2026-09-03.md`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_policy_v2.rs`。
+
+## 2026-09-04 PlanningSessionRuntime V2 将既有输出阻断原因回灌给 Provider
+
+- 背景：原型已将会导致输出拒收的字段、类型、数量和长度契约写入提示词，并在校验失败重试时回灌具体原因；生产 V2 仍只有简要 GDD 形状提示，模型可能重复犯同一结构错误。
+- 决策：生产 V2 只同步当前已经存在的 question/GDD 校验契约到 Provider system prompt，并在现有一次重试中明确列出本次阻断原因、要求逐项修复；不扩大校验范围、不新增门禁、不增加重试次数，也不把 `answerSource` 变成阻断条件。
+- 影响范围：`planning_session_v2.rs` 的 Provider prompt 与现有非法输出重试提示；`planning_policy_v2.rs` 校验逻辑、问询上限和持久化契约不变。
+- 验证方式：运行 Planning V2 定向 Rust 测试、`cargo fmt --check`、`git diff --check`，确认提示词构造和现有校验路径通过；不改变既有校验结果。
+- 关联文档：`docs/technical/【技术方案】策划会话RuntimeV2接入与旧链路退役-2026-09-03.md`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_session_v2.rs`。
+
+## 2026-09-04 PlanningSessionRuntime V2 提示词只保留形状和策略
+
+- 背景：把逐字段长度、数量、类型清单写入 system prompt 后，提示词与 JSON 骨架、Rust 校验器三重叠，模型也难以消化长清单；精确数字已由校验失败的一次重试回灌。
+- 决策：V2 system prompt 只保留问询/GDD 骨架、`game` 与 `decisions` / `prototypeValidationItems` 同级边界、状态枚举、首条 `initial-request` 约束，以及一行易错数量范围（options / keywords / pillars / coreLoop / mvpSystems / outOfScope / oneLiner）。不把逐字段长度、控制字符、label 去重等校验细则写入 prompt；校验范围、门禁和重试次数不变。
+- 影响范围：`planning_session_v2.rs` 的 Provider system prompt；`planning_policy_v2.rs` 校验逻辑与非法输出重试路径不变。
+- 验证方式：提示词含骨架与同级边界、不含逐字段长度清单；现有 Planning V2 定向测试、编码和 diff 检查通过。
+- 关联文档：`docs/technical/【技术方案】策划会话RuntimeV2接入与旧链路退役-2026-09-03.md`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_session_v2.rs`。
+
 ## 2026-09-03 AGC 登录 route event 使用 handler 已验证主体归属

 - 背景：登录请求进入时尚未拥有 `AuthenticatedAccessToken`，通用 tracking middleware 无法从响应 extensions 归属登录成功用户；将 AGC marker 直接写入按用户/业务日幂等的 `daily_login` 又会受到不同来源登录顺序影响。
@@ -1507,6 +1598,7 @@ CI 上 `background_agent_runtime_recovers_stale_running_before_pending_task` 在
 - 背景：主站与图片画板的泥点余额入口、余额明细和充值弹窗存在不同实现，旧充值口径仍展示六档泥点、首充双倍和会员购买 / 升级入口，容易让展示、商品资格与后端余额真相发生漂移。
 - 决策：主站与图片画板统一复用公共泥点资产入口，收起态展示总额与充值，展开态只展示不限时泥点、每日免费泥点和使用详情；充值中心 BFF 继续统一下发总额、三桶余额、限时到期时间、每日免费基础重置额及下次重置时间，前端不得自行相减推算，但会员周期限时泥点仅用于存量兼容和后端结算，当前版本不在前台展示。钱包明细每次展开都重新读取充值中心 BFF，打开期间实时总额变化时继续补读；图片画板的生成扣费或退款完成后同时刷新总额与充值中心拆分。充值中心读请求必须使用 revision 门禁，支付创建、到账确认等权威响应写入时使旧读失效，避免旧响应覆盖新的每日免费 / 不限时明细。默认泥点商品收敛为 `60 / ¥6`、`180 + 90 / ¥18`、`300 + 150 / ¥30`、`680 + 340 / ¥68` 四档，`60` 档无赠送，后三档按现有 `user_id + product_id` 独立资格规则首次购买加赠 `50%`。当前版本关闭会员购买页签、会员商品和购买 / 升级入口。
 - 2026-07-17 追加：主站、图片画板与 AI 游戏创作独立 App 的泥点账单统一复用 `packages/shared/src/components/PlatformProfileWalletLedgerModal`。共享组件只依赖 `ProfileWalletLedgerResponse`，承接来源 label、金额正负号、UTC 日期、余额兜底和 loading / empty / error 展示；`/api/profile/wallet-ledger` 请求、鉴权、打开状态与重试生命周期继续由各宿主持有，不把账户事实或后端副作用下沉到共享 UI。
+- 2026-09-07 追加：资产扣费在既有钱包流水 metadata 中记录服务端确定的 `assetKind`，`GET /api/profile/wallet-ledger` 只把白名单类型映射为可选用户文案 `reason`，不暴露原始 metadata、资源 ID、任务 ID 或未知内部枚举。共享账单组件优先展示非空 `reason`；历史、未知和空 metadata 继续按 `sourceType` 回退为“资产操作消耗”，不得由客户端猜测业务类型。
 - 影响范围：`profile_recharge_product_config` 默认商品、充值中心 read model、共享前后端契约、主站与图片画板泥点资产入口、充值弹窗、后台充值商品默认值。
 - 验证方式：充值与统一入口定向前端测试、`npm run typecheck`、充值商品定向 Rust 测试、`cargo check -p spacetime-module -p spacetime-client -p api-server --manifest-path server-rs/Cargo.toml`、`npm run check:encoding`、`git diff --check`。
 - 关联文档：`docs/【项目基线】当前产品与工程约束-2026-05-15.md`、`docs/【后端架构】server-rs与SpacetimeDB数据契约-2026-05-15.md`。
@@ -7960,6 +8052,19 @@ CI 上 `background_agent_runtime_recovers_stale_running_before_pending_task` 在
 - 新建/恢复 ephemeral Codex thread 时，replay 使用 `contextWindowTokens`、`autoCompactTokenLimit`、本次 `maxOutputTokens` 与 4096 安全余量计算预算，从最新记录向前选择连续完整的 `user` / `assistant` / `tool` 行；超预算旧前缀被省略，单条记录不截断，当前 user request 始终保留。
 - 发生省略时在 prompt 开头加入普通 `system: Earlier conversation history was omitted due to context budget.` 提示；当前请求本身超过硬上下文预算则直接失败。该策略是 Direct 专用滑动窗口，不复用 Runtime Agent 的摘要、tail 或 session compaction 生命周期。

+## 2026-09-05 共享 CanvasWorld 统一超采样与资源页迁移
+
+- 背景：资源总览页曾在业务层重复实现 world 的渲染与尺寸逻辑，需与网站 / Tauri 共用的 `@genarrative/image-canvas-react` 统一。
+- 决策：`CanvasWorld` 的公开契约为逻辑 `viewport`，最终视觉比例由 `viewport.scale` 定义。渲染细节由共享包封装，调用方不得自行换算。所有调用方继续使用共享默认正方形 `CANVAS_WORLD_SIZE = 12000`，不引入 `worldWidth/worldHeight` 等矩形 API。资源页 `navigationBounds` 只保留布局、fit、依赖线 geometry 和 data 属性用途，不再驱动 world DOM 尺寸。非缩放描边只应用于资源依赖关系线等几何 overlay，静态卡片图标不继承统一 SVG 描边规则；位图维持浏览器默认插值，不全局启用 `pixelated`。
+- 影响范围：资源总览迁移为直接渲染共享 `CanvasWorld`，卡片控件通过共享 inverse-scale CSS 变量保持屏幕级尺寸；Asset Canvas、UI Editor 和依赖线继续消费相同 viewport 坐标与事件换算，不改变业务状态或持久化合同。
+- 验证方式：调用方测试以预期逻辑 `{ x, y, scale }` 调用公开 helper `canvasViewportToWorldTransform`，再与实际 world 的 `style.transform` 比较；不手写渲染换算，不以缩放按钮文案替代 viewport 断言。运行共享包与 AGC 定向类型 / 测试、资源页集成测试、`npm run check:encoding` 和 `git diff --check`，覆盖 SVG 描边、拖拽坐标、关系线端点和默认 world 尺寸。
+
+## 2026-09-07 DirectProject 用户消息由 AGC 预写并过滤 Codex 回显
+
+- `.agent/conversations/project.jsonl` 中的 DirectProject 用户消息由 AGC 在 `turn/start` 前以 `direct-codex:{clientTurnId}:user` 幂等追加；写入失败时禁止发起 Codex turn，失败或中断也保留该 user item。
+- Codex app-server 回显的 `userMessage` / `role=user` item 不是第二个历史来源。AGC 只处理其观察和关联，不再把该 echo 追加到项目历史；Codex 的 assistant、tool 和其它有效 response item 仍按现有 append-only 规则落盘。
+- 本地 AGC user-item 写入必须使用允许 user item 的内部入口，Codex raw item 写入使用过滤入口，避免“过滤回显”反过来阻断预写。相同 `clientTurnId` 只能复用相同规范化 prompt，内容冲突必须失败关闭。
+
 ## 2026-08-31 AGC 错误报告与诊断上传

 - AGC 采用 IDEA 风格的当前进程错误池：按 fingerprint 合并 React / window / Promise / Tauri / Agent 错误，重启后不恢复，不使用 run 或 run_id。
@@ -7983,6 +8088,37 @@ CI 上 `background_agent_runtime_recovers_stale_running_before_pending_task` 在
 - 生成文件名保留可读清洗前缀，并追加 asset ID 的 SHA-256 摘要前缀以避免不同 ID 碰撞；不迁移既有旧路径，调用方需在采用新命名后使用新返回路径。
 - Radial90 的前端预览与 Rust 导出统一使用角点映射和顺时针起始角规则，顺时针填充从角点前一条边开始，避免两端渲染偏移。

+## 2026-09-03 策划会话 Runtime V2 P1 内核落地
+
+- 新增 `PlanningSessionRuntime V2` 内核入口：`start_planning_session_v2`、`continue_planning_session_v2`、`hydrate_planning_session_v2`。P1 只负责单 Agent 会话生命周期、Provider 流式/普通调用、消息持久化、回合幂等、单项目单活跃回合、耗时和失败恢复，不接入 GDD 解析、审批或旧 Supervisor。
+- V2 会话快照落在 `.agent/planning-v2/session.json`，完整消息落在 `.agent/planning-v2/conversation.jsonl`。同一 `clientTurnId` 已有成功 assistant 记录时直接重放；若只有 error 记录则允许沿用同一用户意图重试，不重复追加用户消息。进程退出后 hydrate 发现 `planning` 会投影为 `provider_failed/RECOVERY_REQUIRED`，不伪造成功或自动重试。
+- Provider 调用复用现有 `platform-llm` 的 API-kind、流式解析、超时和重试配置；当前策略快照固定 `mode=gdd`、`questionLimit=8`、`tools=[]`、`skills=[]`。GDD 业务规则留给 P2，生产 UI 接入留给 P3。
+
+## 2026-09-03 策划会话 Runtime V2 P2 产物闭环
+
+- V2 新增 `GddPlanningPolicy`：Provider 输出只接受合法 question 或完整 GDD JSON；question 在 `questionCount < questionLimit` 时保存并展示，第 8 个问题仍可展示，第 8 个之后再次返回 question 时只允许一次内部强制出稿重试，额外 question 不落盘、不进入用户等待态。
+- V2 GDD 使用独立 `plan-gdd.v2`，只保留项目身份、版本、游戏内容、决定、原型验证项和指纹，不带旧 Supervisor/Run/delegation 字段。每个版本写入 `.agent/planning-v2/gdd.vN.json`，同步更新 V2 index 和 `game/fast_gdd.md`；旧版本不可覆盖。
+- 新增 `decide_planning_artifact_v2` 与 `plan-approval.v2`。批准、修改、退回均绑定当前 Session、artifact、version 和 fingerprint；修改/退回必须有意见，修改后 Session 回到 `revision_requested`，下一轮由同一 V2 Session 继续。`answerSource` 缺失或未知值回退，不成为单独阻断项。
+
+## 2026-09-03 策划会话 Runtime V2 P3 入口与 UI 接入开始
+
+- 正式 AGC“做方案”入口在 `planningStartMode` 下直接调用 `start_planning_session_v2`、`continue_planning_session_v2` 和 `decide_planning_artifact_v2`，不再为新策划回合创建 Supervisor root、child Run 或 delegation。
+- 前端以适配层复用现有聊天区、澄清输入卡、GDD 审批卡和阶段进度条；V2 hydrate 返回 `conversation` 消息，用于页面刷新和重启后恢复可见历史。
+- V2 会话使用独立 `planning-session-v2-stream` 事件，旧 Supervisor Runtime 轮询、专业 Agent 轮询和旧 Runtime 事件不会介入 V2 会话。
+- 没有 V2 authority 的项目仍按旧读取路径打开；旧链路封存、未完成旧会话强制失败和旧入口彻底关闭仍留在 P5。
+
+## 2026-09-05 策划会话 Runtime V2 P4 收口
+
+- Planning V2 的 P4 灰度与回归验收已通过人工校验：正常提问/回答/GDD/批准链路、GDD 修改后再次批准链路、Provider 失败恢复、非法输出失败边界、重启恢复、前端工作台展示以及编码/差异门禁均完成验证。
+- P4 收口不代表旧链路退役；旧 `project-supervisor-plan` / `project-planning` 源码和入口仍保留，旧活跃会话封存、迟到结果隔离、旧入口关闭和只读历史展示统一留在后续 P5。
+- P5 收缩为最小退役：旧 `project-supervisor-plan` caller 统一立即返回退役错误，不启动旧 Runtime/Provider；不扩展 V1 `PlanSessionV1` schema，不做旧数据迁移，旧文件继续保留只读，V2 只读取 `.agent/planning-v2`。
+
+## 2026-09-05 修正 Planning V2 流式交互契约
+
+- Planning V2 不要求把 Provider 的文本 stream delta 逐条投影为用户可见对话。V2 的用户交互是结构化工具调用结果：`plan_ask_question` 渲染澄清选项卡，`plan_submit_gdd` 渲染 GDD 输出和审批卡；中间纯文本不是用户对话内容。
+- `planning-session-v2-stream` 若继续存在，只能作为内部状态/兼容事件能力，不构成实时逐 delta 的功能契约；Provider 是否使用流式传输不影响 V2 的业务验收。
+- 文档措辞约束：凡出现“流式响应”“流式事件”或 `text_delta`，均须注明其属于 Provider adapter/Runtime 内部实现能力；不得将其描述为前端必须逐条接收的用户可见消息。V2 的唯一用户交互结果是 `plan_ask_question` 和 `plan_submit_gdd` 的结构化工具结果，Provider 完成前是否产生多个 delta 不参与验收。
+
 ## 2026-08-29 AGC 官方 LLM 代理与 Windows 私有路径修复
 ## 2026-08-29 AGC 官方 LLM 代理与 Windows 私有路径修复

@@ -8034,3 +8170,40 @@ CI 上 `background_agent_runtime_recovers_stale_running_before_pending_task` 在
 - 配置契约提升为 `game-creator-config.v2`：新模板默认 `stream=true`、受控搜索开启；无版本旧 DirectProject 配置仅在省略 `webSearchEnabled` 时把历史默认补为开启，旧配置显式 `false` 不覆盖，v2 显式 `false` 同样保留；Provider / Anthropic 未提供搜索覆盖时保持关闭。本地覆盖配置只补 schema 版本，不凭不完整 overlay 推断或写入 `agentMode` / 搜索布尔值；未知版本失败关闭。
 - 搜索结果始终是不可信外部输入，只可作为资料；工具 schema、参数、客户端权限、Agent 身份、系统规则和工具协议不得由网页内容修改。搜索结果与状态投影不携带 API Key、请求头、宿主绝对路径或 Provider 原始错误正文。
 - 验证锁定：`configuration`、`direct_tools_mcp`、`direct_tool_bridge`、`codex_app_server` 定向 Rust 测试，以及前端状态格式化 / AppSurface 测试；真实 Provider 登录态与真实公网搜索仍需单独现场 smoke。
+
+## 2026-09-08 策划 V1 链路源码整体退役（四不写）
+
+- 策划会话 Runtime V2 全量接管“做方案”入口后，旧 V1 链路（`project-supervisor-plan` 根 Run、`project-planning` 子 Agent、`plan.submit_gdd` 工具、Fast GDD 审批门禁与恢复车道）按四不写原则整体删除源码，不保留兼容实现、墓碑注释或防御性测试。
+- 删除范围：`runtime_protocol` 六个 V1 模块与四条 V1 提示词、prompt manifest planning 目录与生成常量、`capabilities.planning` 配置开关、CLI `--swarm-chat --plan` 与 `--plan-gdd-status/--plan-gdd-decide`、provider_retry 的 planning session binding、provider_action_batch 的 V1 提交批次校验、main_loop/pending_recovery/recovery_scan/acceptance_graph 的 plan 根特判、agent_db 三条 V1 专用持久车道（`agent.runtime.plan.provider_usage`、`agent.runtime.plan.gdd_decided`、`agent.runtime.plan_submit_gdd.committed`）及预留配额、前端旧 V1 读模型、`scripts/agent-swarm-test-chat.mjs --plan` 与 `test:plan*` 脚本。
+- 保留项：V2 与 V1 共用的 GDD 数据模型收敛到 `runtime_protocol/planning_gdd_model.rs`；`.agent/planning/` 旧文件不迁移、不删除，旧 `fast_gdd.md` 仍可只读打开；前端 `PROJECT_SUPERVISOR_PLAN_SOURCE` 字符串与 `GddApprovalCard.tsx`（`PlanGddSurface`）是 V2 现役的适配/展示面，不属于退役对象。
+- 旧 sidecar 中带已删字段（`clarification`、`continuation`、`requestId`、`turnId`、`pendingApproval` 等）的记录会因 `deny_unknown_fields` 拒绝反序列化，这是退役语义的一部分，不做迁移。
+- 测试基线说明：收尾时测试套件存在 25 个既有失败（mock LLM 时序敏感类，HEAD worktree 对照验证与本次无关），后续清理时不要误记到本次退役头上。
+## 2026-09-08 Planning V2 正常 run 优先的恢复旁路
+
+- 恢复只利用已经落盘的合法 question、GDD 和 approval receipt；不调用 Provider、不要求模型额外输出恢复字段、不设置复杂状态机或自动重试。
+- 正常 run 进行时不读取或写入其 Planning V2 文件，也不增加文件锁或等待；无活跃 run 时恢复只做一次非阻塞锁尝试，竞争即退出，交给既有轮询。
+- question 恢复为成功结果，approval 重放复用 receipt 原始 decisionId。
+
+## 2026-09-08 Planning V2 用户输入与异步投影身份
+
+- 问题回答携带被回答卡片的 questionId，在已有回合锁内核对 Session 和当前问题；自由文本回答同样绑定问题，已完成回合保留幂等重放。此身份匹配服务于用户提交，不增加恢复门禁或模型输出要求。
+- hydrate 结果（包括空结果）写入前端状态前同时核对请求序列和当前项目路径；过期结果直接丢弃，不重试、不阻塞正常 run。
+
+## 2026-09-09 项目写锁残留回收与启动诊断
+
+- 决策：`.agent/project.lock` 记录 `processStartedAt`；PID 存活时用启动身份区分“原持有者仍在”与“PID 被复用”，身份不一致才回收。旧锁无该字段时用“进程启动时间晚于锁 `createdAt` + 5 秒容差”推断，锁创建时间未知时不做该推断。空锁 / 坏锁（崩溃停在 `create_new` 与落盘之间）宽限期 30 秒，无法判定存活时保持 600 秒，mtime 不可读时按未知年龄不回收。活持有者始终不回收。
+- 决策：回收判据与删除基于同一次读到的锁文件快照——payload 只解析一次，删除前重新核对字节，只有内容仍是判定时的内容才 unlink；文件已消失或被替换时重试 `create_new`，不把并发回收当成错误。
+- 决策：启动诊断日志用 `StartupLogSlot`，优先用已生效的配置目录（含 `--config-dir`），否则退到平台配置根（Windows APPDATA、macOS Application Support、其它平台 `XDG_CONFIG_HOME` / `~/.config`），配置目录就绪后再切换；`startup.*.failed` 与 `show_startup_error_dialog` 必须可达，日志路径未知时也必须给出用户可见提示；Windows 启动失败弹系统消息框，其它平台写 stderr。
+- 边界：`agent-runner.lock` / `agent-runner.gui-owner.lock` 是 OS 独占句柄锁，进程退出即释放，残留文件不阻塞下次启动；不要把它们当成项目写锁的同类残留处理。
+- 边界：锁文件里的 PID 若超出平台进程号空间（Unix `pid_t` 是有符号 32 位、Windows 是 32 位，均恒大于 0），它不可能属于任何活进程，按“持有者不存在”直接回收，不再落回 600 秒保守分支。
+- 验证：`project_lock_recovery` 11 条与 `diagnostic_log` 7 条定向测试通过，真实二进制双实例复现“第二个实例写 `startup.runner.owner-lock.failed` 并弹出可见提示”。
+
+## 2026-09-10 Direct 写通道纳入统一项目锁等待窗口并补齐持锁方可诊断
+
+- 背景：Issue #318。`agc_write_file` 是用户直接触发、失败即整轮无法落盘的项目写入通道，却用零等待取锁，任何重叠都在 24-42ms 内被投影成“项目正在被其他写操作占用”；同一形状已在 2026-07-22 由 `file.write / file.patch / file.delete` 用有界等待修过，本项目技术方案的 2026-08-13 一节也已规定这类争用结果“统一投影为争用并进入既有有界等待”。现场取证还缺 `commandId / pid / createdAt / ownerIsSelf`，无法回答“谁在持锁”，加上 `create_new` 把 ACL 拒绝、delete-pending 和真实跨进程争用压成同一句话，排障被引向“残留锁”。
+- 决策：① Direct 写路径改用 `acquire_game_creator_agent_runtime_project_write_lock_with_wait`，与其它写入口同语义，同一轮并行写按同一把锁串行。①′ 这条等待是同步轮询（最多约 10 秒），handler 是 async，因此写路径经 `spawn_blocking` 走阻塞线程池：直接在 handler 里同步等待会占住 tokio worker，争用窗口内并行写多个文件时会波及共享同一 runtime 的只读端点与 UI 命令，破坏 Issue #318 现场“只读工具全部正常”的诊断特征。② 争用错误前缀逐字不变并追加持锁方身份；`create_new` 失败拆成可重试（进入有界等待）/ 权限拒绝（失败关闭，文案不含争用前缀）/ 其它三类，**重试性只看错误码**：Windows 的 `ACCESS_DENIED(5)` 与删除拆链窗口在错误码上不可区分，一律先按可重试处理，等满预算且目标仍不存在时才由 `exhausted_projection` 改判成权限拒绝（单次试探不改判）；`sharing violation(32)` 与 `lock violation(33)` 恒定归可重试。③ 等待预算耗尽时按 `project.write_lock.wait_exhausted` 记录持锁方快照、等待时长与 `projection=`（contention / permission_denied），Unix 上明确判定的权限拒绝按 `project.write_lock.permission_denied` 记录；这条日志与终态改判都只在真的等过（`max_attempts > 1`）时发生，hydrate 的单次试探既不写日志也不改判。④ 重试与否改由类型决定：`acquire_project_write_lock_failure` 返回 `ProjectWriteLockFailure::{Retryable, Terminal}`，有界等待按 `is_retryable()` 分流，`acquire_project_write_lock` 只是它的文案包装；`PROJECT_WRITE_LOCK_CONTENTION_PREFIX` 同时收口 `provider_recovery.rs` / `planning_session_v2.rs` / `direct_runtime.rs` 三处手写文案。⑤ 平台判据的每一环都要带平台：终态改判也曾只比 `ErrorKind`，而 errno 5 在 Windows 是 `ACCESS_DENIED`、在 Linux 是 `EIO`，CI 直接把它判成 `contention`；现由 `Retryable { platform, path, source }` 携带平台。
+- 为什么不按“目标是否存在”当场分类：目标被删除时目录项先消失、删除挂起随后才结束，`create_new` 会在这个拆链窗口里返回 `ACCESS_DENIED(5)` 而 `exists()` 已经报 false（本机 6 万次建锁 / 删锁竞争实测 396-538 例命中该组合）。按一次 metadata 观察判成权限拒绝，等待层会立刻失败关闭，等于把 Issue #318 的“毫秒级直接失败”换成更误导的 ACL 文案；这也是对 2026-08-13 已定口径“这些结果统一投影为争用并进入既有有界等待”的回归。
+- 复用既有实现：回收判据沿用 2026-09-09 的 `ProjectWriteLockSnapshot` + `project_write_lock_reclaim_decision` + 字节 CAS 删除，不新增第二套回收机制；本次只给快照补 `commandId` 与 `describe_holder()`，供错误文案和日志使用。
+- 不做什么：不放宽 `.agent/project.lock` 的项目级串行化语义，不引入可重入项目锁，不改“同一调用链禁止二次获取 `.agent/project.lock`”的既有约定，不改 AGC 多进程拓扑，不改 `pendingOperations` 语义，也不改“活持有者始终不回收”的既有判据。其它仍用零等待取锁的入口（`command.exec / project.verify / memory / conversation / task / checkpoint / 预览 / UI 编辑器 / 资源编辑器 / Tauri 命令`）不在本次范围。
+- 验证方式：`project_lock_recovery` 追加持锁方身份与权限拒绝两条；`direct_tool_bridge` 追加同进程重叠写等待、同轮并行写、有界等待不占 runtime worker（默认 `current_thread` runtime 加心跳任务，同步阻塞会立刻让心跳停摆）、ACL 拒绝不投影成争用四条；`project/write_lock` 追加“重试性只由错误码决定”与“终态改判三条件”两条平台无关用例（平台作参数传入，Linux CI 覆盖 Windows 分支）。Windows 本机定向结果：`project_write_lock` 18 条、`bridge_write_file` 4 条、`parent_wake` 16 条、`waits_across` 3 条全过；CI（`71e9ad313`）四个 job 全绿，其中 Native shell tests 的首轮失败正是第 ⑤ 条平台判据缺陷。
+- 关联文档：`docs/project-memory/shared-memory/pitfalls.md`、`docs/technical/【技术方案】AI游戏创作智能体App实施计划-2026-06-24.md`、Issue #318。
@@ -37,6 +37,8 @@

 ## 验证路由

+AGC 测试构造单 HTML 项目时，必须在初始化之前写入 HTML，避免自动建立 npm 工程；npm 预览和导出测试应提供 dist 产物。已有图片生成 pending/operation 属于持久化恢复合同，修改工具默认参数后仍须验证旧动作恢复不重复提交、不因默认值变化被误判为新意图。
+
 SpacetimeDB 任务统一先读取 `.codex/skills/genarrative-spacetimedb/SKILL.md`；该项目适配层按需调用已安装的官方 `spacetimedb` 插件 skill，插件提供通用 SDK/CLI/MCP 知识，项目 skill 负责 Genarrative 架构边界和验证门禁。

 按改动范围选择定向门禁，不以无关全量扫描代替契约验证：
@@ -22,14 +22,19 @@
 AI 游戏创作 / DirectProject / UI workflow：

 1. `docs/technical/【技术方案】AI游戏创作智能体App实施计划-2026-06-24.md`
-2. `docs/technical/【技术方案】DirectProject客户端Skill与MCP扩展导入方案-2026-08-31.md`
-3. `docs/prd/【AI游戏创作】项目开发工作台PRD-2026-07-20.md`
-4. `docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md`
-5. `docs/technical/【技术方案】DirectProject本轮附件路径映射-2026-08-31.md`
-6. `docs/technical/【技术方案】Direct回合行为审计账本-2026-08-31.md`
-7. `docs/technical/【技术方案】GameAgent资源自由画板与快速编辑-2026-08-20.md`
-8. `docs/【技术方案】UI工作流资源桥接与Runtime执行-2026-08-24.md`
-9. UI 编辑器、宿主壳和当前测试专题文档
+2. `docs/technical/【技术方案】策划会话RuntimeV2接入与旧链路退役-2026-09-03.md`
+3. `docs/technical/【技术方案】DirectProject客户端Skill与MCP扩展导入方案-2026-08-31.md`
+4. `docs/prd/【AI游戏创作】项目开发工作台PRD-2026-07-20.md`
+5. `docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md`（仅存量旧链路）
+2. `docs/technical/【技术方案】DirectProject Codex原始历史与异常恢复-2026-09-04.md`
+3. `docs/technical/【技术方案】DirectProject客户端Skill与MCP扩展导入方案-2026-08-31.md`
+4. `docs/prd/【AI游戏创作】项目开发工作台PRD-2026-07-20.md`
+5. `docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md`
+6. `docs/technical/【技术方案】DirectProject本轮附件路径映射-2026-08-31.md`
+7. `docs/technical/【技术方案】Direct回合行为审计账本-2026-08-31.md`
+8. `docs/technical/【技术方案】GameAgent资源自由画板与快速编辑-2026-08-20.md`
+9. `docs/【技术方案】UI工作流资源桥接与Runtime执行-2026-08-24.md`
+10. UI 编辑器、宿主壳和当前测试专题文档

 图片画布 / 媒体生成：

@@ -2,6 +2,50 @@

 > 当前口径：本文件保留可复用的排障经验；历史条目的旧路由、旧版本和已删除文档仅作根因背景，不得据此恢复退役入口。当前命令、路由和 schema 以代码与 `docs/README.md` 为准。

+## 2026-09-05 Planning V2 审批和续跑必须等过项目锁瞬时争用
+
+- **现象**：策划 V2 在 GDD 审批提交修改意见后提示 `项目正在被其他写操作占用：...\\.agent\\project.lock`，聊天区再出现 `项目总控 Agent 执行失败，请稍后重试`。
+- **原因**：V1 `decide_plan_gdd_at` / hydrate 已按完整或短窗口等待项目锁。V2 的审批、回合启动、策略落盘和 hydrate 直接 `acquire_project_write_lock`，与 GUI 重灌、刚结束的审批写盘或后台扫描撞车就立刻失败。修订后续跑走 `continue_planning_session_v2`，失败被前端写进总控错误位。这不是锁没释放，也不是 UAC。
+- **处理**：一次性用户意图（审批、回合启动、策略落盘、失败投影、GDD 认领）走完整等待窗口；V2 hydrate 走短窗口。前端 V2 hydrate 对锁争用保持上一份状态，不把瞬时占用画进审批卡。
+- **排查顺序**：先看错误是否点名 `project.lock` 且发生在提交修改意见或立刻续跑；不要当成总控 Runtime 或 Provider 失败。锁文件在失败后通常已被 Drop 删掉，现场缺文件不否定争用。
+- **验证**：Rust 定向覆盖 V2 审批、修订续跑和 hydrate 等过短暂占用的项目锁。
+
+## 2026-09-05 新建项目锁不要把继承 DACL 当成 UAC 事件
+
+- **现象**：策划 V2 在 GDD 审批提交修改意见时弹出权限窗口，目标是 `Documents\Genarrative GameAgent\gameagent-*\.agent\project.lock`，随后 `AGC ACL 提权修复未成功（exit code Some(1)）`。
+- **原因**：#211 把新建 sidecar 纳入私有 DACL 门禁。父目录已是当前用户独占且禁止继承时，刚 `create_new` 的锁文件仍会短暂带继承 ACE；生产路径把这类 DACL 不合格送进 `--repair-private-acl`。独占句柄还会妨碍本进程 `SetNamedSecurityInfoW`。提权再用 `Start-Process -ArgumentList` 数组，含空格路径被拆开，helper 参数个数不对并以 1 退出。这不是 V2 审批协议或 Provider 权限请求。
+- **处理**：本进程新建对象只在进程内收紧 DACL，不因继承 ACE 自动 UAC。项目锁先写入并释放独占句柄，再 harden，回读内容校验后返回；不再对这把新锁走 `prepare_for_read`。UAC 仍留给允许范围内的外人本对象；提权命令行改为一条已加引号的 ArgumentList。
+- **排查顺序**：先看错误是否点名 `project.lock` 且含 `禁止继承` / `exit code Some(1)`；不要当成策划 V2 或 Provider 鉴权问题。含空格的 `Genarrative GameAgent` 项目根是复现条件，不是业务失败。
+- **验证**：Windows 定向覆盖含空格项目根取锁、新锁已满足私有 DACL、Drop 删除，以及提权参数把带空格路径保留为一个 quoted token。
+
+## 2026-09-04 Planning V2 不可变 GDD 创建后不能当没提交
+
+- **现象**：`gdd.vN.json` 已 create-only 落盘，但 index / Markdown / conversation / session 任一步失败后，session 停在 `provider_failed` 且 `current_artifact_version` 仍指向旧版本。重试会用新 UUID/时间戳再写同一版本号，命中“已存在且内容不同”。
+- **处理**：把该文件当作提交点。恢复时只认领 session 指针的下一个连续版本并补投影，不要删文件，也不要重建 GDD 身份。hydrate 和同一回合重试都必须走这条认领路径。
+- **排查顺序**：先看 `.agent/planning-v2/gdd.vN.json` 是否已存在、再看 `session.json` 的 `currentArtifactVersion` 是否落后；不要为了重试去覆盖不可变文件。
+- **验证**：孤儿文件重试后仍是同一 `gddId`/vN，hydrate 能看到当前产物。
+
+## 2026-09-04 DeepSeek thinking 不能与 tool_choice=required 同时使用
+
+- **现象**：DeepSeek V4（默认 thinking）对 `tool_choice=required` 或指定函数返回 HTTP 400：`Thinking mode does not support this tool_choice`。
+- **处理**：策划 V2 协议工具固定 `tool_choice=auto`，由 Runtime 校验必须恰好调用 `plan_ask_question` 或 `plan_submit_gdd`。不要按模型名分支，也不要用 required 强行出稿。
+- **验证**：请求体含 `tools` 且 `tool_choice=auto`；无工具调用时走既有非法输出重试。
+## 2026-09-09 常用设置跨文件保存失败
+
+主配置与 local overlay 的单文件原子写入不能保证整体成功；覆盖层写入失败会留下混合配置。保存前先序列化全部变更，多文件保存保留原内容，错误时逆序恢复并报告回滚失败；单文件保持原写入路径，成功后不回读、不触发外部诊断。此回滚仅处理可捕获错误，不承诺进程崩溃下的事务恢复。
+
+## 2026-09-09 `npm run agc` 的 Ctrl+C 不能只依赖 shell 包装层与端口健康检查
+
+- **现象**：`npm run agc` 按 Ctrl+C 后终端回到提示符，但上个工作树的 `api-server.exe` / SpacetimeDB 仍在监听 `8082` / `8083` / `3101`；切到另一个 worktree 再启动 AGC 时，前端仍然连到上个工作树的后端，在改过数据库 / schema 的工作树上会串库。
+- **原因**：
+  1. Windows 下所有长驻服务都由 Node `shell: true` 经 `cmd.exe /d /s /c` 包装层启动，Ctrl+C 会先杀掉包装层（退出码 `0xC000013A`）。`scripts/dev.mjs` 的 `stopProcess` 见到直接子进程已退出就直接 `return`，`start-dev-stack.mjs` / `start-tauri-dev.mjs` 对已退出 PID 的 `taskkill /PID <pid> /T /F` 只会失败并返回 `stopped: false`，于是更深的 `cargo → api-server.exe` 没有任何人收。
+  2. 即使走到按根 PID 遍历进程树，遍历依赖快照里的父子链；中间层（包装层）先消失时链路断开，遍历只能拿到根 PID，深处的后端不可达。
+  3. 复用判据只看 `.app/dev-stack.json` 的 status 与 `/healthz`、`/readyz`、`/v1/ping`，从不校验端口上的进程属于哪个工作树；残留后端照样“健康”，因此被当成自己的后端复用。
+- **处理**：新增 `scripts/dev-windows-process.mjs`，同时提供按根 PID 遍历与按身份匹配（`server-rs/target/debug/api-server.exe` 绝对路径、SpacetimeDB `--data-dir`）两条独立清理路径。`dev.mjs` 在直接子进程已退出时也继续清理，并在退出时按身份兜底清扫本工作树后端（复用他人 standalone 时不清理）。`start-dev-stack.mjs` 在收到信号和 `finally` 各清扫一次本工作树 `api-server.exe`（仅限本次自己拉起后端的情况），复用前先校验端口监听进程归属，无法证明归属就不复用、改为启动自己的后端并允许端口漂移。
+- **排查顺序**：先看 `.app/dev-stack.json` 的 status 与实际监听端口是否一致，再用 `Get-CimInstance Win32_Process` 按本工作树 `server-rs\target\debug\api-server.exe` 路径与 SpacetimeDB `--data-dir` 核对残留进程；不要因为 `/healthz` 返回 200 就认定后端属于当前工作树。
+- **验证**：`node --check scripts/dev.mjs scripts/dev-windows-process.mjs apps/ai-game-creator-shell/scripts/start-dev-stack.mjs`；`npx vitest run scripts/dev-windows-process.test.ts apps/ai-game-creator-shell/tests/start-dev-stack.test.ts scripts/dev.test.ts`；真机确认 Ctrl+C 后没有匹配本工作树 `api-server.exe` 路径的残留进程。
+- **关联**：`scripts/dev.mjs`、`scripts/dev-windows-process.mjs`、`apps/ai-game-creator-shell/scripts/start-dev-stack.mjs`、`docs/【开发运维】本地开发验证与生产运维-2026-05-15.md`。
+
 ## 2026-09-02 Tauri 事件桥在浏览器预览中必须 fail-safe

 - **现象**：Vitest/jsdom 挂载 AGC 客户端时，错误报告通知调用 `@tauri-apps/api/event.listen`，因缺少 `window.__TAURI_INTERNALS__` 产生未处理拒绝；测试断言虽通过，CI 仍以 unhandled errors 失败。
@@ -4141,6 +4185,14 @@
 - 关联：`apps/ai-game-creator-shell/scripts/game-creator-config-wizard.mjs`、`apps/ai-game-creator-shell/scripts/agent-swarm-test-chat.mjs`、`apps/ai-game-creator-shell/scripts/check-config.mjs`、`apps/ai-game-creator-shell/tests/agentSwarmTestEntry.test.ts`。
 - 真实验收状态：外部 Provider 与画布 API 均可调用不等于全链路验收通过。2026-07-27 新起的独立轮次使用 `npm run agc:test:chat -- --timeout-minutes 75`，约 `59m50s` 后以退出码 `0` 完整 **PASS**：同一轮完成固定 `16` 个 manifest task exactly-once、七份基础产物、两张真实画布 PNG、当前 revision 静态检查、desktop / mobile `lane-defense-v1` playtest、唯一终态回复和安全清理；`turn.report` 的 busy / pending / running / confirmation / user-input / reconciliation 均为 `0`。此前失败轮、部分产物、单项接口成功和确定性结果仍不得与本轮拼接。

+## 仓库回退配置模板不能被读取通道私有化锁定
+
+- 现象：Windows 上 `apps/ai-game-creator-shell/game-creator.config.json` 莫名其妙被"加锁"（DACL 被剥成只剩一个陌生 SID，连 `Get-Acl` 都 unauthorized），开发 agent 和其他用户无法修改，cargo 也因 `include_str!` 读不到文件而不能编译；手动解锁后过一段时间又被锁。
+- 原因：无 AppHandle 的开发 CLI（`llm-status`、`agent-run`、`agc:test:chat` 等）经 `game_creator_config_paths()` 从 CWD / `current_exe` 向上回溯 8 级探测到 worktree 里的 git 跟踪模板后，读取走了为 AppData 私密凭据设计的私有通道 `open_project_private_regular_file` → `prepare_game_creator_private_path_for_read`；该函数名为 "for read"，在 Windows 上却无条件收紧目标 DACL 为"仅当前进程用户、禁止继承"。沙箱 agent 是其 checkout 文件的 owner，校验通过后被静默私有化，其他账号全部 Access Denied。
+- 处理：配置读取按路径归属分流——`read_game_creator_config_file` 只对位于 `game_creator_runtime_config_dir()`（AppData 托管目录）内的真实凭据走私有加固读取；仓库旁边的回退模板 / local 覆盖一律走 `open_project_snapshot_regular_file` 非变异快照通道，读取绝不修改 owner / DACL。这与 `open_project_private_regular_file` 注释中"非用户明确选择的文件用 snapshot 读"的既有原则一致。
+- 教训：任何名为"读前准备"的函数若附带权限收紧副作用，都必须按路径是否属于本进程托管范围设白名单；共享仓库文件、git 跟踪文件永远不在加固范围内。排查"文件莫名被锁"时优先查 DACL owner 是哪位 SID，再倒推哪个进程以该身份运行过。
+- 验证：`tests::configuration::fallback_template_read_stays_on_snapshot_channel_outside_runtime_dir` 与 `runtime_config_read_stays_on_private_channel_inside_runtime_dir` 锁定两条通道的分流；`node scripts/check-config.mjs` 通过。
+
 ## 项目总控空态和持久 Runtime 不能依赖同一份 Session 索引

 - 现象：新项目尚未发消息时右侧总控区域只剩整块空白；已有 `needs-reconciliation` Runtime 的项目重新打开后，也可能看不到失败状态卡。
@@ -4996,3 +5048,38 @@
 - 外层 `start-tauri-dev.mjs` 应在启动 Tauri 前完成配套开发服务准备，并统一收束自有服务进程树；不要让冷编译和数据库发布挤占 Tauri 的前端就绪等待。自动发布必须保留数据库，不能靠清库解决启动问题。
 - CLI 与 standalone 可能是两个独立软链接。必须同时核对 `spacetime --version` 和 `spacetimedb-standalone --version`，不能把 CLI 的版本记录当作宿主版本证明；PATH 中存在宿主时启动器检查两者一致。更换宿主前停机备份数据，按原目录启动，不通过清库处理版本错配。
 - Router 配置缺失不应只在首次请求时报错。API/All 启动必须先校验官方地址、固定模型、provisioning secret、管理员 Token 和凭据加密密钥；否则服务看似 healthy，但登录后的 provisioning/模型调用才延迟失败。
+
+## 共享画布框选需要识别 world 的真实后代命中
+
+- 现象：共享 `CanvasWorld` 在 world 外层增加 `.genarrative-image-canvas__world-content` 后，点击或拖拽空白画布时事件 `target` 是内层 div；框选逻辑若只检查外层 world 本身，就会只清除焦点而不创建选框。
+- 原因：viewport 上的 pointer 事件通过冒泡接收，`event.currentTarget` 是 viewport，空白区域的 `event.target` 可能是 world 的任意后代，不保证命中外层元素。
+- 处理：框选命中判断使用 `Element.closest('.genarrative-image-canvas__world')`，并保留 viewport 自身命中路径；回归测试通过真实 `CanvasWorld` DOM 的 `pointerdown` 冒泡覆盖内层 world content。
+- 验证：`src/components/image-editor/useImageCanvasStageInteractions.test.tsx` 覆盖内层 world content 命中，定向交互测试通过。
+- 关联：`packages/image-canvas-react/src/useImageCanvasStageInteractions.ts`、`packages/image-canvas-react/src/CanvasWorld.tsx`。
+
+## 跨平台“死进程 PID” fixture 必须落在 Unix 有符号 32 位范围内（2026-09-09）
+
+- 现象：`project_lock_recovery::project_write_lock_reclaims_dead_owner_pid` 在 Windows 本地通过，在 Linux CI 报“死进程残留锁未被回收，实际错误：项目正在被其他写操作占用”。
+- 原因：fixture 用 `0xFFFF_FFF0` 当死 PID；Unix 的 `pid_t` 是有符号 32 位，`i32::try_from` 直接失败，存活判定返回 `None`（无法判定）而不是 `Some(false)`，于是落回 600 秒保守分支，残留锁不再被回收。
+- 处理：实现层把“平台不可能分配出的进程号”（0 或超出平台 pid 宽度）判为持有者不存在并直接回收；fixture 改用 `i32::MAX as u64 - 1`，另加 `u64::MAX` 非法进程号用例。
+- 验证：WSL Ubuntu 上 `cargo test --bin genarrative-ai-game-creator-shell project_lock_recovery` 7 条全过；Windows 上把可表示性判据临时回退到 HEAD 后，只有 `project_write_lock_reclaims_unrepresentable_owner_pid` 失败，说明该用例确实覆盖这条分支；Linux CI 的原始失败记录覆盖越界 PID 分支。
+- 关联：`apps/ai-game-creator-shell/src-tauri/src/project/write_lock.rs`、`apps/ai-game-creator-shell/src-tauri/src/tests/project_lock_recovery.rs`。
+
+## 锁文件回收的判定与删除必须基于同一份快照（2026-09-09）
+
+- 现象：两个实例同时恢复同一个崩溃项目时，后判定的一方可能删掉另一方刚装上的活锁；`remove_file` 的 `NotFound` 还会被当成硬失败，直接报“清理失效项目写锁失败”。
+- 原因：`project_write_lock_can_be_reclaimed` 只是快照观察，调用方拿到 true 后无条件 unlink；helper 还分别重读 `createdAt` / `pid` / `processStartedAt`，并发替换会拼出“旧 inode 的死 PID + 新 inode 的启动身份”。
+- 处理：payload 只解析一次并连同字节一起快照；删除前重新核对字节，只有内容仍是判定时的内容才 unlink；文件已消失或被替换时返回 false 并重试 `create_new`，不报错。
+- 补充：`project_write_lock_file_modified_seconds` 读不到 mtime 时不要返回 `0`——纪元 0 会被算成极大年龄，把保守判定反转成“立刻回收”，甚至把活持有者当 PID 复用抢走；要用 `Option` 区分“mtime 未知”和“mtime 等于纪元 0”。
+- 关联：`apps/ai-game-creator-shell/src-tauri/src/project/write_lock.rs`。
+
+## 2026-09-10 Direct 写通道零等待取锁把毫秒级竞争放大成整轮阻断
+
+- **现象**：AGC 新建项目后第一轮 Direct 对话里，唯一的项目写入通道 `agc_write_file` 每次都返回 `项目正在被其他写操作占用：<项目根>\.agent\project.lock`；同一轮 15 次写入全部 `status=failed` 且 `durationMs` 只有 24-42ms，而只读工具（`agc_list_project_files`、`agc_list_registered_assets`、`client.session.info`）全部正常，整轮无法写入任何项目文件。
+- **原因**：`.agent/project.lock` 是 `create_new` 存在性锁，Direct 通道却调零等待的 `acquire_project_write_lock`，与 App 自身其它写通道（美术 lane、revision、conversation、预览等）撞车就直接判死；而 `file.write / file.patch / file.delete` 等入口走的是约 10 秒有界等待。**失败耗时本身就是判据**：几十毫秒说明这个入口根本没等，同等争用在其它通道会被等待窗口吸收。此外错误文案不带 `commandId / pid / createdAt / ownerIsSelf`，又把 ACL 拒绝、delete-pending 和真实跨进程争用压成同一句话，现场很容易被误判成“残留锁”。
+- **处理**：Direct 写路径改用统一的有界等待；`create_new` 失败按可重试 / 权限 / 其它分三类并给不同文案；争用错误与等待日志都带持锁方身份，`ownerIsSelf` 区分“自己人”和“别人”。
+- **补充：重试性不能由一次 metadata 观察决定**。Windows 上 `create_new` 在目标被删除的拆链窗口里会返回 `ACCESS_DENIED(5)`，而此刻 `exists()` 往往已经报 false——本机 6 万次建锁 / 删锁竞争实测 396-538 例命中“5 + 目标不可见”。用 `path.exists()` 当场判成权限拒绝，等待层会立刻失败关闭，把同一个问题换成更误导的 ACL 文案。正确形状是：重试性只看错误码（`ACCESS_DENIED(5)` / sharing violation(32) / lock violation(33) / 已存在都可重试），终态改判放到等满预算之后——真的等过、目标此刻仍不存在，才改判成权限拒绝。分类判据把平台作为参数传入，Linux CI 才能覆盖 Windows 分支（CI 没有 Windows runner，`#[cfg(windows)]` 用例在 CI 里一次都不跑）。**判据的每一环都要带平台**：只看 `ErrorKind` 的判据在 Linux 上会给出相反结论——errno 5 在 Windows 是 `ACCESS_DENIED`、在 Linux 是 `EIO`（`Uncategorized`）。所以“等满预算再改判成权限拒绝”这第二个判据也必须连同平台与原始错误码一起传，否则 Windows 侧的行为在 CI 上永远测不到（本批第一次推送就是 CI 抓到 `permission_denied` 被改判成 `contention`：判据只比了 `kind()`）。
+- **补充：同步有界等待不能直接跑在 async handler 里**。这条等待是 2 000 × 5ms 的同步轮询（最多约 10 秒），而 `handle_direct_tool_bridge` 是 async：直接在 handler 里等待会占住一个 tokio worker，争用窗口内同一轮并行写多个文件时会有多个 worker 被占，而 bridge 与只读端点、UI 命令共享同一个 runtime——于是“只读工具全部正常”这条现场诊断特征会在争用窗口内失效，把排障引向错误方向（本次现场正是靠它判断“写锁没释放”的）。做法是把整条写路径挪进 `tokio::task::spawn_blocking`（仓库既有模式），等待语义与错误文案都不变；用例用默认 `current_thread` runtime 加心跳任务锁住这一点：handler 一旦同步阻塞，同一 runtime 上的心跳就完全停摆。**这类“零等待改成有界等待”的改动都要同时问一句：调用方是不是 async，等待窗口会不会占住执行器。**
+- **排查顺序**：① 先看失败耗时——几十毫秒说明该入口没等，是等待窗口缺失，不是锁没释放。② 看错误里的 `ownerIsSelf`：`true` 指向同进程另一条写通道，`false` 指向外部进程；该字段只比 PID，PID 复用会把外人报成自己人，只当线索、不当判据（回收判据另有 `processStartedAt` 兜底）。③ **锁文件在失败后通常已被 Drop 删掉，现场缺文件不否定争用**；同理 `agc_list_registered_assets` 的 `pendingOperations: []` 只表示没有在跑的付费生成，与项目写锁无关，不构成“锁没有持有者”的证据。④ `.agent/.manifest.json.lock` 是 manifest 的持久 OS 文件锁（Windows 不共享写句柄 / Unix `flock`），0 字节长期存在是设计如此，不是残留锁，也不要用项目写锁的回收判据去处理它。⑤ 看到“项目写锁路径权限被拒绝”时注意它的含义：这是**等满等待窗口后**的终态改判（Windows 上真实 ACL 拒绝就走这条路），不是某一瞬间的 metadata 观察；反过来，`项目正在被其他写操作占用：…（持锁方身份不可读：锁文件此刻不存在…）` 是零等待入口无法区分拆链窗口与 ACL 拒绝时的并列表述，两者不要互相否定。
+- **验证**：Rust 定向覆盖同进程重叠写等待、同轮并行写、有界等待不占 runtime worker、活外部进程持锁带身份、权限拒绝不投影成争用，以及两条平台无关判据用例（重试性只由错误码决定、终态改判三条件）；`runtime_project_write_lock_waits_for_delete_pending_target` 继续覆盖带句柄的 delete-pending 必须等到成功。
+- **关联**：`apps/ai-game-creator-shell/src-tauri/src/agent/direct_tool_bridge.rs`、`apps/ai-game-creator-shell/src-tauri/src/project/write_lock.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/project_gates.rs`。
@@ -51,9 +51,11 @@ SpacetimeDB crate、SDK、CLI / standalone 与生成 bindings 按 `2.8.3` 对齐

 ## AGC DirectProject 与 UI workflow

+- 新 Web 游戏为 `game/` 下的 npm + Vite + Phaser 4.2.1 工程，使用包导入且允许其它依赖；npm 预览与导出只读取 dist，运行素材需纳入构建，已有单 HTML/Godot 不自动迁移。
+
 - 通用 Agent Rust 分层为 `agent-runtime-core`（catalog、执行生命周期、ToolHost/spawn/all-join/Provider 契约）、`agent-runtime-orchestration`（动态无环任务图、ready、依赖波次、返工下游闭包和受限自主扩图提案）与 `platform-agent` 游戏适配器；循环返工通过新 pass / epoch 表达，不在单张依赖图中建立回边。LLM 可经宿主结构化 function call 提出新增节点/边，编排层只生成经校验的新候选图，epoch 与持久化仍由宿主掌控。
 - DirectProject 始终连接客户端内置的 `agc_tools` STDIO MCP，并在启动时额外读取客户端扩展仓库中已启用的第三方 MCP 独立项。第三方 STDIO/HTTP 配置只写入本次隔离 `CODEX_HOME`，单项非 required，启停、重命名和内容指纹进入 app-server pool identity；完整 Plugin Runtime、hooks/apps 和单文件脚本手动指定入口仍关闭。Skill 正文与 references 由 Codex 原生按需读取；`agc_tools` 负责标准美术准备、已登记资源有界查询、视频 / 角色动画 / 音效 / BGM 的 create-or-derive、已登记图片去背景、desktop/mobile 浏览器试玩和受控 `agc_web_search`；付费资源调用仍由客户端绑定回合、幂等账本、请求上限和投影权威。
- DirectProject 的 Codex 原生文件、搜索、命令、图片查看和 Skill 仅在真实 `game/` cwd 与 `workspaceWrite(writableRoots=[game])` 内可用；原生命令网络保持关闭。多 Agent、Apps、插件、hooks、图片生成、Goals、Workspace Dependencies、Tool Suggestion 和原生浏览器/电脑控制保持关闭。app-server 使用隔离 `CODEX_HOME`，provider 凭据只由 AGC 客户端代理持有，不能进入模型上下文或 shell 环境。
+- DirectProject 的 Codex 原生文件、搜索、命令、图片查看和 Skill 仅在用户项目 cwd 与 `workspaceWrite(writableRoots=[project])` 内可用；原生命令允许联网以支持 npm 安装，npm 缓存位于项目内 `.npm-cache/`。多 Agent、Apps、插件、hooks、图片生成、Goals、Workspace Dependencies、Tool Suggestion 和原生浏览器/电脑控制保持关闭。app-server 使用隔离 `CODEX_HOME`，provider 凭据只由 AGC 客户端代理持有，不能进入模型上下文或 shell 环境。
 - `ui-prototype`（设计图片）与 UI 编辑器 `UI` JSON 是不同资源。白名单 `ui.workflow.run` 按页面执行 `prepare → recognize → status → finalize`，由 provider-backed 识别、合并和组件绑定持久化 State/revision，并把 `reference-ready → structure-ready → merge-ready → binding-ready → application-ready → completed` 投影到 manifest。Provider 缺失、请求失败、工具缺失、结果不匹配或仍有待审节点时保留真实阶段并返回 blocker，不得用 deterministic seed 伪造完成。
 - UI workflow 的资源桥接与 Runtime 边界以 `docs/【技术方案】UI工作流资源桥接与Runtime执行-2026-08-24.md` 和 AGC 实施计划的 2026-08-24 覆盖段为准；只生成图片、登记空 JSON 或进入普通图片画布都不构成 workflow 完成。

@@ -5,13 +5,18 @@
 - 后台 owner 在“AGC 模型”维护列表；每项包含稳定 `id`、必填 `alias`、服务端 `modelId`、`enabled`。默认项必须启用。标识唯一，别名唯一，列表最多 32 项。
 - 配置保存到私有 `agc_model_catalog` 单例表，使用 revision 乐观锁，重启及多 api-server 实例共享同一事实。缺少配置时使用初始目录，高质量对应 `gpt-6-astra`，快速对应 `gpt-5.6-luna`。
 - `GET/PUT /admin/api/agc-models` 仅 owner 可用，返回完整配置；PUT 携带上次读取的 revision，冲突拒绝覆盖。
- `GET /api/llm/models` 返回启用项的 `id/displayName` 和 `defaultModelId`，不返回实际模型名、Router 目录、凭据或能力原始数据。
+- `GET /api/llm/models` 返回启用项的 `id/displayName`、`defaultModelId` 和目录 `revision`，不返回实际模型名、Router 目录、凭据或能力原始数据。
+- 客户端缓存最近 `revision`，在项目切换 / 对话表面挂载 / 下拉展开 / 窗口聚焦时条件刷新：`revision` 未变化不更新界面，同一时刻只保留一个在途请求，刷新失败保留上一次有效目录与本地选择。发起对话前用同一份快照校验所选模型仍启用，已停用或删除则回退默认模型并提示。
 - AGC Responses 请求的 `model` 是稳定目录标识。服务端按当前目录映射实际模型名；未知、停用项拒绝，不回退其它模型。旧客户端无 AGC 标记时使用后台默认项。
- 输入框右下角选择模型，只显示别名；选择保存到客户端配置 `selectedModelId`，从下一次请求生效。加载失败或选项停用时禁用提交并允许刷新，不显示实际 ID 作为兜底文案。
+- 输入框右下角选择模型，只显示别名；选择保存到客户端配置 `selectedModelId` 与 `selectedModelIsDefault`（当前选择是否来自平台默认项），从下一次请求生效。加载失败或选项停用时禁用提交并允许刷新，不显示实际 ID 作为兜底文案。
+- `selectedModelIsDefault` 为真表示选择由平台默认项驱动（首次进入、默认项变化、所选模型失效回退），后台默认项变化时客户端跟随切换并提示；用户手动选择后置为假，不再被默认项变化覆盖。
+- 首页聊天框架的右下角同样提供模型选择入口（与项目对话右侧一致）。首页入口与项目对话共用同一份目录缓存、挂载即加载（失败时沿用上一次成功目录），选择仅影响后续创建/发送的轮次，不阻塞「开启创作」，因此模型目录不可用时仍可创建项目并使用后台默认项。
+- 项目右侧对话的模型选择器在对话进行中保持可交互：切换模型只写回客户端配置并作用于下一轮，当前回合不受影响；发送按钮仍由 `controlBusy` / `modelReady` 把关。
 - 设置页恢复到布局改版前的官方代理版本，不包含模型管理或模型选择，保留配置安全清理和官方代理锁定。

 ## 验收

 - 目录领域校验、未知/停用模型拒绝、客户端响应不包含实际模型名。
 - 后台鉴权、持久化 revision 冲突处理；客户端选择保存后重新读取，设置保存不覆盖选择。
+- 目录 `revision` 条件刷新与并发触发去重、发送前回退默认模型、刷新失败可恢复。
 - AGC/admin-web 类型检查与定向测试、编码检查、Rust 定向检查、schema 一致性与 diff 检查。
@@ -1,5 +1,27 @@
 # AI 游戏创作智能体 App 实施计划

+## 图片生成恢复与测试边界
+
+已有持久生成账本的 Provider 待执行动作恢复时，若动作省略了旧视觉 Agent 自动补齐的参数，只在 Agent、动作身份、生成种类和冻结提示词均匹配旧合同后补齐缺省参数；显式参数不得被覆盖。新请求继续按当前自由图片合同执行，不能重新引入固定视觉产物门禁。恢复复用原 operation 与幂等账本，不因默认值变化重复提交已受理请求。
+
+单 HTML 测试须在项目初始化前准备 HTML；npm 项目的预览与导出测试须准备构建目录。图片测试按现行数量和布局合同验证资源、透明度、引用和持久恢复，不继续要求固定四切片。
+
+本地 Provider smoke 在启动 Agent 前准备已有的 `game/index.html`，按 JSON Generator 的单 HTML 项目合同验证生成、资源引用与浏览器预览。Agent 子进程失败时，诊断必须包含退出码、终止信号及有长度上限的 stderr/stdout 尾部，避免编译 warning 淹没实际错误。定位此阶段失败时单独运行 `npm run ai-game-creator-shell:agent-run:smoke`。
+
+## 常用设置职责
+
+常用设置负责运行参数的读取、编辑和保存，配置读写独立于账号权限诊断。账号权限由登录会话与实际智能服务请求链路处理，设置面板只维护配置草稿与读写反馈。
+
+保存配置复用写入前读取的高优先级本地覆盖内容：常用设置同步覆盖文件中已有的对应配置项，并保留当前模型 ID 和默认模型标记；模型选择仅同步 `selectedModelId` 与 `selectedModelIsDefault`；无冲突时不写覆盖文件。所有内容先完成序列化，多文件写入前保存原始内容，任一写入失败时逆序恢复已变更文件，回滚失败须明确报告。各文件沿用现有原子写入，不提供断电或进程崩溃下的多文件事务保证。全部成功后直接返回规范化配置，不执行保存后回读或外部诊断；单文件保存保持原路径。
+
+## 2026-09-08 Web 游戏 npm 与 Phaser 4 产物合同
+
+新建 Web 游戏使用 npm 工程：默认 `game/package.json` 声明 Phaser 4.2.1 和 Vite 构建工具，源码使用 `import Phaser from 'phaser'`，`package-lock.json` 由 npm 维护。默认脚手架文件位于 `game/`，包含 `index.html`、`game.js`、`style.css`、`vite.config.js` 和 npm 配置/锁文件；已有根目录 npm 工程沿用原根，可按需求拆分模块并添加任意其它 npm 依赖，不设置包名白名单。客户端不手工分发 Phaser bundle，不用 import map 模拟 package 导入。
+
+Agent 在包含 `package.json` 的目录执行 `npm ci`（依赖变更使用 `npm install`）和 `npm run build`；默认可从工作区根执行 `npm --prefix game ci` 与 `npm --prefix game run build`。DirectProject 保持 workspace-write 目录边界并开放网络，以支持 npm 依赖解析和安装；凭据仍由客户端代理持有，不进入项目或原生命令环境。其它执行模式维持现有权限。新游戏完成后执行 `npm run build` 并用真实浏览器试玩；依赖安装与构建失败必须反馈真实错误，不能回退成未解析裸模块导入的静态页面。
+
+npm 游戏的可预览产物固定为对应 package 目录下的 `dist/index.html`，静态 smoke 校验构建入口及本地文件引用，实际可玩性由浏览器验证。预览服务与导出读取该构建目录，所有运行素材必须由构建纳入 dist；npm 预览不回退读取源码或项目素材目录，保证试玩与导出一致。源码投影包含 package、锁文件、配置和真实游戏源码，排除 `node_modules/`、`dist/`、控制文件与凭据；npm 试玩包将 dist 文件映射到 `game/` 并附带发布说明，不包含源码依赖安装目录。现有单 HTML 项目不自动迁移，Godot 项目保持原合同。旧 JSON Generator 仅接受已初始化的单 HTML 项目，npm 项目或新建请求在调用 LLM 前明确拒绝并引导使用 DirectProject，避免静态草案伪装为 npm 构建产物。本节覆盖下文仅适用于旧单 HTML 产物的 Canvas API、手写动画循环和禁止外部本地脚本要求。
+
 ## 2026-09-02 项目名称显示与自动提炼

 - `.agent/manifest.json` 的 `name` 仍是本地项目显示名唯一事实源；项目组页行尾更多菜单提供行内重命名，保存必须走 Tauri 受控命令、项目写锁、manifest 写锁与既有 ACL/权限校验。重命名只更新 manifest，不改变项目目录、`projectId`、项目类型、任务、资源、版本或远端同步状态；保存成功后当前项目上下文、窗口标题和最近项目检查结果必须回读新 manifest 并保持一致。
@@ -58,6 +80,10 @@ Runtime 确认卡与普通聊天确认卡必须共用“信息区 + 固定操作

 ## 2026-08-19 UI Editor 节点右键菜单

+## 2026-09-05 UI Editor 节点树快捷删除
+
+左侧 `UI Tree` 每个可删除节点行在右侧提供桌面端快捷删除按钮，眼睛与删除按钮组成固定宽度的右侧动作列；整棵树保留横向滚动，深层节点的缩进、完整名称和组件数随树内容一起滚动，不使用省略号截断。沿用右键菜单的页面根节点禁删规则。快捷删除与右键删除共用页面级 `requestDelete` 入口：叶子节点直接调用现有删除命令；包含后代节点时先打开模态确认，正文显示节点名称及将同时删除的后代节点数量，按钮为“取消 / 删除”。确认期间使用现有 `ThemedModal` 的模态行为，取消或完成后关闭弹窗。底层 `deleteNode` 命令继续保持无确认，以兼容键盘 `Delete` 及已有状态测试；锁定态下快捷按钮和右键删除均不可执行。
+
 ## 2026-08-20 UI Editor 最终预览互斥子节点

 最终预览中，选中一个 `Exclusive` 父节点时，它的子节点切换条必须在该父节点自身的预览坐标空间内、紧贴节点上方悬浮；不得固定在预览容器左上角，也不得另行按屏幕坐标换算。点击 tab 必须显式选中对应子节点，不能按通用“切换可见性”语义把当前分支隐藏。`Exclusive` 父节点首次加载且尚未发生可见性操作时，必须默认且仅显示第一个直接子节点；用户手动隐藏全部直接子节点后必须保持全部隐藏，不得再次回退显示第一个子节点；空容器不显示子节点。切换条始终按内容宽度展开并允许溢出节点边界，不设最大宽度或内部滚动区域。从 `Exclusive` 切回 `Stack` 时必须清除全部直接子节点因互斥选择产生的隐藏状态并立即显示所有子节点，后代节点自身的独立隐藏状态保持不变。切换条仅改变现有子节点可见性状态，不能触发参考图重读、视口重新适配或预览树的异步重建。
@@ -183,7 +209,7 @@ Supervisor 认领该回执后，由父 run 自己为每个原 delivery 逐一创

 - Windows AppData 安全迁移：首次创建客户端 AppData 时必须以进程 `TokenUser` SID 显式设置 owner，并写入当前用户私有 DACL，不能把可能为 Administrators 的 `TokenOwner` 当作用户身份。发现历史目录 owner 不属于当前 `TokenUser` 时，不在原目录上放宽权限，而是拒绝 reparse point / junction / symlink 后，将旧目录原子重命名到同级唯一 `.owner-mismatch-backup-*` 备份，再新建并验证当前用户 owner 与私有 DACL；迁移或备份失败必须失败关闭，不覆盖旧配置。
 - Windows 私有文件初始化：父目录已归当前 `TokenUser` 后，新建 `.agent/.manifest.json.lock`、`agent-runner.lock`、endpoint 临时文件、project-owner 诊断临时文件与 real-E2E 私有文件的 owner 仍可能采用 token 默认 owner `Administrators`。manifest 固定锁和 Runner 固定 stale lock 只有在 Windows 不共享独占句柄已取得、且句柄确认普通文件、非 reparse point、链接数为一时才允许初始化或修复为当前 `TokenUser`，随后必须再次复核句柄并按既有 owner/DACL 门禁验证；其它临时文件只允许在本进程 `create_new` 成功且仍持有同一独占句柄时初始化 `TokenUser` owner / DACL，再写入、原子安装并严格复核，初始化失败必须清理刚创建的文件。既有 durable endpoint / diagnostic 读取不得自动接管；活锁不得截断，只有 sharing / lock violation `32/33` 表示占用，access denied 等其它错误立即返回。父进程观察到 Runner 子进程退出后立即返回错误，不等待完整 30 秒 deadline。
- Windows ACL 提权边界：自定义 `--config-dir` 的启动前置检查必须把 `managed / user-selected` scope 一并传入提权子进程，不能依赖父进程内存中的配置目录覆盖；native picker 返回的文件或项目目录在同一进程登记短时授权，后续导入 / 项目操作只对登记路径（目录可覆盖其后代）允许 `user-selected` 自动提权，直接伪造 IPC 绝对路径不得获得该能力。项目文件列表 / 索引递归逐项拒绝 symlink 与 Windows reparse point，并在 metadata / read 前先完成 ACL 准备。
+- Windows ACL 提权边界：自定义 `--config-dir` 的启动前置检查必须把 `managed / user-selected` scope 一并传入提权子进程，不能依赖父进程内存中的配置目录覆盖；native picker 返回的文件或项目目录在同一进程登记短时授权，后续导入 / 项目操作只对登记路径（目录可覆盖其后代）允许 `user-selected` 自动提权，直接伪造 IPC 绝对路径不得获得该能力。项目文件列表 / 索引递归逐项拒绝 symlink 与 Windows reparse point，并在 metadata / read 前先完成 ACL 准备。本进程刚创建的普通文件或目录只在当前进程收紧 owner / 私有 DACL，不因继承 ACE 自动 UAC；UAC 只修复允许范围内、owner 不属于当前用户的已有对象。提权 `Start-Process -ArgumentList` 必须是一条按 Windows 命令行规则加引号的字符串，不能把带空格路径拆成多个 argv。
 - 启动恢复和续跑边界：本条取代上一条中“只有 accepted 才可恢复”的窄口径。若进程在 Supervisor 用户消息已持久、accepted 未持久之间崩溃，只读 preflight 可以把该 `preparing` 识别为可恢复，但不改写 task/conversation；真实 resume 持有 Agent 锁后必须先幂等补写 accepted，再提升为 `pending / queued`。用户消息或 accepted conversation 已落盘而辅助审计失败时，以 conversation 为公开真相继续入队，不留下“已接收但永不执行”的任务；根终态首次公开写入的瞬时失败必须在终态投影后用相同 message ID 重试。receipt / isolated-join 等带 parent 的 Supervisor continuation 不再另写 Session 终态，只保留单一后端公开事件；`runtime-task-*` 与 `runtime-public-status-*` 共享同 run 的不透明关联摘要，秒级时间戳下多个连续任务必须按实际 run 对应的 `user -> accepted -> terminal` 顺序交错展示。
 - ready-task 启动活性：`background_task.queued`、`autonomous_ready_task.scheduled`、Runner heartbeat 或执行锁已移交都不等于 child 已启动。实际持有执行权的 Runner 必须在释放项目写锁后同步写入 child 的 running task、`turn.started` 与 started journal，再把已启动 state 和 per-Agent 执行锁交给已确认开始轮询的独立 execution worker；同步启动或 worker 接管失败时，要在仍持有执行锁期间依次把 child 和 manifest Graph 节点明确落为 failed，再释放锁并让 parent 收到调度错误。`autonomous_ready_task.scheduled` 只作诊断审计，其写入失败不能阻断 durable child 启动；external client 只 wake Runner，不在客户端抢占执行。Supervisor 进度卡通过 durable `startedAt`（旧 Run 从完整 task journal 恢复，最新 task-record fallback 保持 0）显示真实持续时间，并以父 Run 与当前关联专业 Agent 的最大事件时间计算运行态活跃度：运行超过 5 分钟无新事件时显示“运行中 · 疑似停滞”和静默时长；等待用户、等待确认、Provider retry、视觉资产、进程会话、pausing 与 paused 不误报。父 Run terminal 后，持续时间冻结在父 Run 自身最后活动，不随 child 晚到收口事件增长。消息时间统一校验为 JavaScript 可表示的 Date；越界值显示“时间未知”且不写无效 `datetime`。实时回复只显示 response stream 自己的 `updatedAt`，缺失时同样显示“时间未知”，不能借用其它 Runtime 活动时间或随前端时钟漂移。该提示只提供可观测性，不改变 Runtime/manifest 正式状态。
 - ready-task 对账取消续跑：未知工具结果仍停在 `needs-reconciliation` 且禁止自动重放；人工核对后显式取消原 child，保留 cancel tombstone，旧 child 和旧父 Run 按真实终态收口。若随后创建同 Session、同 Supervisor source、同有效任务语义的 continuation，新完成合同只对同时具有历史 `failed / needs-reconciliation`、最终 `cancelled` 和 durable tombstone 的 ready-task，把当前 manifest 对应 failed 节点恢复为 pending，并由 scheduler 创建全新 child Run。manifest 的读取、failed 筛选、每任务一次的 child journal 索引、证据重验和写回必须位于同一项目写锁域；较新的无 child 根 Run 只有在 durable journal 精确表明为旧 failed Graph 在进入调度前即失败时才能跨过，scheduler 自身失败必须阻断借用更老 tombstone。普通失败、无 tombstone、不同 source/Session/任务语义或证据冲突均保持失败关闭；不得复活旧 pending action、补造 observation 或把取消任务标成 completed。
@@ -226,7 +252,7 @@ Supervisor 认领该回执后，由父 run 自己为每个原 delivery 逐一创

 - 模式升级：`agentMode` 扩为 `codex_app_server / codex_cli / provider`，新默认为 `codex_app_server`；V1.51 的一次性 `codex exec` 保留为显式兼容模式，HTTP Provider 保留为非 Responses 配置及故障回退模式。
 - 进程与节点：External Runner 按“有效 Agent LLM 凭据/Responses 路由 + `projectId/agentId/sessionId/runId`”隔离长期 `codex app-server --stdio`，即每个权威节点 run 直接持有自己的 Codex CLI 子进程与 ephemeral thread，每次完整权威请求映射 turn。同一节点 turn 串行，节点之间进程级隔离；单节点连接失败不得使其它节点同时失去终态。Codex thread 不写 durable recovery；节点完成、重启、retry、handoff 和 finalization 仍只认 AGC 账本。
- DirectProject replay：Codex thread 仍保持 `ephemeral=true`。`.agent/conversations/project.jsonl` 是聊天唯一、append-only 事实源；每个 GUI turn 在发起 app-server turn 前，先把渲染后的规范化 user prompt 以 `direct-codex:{clientTurnId}:user` 幂等追加，持久化失败则不发起 turn 并公开 failed；LLM 失败 / 中断时保留该 user 记录，重试同一 `clientTurnId` 只复用它。仅当 app-server 连接没有可用的项目 thread（通常是进程重启或 thread 被淘汰）时，AGC 才读取历史，按原顺序渲染为简单 `user:` / `assistant:` / `tool:` 行，再追加本次新 user request，发送给新建 thread；已有 thread 的普通消息仍只发送新 user。为避免持久增长的历史超过模型上下文，replay builder 使用全局 `contextWindowTokens`、`autoCompactTokenLimit`、本次 `maxOutputTokens` 和 4096 安全余量计算输入预算，从最新记录向前选择连续、完整的消息；超预算的旧前缀只在本次 prompt 中省略，不改写 JSONL、不写 summary/sidecar、不拆分单条记录。发生省略时在 prompt 开头加入普通 `system: Earlier conversation history was omitted due to context budget.` 行；当前 user request 始终保留，若其自身超过硬上下文预算则直接失败。这里的简单 role 前缀和普通 assistant partial（末尾 `unexpected interrupt happened here`）仍是产品合同：保持 prompt 形状稳定、避免 envelope breaking change，并让模型明确知道上次输出在断开处结束。app-server 意外中断时，已收到的 partial 文本按普通 `assistant` 消息追加；断开处理和下一次发送都可尝试写入，依赖普通 `messageId` 幂等。项目打开只读取历史，不因 user-only 记录自动重发；Direct 不提供 retry 入口。Runtime Agent 继续使用独立的 runtime/context 恢复链路，不读取 DirectProject 对话作为原生 thread history。
+- DirectProject replay：Codex thread 仍保持 `ephemeral=true`。`.agent/conversations/project.jsonl` 是聊天唯一、append-only 事实源；AGC 是 DirectProject 用户消息的唯一持久化来源：每个 GUI turn 在发起 app-server turn 前，先把渲染后的规范化 user prompt 以 `direct-codex:{clientTurnId}:user` 幂等追加，持久化失败则不发起 turn 并公开 failed；LLM 失败 / 中断时保留该 user 记录，重试同一 `clientTurnId` 只复用它。Codex 回显的 `userMessage` / `role=user` item 只用于事件观察和关联校验，不得再次追加到项目 JSONL，避免把服务端 echo 当作第二条用户消息；本地 user item 写入与 Codex echo 过滤必须区分来源，不能用同一个“忽略 user item”入口阻断 AGC 自己的预写。仅当 app-server 连接没有可用的项目 thread（通常是进程重启或 thread 被淘汰）时，AGC 才读取历史，按原顺序渲染为简单 `user:` / `assistant:` / `tool:` 行，再追加本次新 user request，发送给新建 thread；已有 thread 的普通消息仍只发送新 user。为避免持久增长的历史超过模型上下文，replay builder 使用全局 `contextWindowTokens`、`autoCompactTokenLimit`、本次 `maxOutputTokens` 和 4096 安全余量计算输入预算，从最新记录向前选择连续、完整的消息；超预算的旧前缀只在本次 prompt 中省略，不改写 JSONL、不写 summary/sidecar、不拆分单条记录。发生省略时在 prompt 开头加入普通 `system: Earlier conversation history was omitted due to context budget.` 行；当前 user request 始终保留，若其自身超过硬上下文预算则直接失败。这里的简单 role 前缀和普通 assistant partial（末尾 `unexpected interrupt happened here`）仍是产品合同：保持 prompt 形状稳定、避免 envelope breaking change，并让模型明确知道上次输出在断开处结束。app-server 意外中断时，已收到的 partial 文本按普通 `assistant` 消息追加；断开处理和下一次发送都可尝试写入，依赖普通 `messageId` 幂等。项目打开只读取历史，不因 user-only 记录自动重发；Direct 不提供 retry 入口。Runtime Agent 继续使用独立的 runtime/context 恢复链路，不读取 DirectProject 对话作为原生 thread history。
 - LLM 配置：`apiKind` 始终只接受 `openai_responses`；非空 Key 转换为 app-server model provider，base URL 生效，Key 仅走专用环境变量；空 Key 只桥接用户 Codex `auth.json`，不继承环境 `CODEX_API_KEY`。设置面板在 app-server 模式继续显示并保存 model、effort、stream、全局/逐 Agent Key 与路由配置；`openai_chat / anthropic` 明确提示切 `provider`，不得悄悄忽略。`stream=true` 接入 app-server 文本 delta；`webSearchEnabled=true` 只允许 DirectProject 经客户端审核的 `agc_web_search` 使用，不得启用 Codex 原生 webSearch 或任意网络。
 - 安全与取消：临时 cwd、隔离 `CODEX_HOME` 与 OS HOME、read-only、network off、never approval，并在启动前关闭 web/multi-agent/shell/browser/plugin/image 等原生能力；取消从 turn-start pending 阶段就跟踪且只 interrupt 当前 turn。已发送 turn 后连接断开或终态丢失进入 reconciliation，只关闭当前节点进程且不重放同一 request slot；明确 failed/interrupted 不按 transport 重试。
 - remote-control 认证边界：没有 ChatGPT `auth.json` 的 API Key / provider-proxy app-server 在启动时设置 Codex 内部环境变量 `CODEX_INTERNAL_APP_SERVER_REMOTE_CONTROL_DISABLED=1`，让 remote-control 以 `desired_state=Disabled` 启动，避免上游进入 1Hz 认证重试；不再依赖需要 ChatGPT 登录态的 `remoteControl/disable` RPC。只有实际桥接 ChatGPT 登录态的 AuthBridge 保持 remote-control 可用。API Key 子进程同时使用 `RUST_LOG=warn` 收敛剩余预期噪音，不伪造 `auth.json` 或静默继续。
@@ -234,6 +260,13 @@ Supervisor 认领该回执后，由父 run 自己为每个原 delivery 逐一创
 - 旧配置迁移：既有 AppData 若没有 `agentMode`，只有全局和逐 Agent 路由均为 `openai_responses` 时迁移到 `codex_app_server`；存在 `openai_chat / anthropic` 时显式保留 `provider`，避免打开项目自动恢复时把所有节点批量写成 `invalid-config`。用户确认端点支持 Responses 后，可在设置中显式切换并保留原 model/base URL/API Key。
 - 验收：fake JSON-RPC fixture、三态 UI/config、配置指纹、unknown-terminal 零重放、旧两种模式回归和显式 ignored 真实 smoke 全部通过后，才可视为模式切换完成。

+### 2026-09-03 AGC 客户端能力以 MCP 暴露
+
+- MCP 暴露是客户端能力层，不替换 `codex_app_server / codex_cli / provider` 或客户端对话。客户端对话入口继续驱动 Codex app-server；app-server 通过客户端随附的 stdio MCP 子进程调用审核后的客户端能力。客户端不再替 Codex 做业务语义门禁、意图判断和完成判定。
+- MCP 会话在客户端握手时绑定当前账号、项目和实例，工具参数不得携带 `projectPath`、Token、Cookie、objectKey 或内部 URL。仅暴露稳定业务白名单与 `resources/list/read`，所有文件、资源、画布、预览和 operation 副作用继续复用客户端权限、锁、计费、幂等账本、manifest/revision 与恢复机制。
+- 客户端对话继续写入现有 conversation projection；外部 Host 如需旁路保存返回文本，可显式调用 `conversation.record_codex_response`。客户端将有界、脱敏正文、SHA-256、安全摘要和状态追加到项目级 journal，UI 只展示记录，不从文本推断业务状态或触发副作用。
+- MCP 子进程只由当前客户端为绑定项目启动，并在该项目工作目录内运行；客户端回合结束或客户端退出后子进程随 Codex app-server 一并回收。账号和项目权限仍由客户端业务桥接层校验，未知副作用保持 `needs-reconciliation`，只能通过 operation 查询恢复。稳定验收覆盖客户端对话驱动的 MCP 工具调用、Skill 指导资源、跨项目/账号拒绝以及旧 Provider/Codex 回归。
+
 ### 2026-08-10 Supervisor 边做边聊与条件中断

 - 根 Project Supervisor 的运行中消息继续进入当前 `taskId / sessionId / runId`，先持久显示“正在判断、当前任务继续”，再由独立 LLM 生成非终态语义回复并给出 `interruptCurrentProvider`。过程回复不能调用终态 `respond_to_user`，不能把制作 Run、Goal 或 task 提前完成。
@@ -549,6 +582,7 @@ game-project/
 - 中间主视窗提供 `资源管理 / 运行` 切换。`code-prototype` 任务完成前运行入口保持视觉不可用，但仍可点击查看“当前无可运行版本”，不能使用会阻断说明交互的原生 `disabled` 或 `aria-disabled`；完成后才允许进入运行表现层。切回资源管理只修改前端展示态，不伪造后端预览暂停结果。
 - 资源管理从当前 `GameCreationAppManifest`（包含可选 `versions`）、合法 Agent 文本回执和已导入附件派生资源，固定按文档、项目版本、美术资源、音乐音效资源分区；未知任务产物不再兜底为版本，任务声明中的未登记音频也不冒充正式音频。`按依赖 / 按类型` 使用各自前端排列，dependency 模式额外绘制当前 manifest 与资源投影可证明的依赖关系。排列与图层都不写回 manifest，不能推断或伪造缺失依赖。
 - 资源卡支持点击聚焦、搜索和类型筛选。2026-07-28 起完成两套二维坐标与本地 CAS sidecar；2026-07-31 起 dependency 模式增加不持久化的原生 SVG 关系图层。2026-08-03 mentor 决定暂缓资源卡拖动，当前卡片不挂载 Pointer Down / Move / Up / Cancel 拖动入口，只允许自动布局和点击聚焦。聚焦态替换中央主视窗内容，保留左侧导航、右侧对话和底部 Agent 状态栏，退出后恢复搜索、布局模式、滚动位置与选中资源；不提供工具栏、工具侧边栏或可拖动标题栏。2026-08-10 起聚焦态以资源元数据、Rust 权威深度、同类型上下游 / 任务流和版本信息为首屏；美术图片与视频只保留卡内本体，不在详情重复放大。安全文档正文与按意图读取的音频控制位于元数据之后；美术编辑、音频编辑 / 替换、版本替换或运行模块仍不在本阶段。
+- `@genarrative/image-canvas-react` 的 `CanvasWorld` 接收逻辑 `viewport`，`viewport.scale` 表示最终视觉比例；渲染细节由共享包封装。调用方测试将预期逻辑 `{ x, y, scale }` 传入公开 helper `canvasViewportToWorldTransform`，再比较实际 world 的 `style.transform`；不自行换算渲染值，不以缩放按钮文案替代 viewport 断言。world 继续使用共享默认正方形 `CANVAS_WORLD_SIZE = 12000`，不新增矩形尺寸 API；资源页的 `navigationBounds` 只用于布局、fit、关系线 geometry 和数据属性，不能再设置 world DOM 宽高。非缩放描边只应用于资源依赖关系线等几何 overlay，Lucide 等静态卡片图标保持自身正常缩放，避免被统一 SVG 规则压窄；普通位图不强制 `pixelated` 插值。依赖线、卡片拖拽、平移和滚轮锚点继续使用同一逻辑 viewport 坐标。

 #### 资源管理串行改造：本体卡、分区缩放与依赖聚类

@@ -870,7 +904,7 @@ game-project/
 - 聊天输入 `/status` 会读取 `.agent/manifest.json` 并在聊天里汇总项目目录、任务状态、资产数量、预览状态和最近命令，不向普通用户暴露任务或文件面板。
 - 聊天输入 `/files` 会通过 `file.list` 只读列出本地项目内的文件摘要；主窗口最近项目文件可一键读取，也可一键填入 `/read` 或 `/asset-register` 草稿，但资产登记仍必须走聊天确认；`/checkpoints` 复用 `file.list` / `file.read` 只读列出最近 checkpoint id、文件数、大小和可复制的 `/diff` / `/restore` 命令，主窗口最近 checkpoint 列表也可填入对应草稿；普通用户仍不暴露文件读写面板。
 - 聊天输入 `/assets` 会读取 `.agent/manifest.json` 并在聊天里列出本地项目资产路径、类型和来源，资产列表消息和主窗口最近项目资产入口都可一键填入对应资产的 `/read` 草稿；聊天输入 `/art` 只使用当前已加载 manifest 盘点美术素材，并提供首版美术生成或读取美术清单草稿，不直接读取文件、不触发平台生成或画板同步；聊天输入 `/audio` 只使用当前已加载 manifest 盘点音频素材，并提供登记音效或读取音频清单草稿，不直接读取文件、不触发资产写入；`/asset-register 路径 [kind] [mediaType]` 可确认后登记项目内已有资产；主窗口音效快捷入口只填入 `/asset-register assets/audio/sfx.wav audio audio/wav` 草稿，不直接写 manifest；普通用户仍不暴露资产面板。
- 聊天输入 `/read 本地相对路径` 会通过 `file.read` 只读返回项目内文本文件内容并在聊天中截断长文本；普通用户仍不暴露文件写入或删除能力。
+- 聊天输入 `/read 本地相对路径` 会通过 `file.read` 只读返回项目内文本文件内容并在聊天中截断长文本；聊天回执中的正文必须包装为安全的 `<pre><code>` 代码块，保留源码字面量但不得执行 HTML；普通用户仍不暴露文件写入或删除能力。
 - 主窗口常用生成产物入口只把 `game/index.html`、`game/game_design.md`、`game/balance.json`、`assets/manifest.art.json`、`assets/manifest.audio.json` 和 `exports/README.md` 的 `/read` 草稿填入聊天输入框；聊天输入 `/artifacts` 只列出这组固定读取命令并提供首个 `/read` 草稿，聊天输入 `/run-artifacts` 只列出最近 run trace 里的产物读取命令并提供首个 `/read` 草稿，聊天输入 `/run-files` 只列出 `.agent/output.jsonl`、`.agent/activity.jsonl` 和 `.agent/context.bundle.json` 的读取命令并提供首个 `/read` 草稿；读取仍由聊天侧 `file.read` 权限流执行。
 - 聊天输入 `/logs` 只列出 `.agent/logs/command.log`、`.agent/logs/preview.log` 和 `.agent/logs/agent.log` 对应的 `/read ...` 草稿 / 命令，并提供首个 `/read` 草稿；该命令不直接读取日志，不新增普通用户日志面板，实际读取仍由聊天侧 `file.read` 权限流执行。
 - 聊天输入 `/tasks` 会读取 `.agent/manifest.json` 并在聊天里列出专业组、角色、任务状态、产物交接和下一步可执行任务；普通用户仍不暴露任务面板。
@@ -1063,7 +1097,7 @@ game-project/
 - 内部 owner 验证只接受 GUI / CLI 完整 16 任务 DAG 中 `agent-ready-task-scheduler` 启动的确定性直接 child、当前活跃根和完整 project/source/profile/Agent/run/parent/root/binding 身份。错误 source、delegated run、历史或终态根、非当前活跃根、跨 Agent/run 凭证均失败关闭；再次 mutation 使旧凭证失效，相同身份恢复可按当前事实确定性重验。本阶段不扩到后置 `publish-package`。`code-prototype` 与 `preview-readiness` 继续执行真实 `game.static_smoke`，`preview-playtest` 继续独立执行浏览器验收；任何 owner 文件凭证都不能替代可玩证据。
 - `design-foundation` 的 2026-07-26 职责隔离继续有效：项目文件仍只允许 `memory/project.md`、`game/game_design.md` 和配置 Key 时的固定 `assets/ui-prototype.png`，禁止修改 `game/index.html`、调用 smoke / preview / process 或恢复整项目。未配置 External Editor API Key 时 `art-director` 保持只读协调；配置 Key 时它是条件 Canvas owner，必须生成并登记 `assets/art-spec.png`，成功 `canvas.asset_generate` 为本人当前 revision 形成普通验证凭证，不能被只读分类吞掉。配置 Key 时 UI 原型、透明图集、Canvas 登记和视觉门仍按既有合同执行，内部 owner 文件验证不替代图片证据。
 - `canvas.asset_generate.replaceExisting` 默认并必须保持 `false`；只有静态专业 Agent 的 `delegated-*` 唯一 repair run 才能申请 `true`。Runtime 要求当前 delivery 带 `repairOfDelegationId`，原 delivery 已被同一父 Agent / 父 run 认领，原始与返工合同的目标 Agent 和精确 `expectedArtifacts` 路径一致；普通 run、未声明路径、错误 Agent、未认领原交付或缺失原图都失败关闭。图片生成仍服从 `art-director` / `design-foundation` / `art-asset-plan` 的固定输出路径、比例、尺寸、kind 和 label，禁止先删除正式图片；请求前记录旧文件 SHA-256，外部生成返回后在项目写锁内复核，旧图在网络请求期间变化即拒绝覆盖。授权替换先写私有临时文件，再以备份 / rename 切换；落盘或 manifest 登记失败时恢复旧图，不把新旧文件并存状态当作成功。
- 在既有 16-task manifest 内固定正式视觉 DAG，不新增平行任务系统：`art-director` 用当前调用模式的图片生成 `kind=spec` 生成 `assets/art-spec.png` 并登记为 `assetKind=icon-spec`；`design-foundation` 使用该规范图的稳定资源 ID 作为视觉规范参考，用同模式图片生成 `kind=ui-design` 生成 `assets/ui-prototype.png`；`art-asset-plan` 以同一 resource ID 调用同模式图标 spritesheet 生成，产出透明 `assets/art-spritesheet.png`。普通模式使用内部 `/api/editor/*`，standalone/高级模式使用对应 `/api/external/v1/*`；业务请求、依赖和验收完全一致。规范图缺失、未登记或缺少稳定资源 ID 时，下游任务不得退回普通生图。图集 warning、透明像素与切片门禁保持不变。
+- 视觉 Agent 只负责指导 Codex 选择合适的图片/编辑/图集工具并提供项目上下文，不再固定图片数量、文件槽位、素材类别或 spritesheet 布局；请求可按玩法需要生成单图、多图或任意切片布局。普通模式使用内部 `/api/editor/*`，standalone/高级模式使用对应 `/api/external/v1/*`；权限、计费、幂等、资源登记和安全校验保持不变。
 - 旧项目已有同路径派生图但缺少上述 provenance 时，一律标记为 legacy，不得只因文件、kind 或通用视觉检查存在就完成。原位替换仍走显式 repair：`design-foundation` 与 `art-asset-plan` 先在同一 Supervisor 批次分别建立 owner 精确原合同并交付 `needs-repair`，父 run 认领后再在同一批次分别发起各自唯一 repair；两个 repair 合称一个显式视觉返工阶段。`art-director` 不得跨 owner 声明或替换 UI / spritesheet，Runtime 在委派落盘前就拒绝这类合同，不再等到生图阶段才失败。
 - 2026-07-27 新起的“16 任务正式产物 + 两张真实画布图片 + current revision 静态 / 双视口浏览器 / PNG 证据 + 受限 repair 替换”独立外部 Provider 验收，使用 `npm run agc:test:chat -- --timeout-minutes 75`，约 `59m50s` 后以退出码 `0` 完整 **PASS**。同一轮真实生成并登记 `assets/ui-prototype.png`（`2829418` bytes）与 `assets/art-spritesheet.png`（`1361906` bytes），固定 `16` 个 manifest task 均为当前父 Run 下唯一 logical run、一次 started、一次 completed、零 failed / cancelled 和一次 manifest projection；七份基础正式产物、两张 PNG、当前 revision 的 `game.static_smoke`、desktop / mobile `lane-defense-v1` playtest、浏览器报告与截图全部通过。`turn.report=settled` 且唯一 assistant，busy / pending / running / confirmation / user-input / reconciliation 均为 `0`；隔离 Runner、一次性项目和隔离 AppData 已自动清理。此前失败轮继续独立保留，不与本轮拼接；未来合同变化仍须新起完整轮次复验。
 - 2026-07-27 补充 tool-plan 成功响应交接的内容边界：Provider 的自然语言计划叙述，以及结构化 arguments 中 `body / code / content / css / html / newText / oldText / patch / script / text` 等源码内容字段，只检查真实密钥 token 形状、凭据头标记和不安全控制字符；仅仅提及 `.env` 或 `game-creator.config` 不能阻断已经计费的安全响应。结构化输入中的敏感 JSON key、非内容字段中的配置痕迹或绝对路径、真实 token、容量、thinking、身份、顺序和账本完整性门禁仍失败关闭。成功 handoff 失败进入 reconciliation 时，Runtime 额外只持久化受控 `failureKind`、脱敏错误 SHA-256 和字符数，不保存 Provider 正文、function arguments、密钥或绝对路径。定向回归覆盖叙述/源码字段放行、`.env.local` 路径和真实 token 拒绝、全部 tool-plan handoff 回归及诊断零正文。
@@ -1265,7 +1299,6 @@ game-project/
 本文早期关于“DirectProject 关闭通用 shell、原生网络和主动工具”的描述属于迁移前基线，现由以下覆盖规则取代：DirectProject 仅在真实 `game/` cwd 与 `workspaceWrite(writableRoots=[game])` 内恢复 Codex 原生文件/搜索/命令、图片查看和 Skill；其余 ToolHost/DirectHome 合同不变。客户端审核的 `agc_tools` MCP 继续承担平台美术、资源登记、去背景、浏览器试玩和受控搜索，并保留项目锁、幂等账本、下载校验、恢复与投影权威。

 DirectProject 使用 `approvalPolicy=never`，避免每次原生调用再经过泛化 ToolHost 包装；原生命令网络保持关闭，联网资料继续走受控 `agc_web_search`。多 Agent、Apps、完整插件 Runtime、hooks、Goals、Workspace Dependencies、Tool Suggestion 和原生浏览器/电脑控制仍关闭，避免绕过 AGC durable delegation、浏览器证据和副作用审计；图片生成通过客户端审核的 `agc_tools.agc_generate_image` 暴露普通单图、角色图、视觉规范图和 UI 设计图，完整游戏美术包继续使用 `agc_tools.taonier_prepare_game_art`，两者都复用同一客户端登录态、幂等账本、下载校验和 manifest/revision 投影，不开放 Codex 原生 image tool。app-server 使用隔离 `CODEX_HOME`：内置 `agc_tools` 由客户端启动参数注入，用户在客户端扩展列表启用的独立第三方 MCP 以原生配置写入该次隔离 home；全局 Codex MCP、禁用项、Plugin hooks/apps 和其它插件能力不进入 DirectProject。第三方项固定非 required，配置或启动失败只记录该项，不替换 `agc_tools`；provider session token、工具桥地址和受控搜索标记不得通过第三方 MCP 的环境转发字段泄露。配置了 AGC LLM Key 或可解析的 `OPENAI_API_KEY` 登录态时，真实 provider 凭据只由 AGC 本地 provider proxy 持有，Codex 仅使用连接级随机代理令牌；无法安全代理的 OAuth `auth.json` 继续关闭 native shell/unified exec。`agc_tools` 的平台授权由 AGC 客户端当前登录会话和受控后端完成，普通客户端不得把 DirectProject 请求改成外部 API Key 请求；401/403 只投影为客户端登录或权限异常，不向用户索要凭据或暴露内部 URL。shell 子进程采用 `shell_environment_policy` core 继承及 secret/proxy/bridge 排除，provider key 和桥接凭据不得进入命令环境。系统提示词不再预注入项目源码快照或 Skill 正文，Codex 按需读取当前 cwd 文件。
-
 ## 2026-08-24 AGC UI 原型桥接与自主 UI workflow

 - 2026-08-24 起，`ui-prototype` 与 UI 编辑器的 `UI` JSON 资源明确分离。设计图生成后必须由白名单 `ui.workflow.run` 按页面执行 `prepare → recognize → status → finalize`：为每个功能页面创建并关联 `UI` JSON，载入页面设计图和已登记图片/图标/字体，调用 UI Editor 的 provider-backed 结构识别、多树合并与分批组件绑定，持久化 State/revision，写入 `game/` 应用标记，并把 `reference-ready → structure-ready → merge-ready → binding-ready → application-ready → completed` 各阶段的 `generationKind` 和 manifest revision 投影给客户端。Provider 未配置、请求失败、工具调用缺失、结果不匹配、未知字体引用、未产出可渲染组件或仍有待审节点时保留最近真实阶段并返回 blocker，不得使用 deterministic seed 冒充完成。工作台点击 `ui-prototype` 时通过 `ensure_ui_design_resource_for_prototype` 幂等补齐关联资源；工作流完成后自动打开首个页面的 UI 编辑器 `visual-binding` 最终阶段，交给用户检查和手动调整。UI 编辑器独立的语义建议请求也必须复用统一 LLM 传输选择，`llm.stream=true` 时发送 `stream=true` 并聚合完整工具调用后再校验结果。只生成图片、登记空 JSON 或进入普通图片画布均不构成 UI 工作流完成，详见 [`【技术方案】UI工作流资源桥接与Runtime执行-2026-08-24.md`](../【技术方案】UI工作流资源桥接与Runtime执行-2026-08-24.md)。
@@ -1276,6 +1309,15 @@ DirectProject 使用 `approvalPolicy=never`，避免每次原生调用再经过
 - 该档位不把最终验收条件提前成启动条件，也不把平台画布、preview、static smoke、发布包或其它平台产物检查作为 child 或根 Supervisor 的完成门。缺少平台产物不会把已完成任务重置为 `Pending`；根 run 只等待任务图进入终态并交回结果。
 - 代码可先按约定的项目路径落地并完成自己的工作；后续任务状态变化只负责唤醒同一根 run 继续收束，不因 `art-polish`、`art-asset-plan` 等非代码任务失败而阻塞代码启动。平台产物和可玩性检查若需要，属于后续独立验收，不是本档位的运行前置条件。

+## 2026-09-04 AGC 项目聊天 Markdown 与流式回复渲染
+
+- 项目开发工作台的 `ProjectWorkspaceChatPane`、`ProjectSupervisorView` 与 `SupervisorChatOnlyView` 继续共享 `ChatMessage` / `visibleMessages` 数据结构；聊天 Markdown 只作为前端表现层能力，不新增消息字段、持久化格式、后端 DTO 或事件协议。
+- 三个视图统一复用 `apps/ai-game-creator-shell/src/components/ChatMarkdownMessage`。assistant 历史消息和流式临时回复使用 `react-markdown + remark-gfm` 渲染；用户消息与命令草稿保持纯文本。调用方仍先执行现有的 `projectSupervisorVisibleConversationText` 安全文案归一化，再交给展示组件。
+- 流式回复以事件中的 `accumulatedText` 作为当前完整草稿：每次更新替换上一版临时正文，不在渲染层自行拼接 `deltaText`。既有 `runId` / sequence 去重、最终 assistant 持久化和历史回放语义保持不变。
+- Markdown 禁止原始 HTML；链接和图片只显示普通文本，不产生可点击或可加载的外部资源。后续若开放安全外链，必须另行评估协议白名单、窗口策略和审计边界，并保留实现 TODO。
+- Markdown 元素样式使用 Tailwind 内联 class，限定在聊天消息组件内部，不改全局 `.message`、资源文档预览或启动器全局 Agent 聊天。组件异常按单条消息回退纯文本，不能使整个聊天面板崩溃。
+- 流式更新沿用“仅在用户接近底部时跟随”的滚动语义；用户主动查看历史时不得被实时 Markdown 高度变化强制拉回底部。实现验收需覆盖 GFM、未闭合 Markdown 中间态、HTML/链接/图片安全、三视图一致性、流式去重、历史回放和桌面/移动视口。
+
 ## 2026-08-29 DirectProject 受控联网搜索闭环

 - 本次正式产品范围只包含 `DirectProject` 单 Codex Agent；`Provider`、`ToolHost`、`DirectHome` 不新增联网工具桥，也不纳入本次联网路由覆盖。受控联网唯一实现为 `agc_tools.agc_web_search`：Codex app-server 通过审核的 STDIO MCP 工具目录发起调用，客户端 loopback 工具桥执行固定 Bing RSS HTTPS 请求，过滤非 HTTPS、凭据 URL、回环 / 私网 / 本地域名，返回有界标题、摘要和结果链接，并以“不可信网页内容”标签回传。
@@ -1289,6 +1331,26 @@ DirectProject 使用 `approvalPolicy=never`，避免每次原生调用再经过
 - `/api/llm/responses` 与 `/api/llm/chat/completions` 的正式请求体上限为 `32 MiB`。两个路由必须显式配置 Axum `DefaultBodyLimit::max(LLM_REQUEST_MAX_BODY_BYTES)`；不能依赖 handler 内的 `Bytes / Json` 后置检查，否则 Axum 默认 `2 MiB` 会先拒绝 Direct Codex 携带图片工具结果的大上下文请求。超过 `32 MiB` 仍返回 `413 PAYLOAD_TOO_LARGE`。
 - Codex app-server 的 failed turn 需要把上游 / 连接层 HTTP 413、`PAYLOAD_TOO_LARGE` 和 provider proxy 的 `provider request too large` 映射为稳定分类 `codex-app-server-error:request-too-large`；用户可见文案固定为“模型请求体过大，请减少参考图或上下文后重试”，不得落入 `other` 或泛化成权限 / 安全策略错误。

+## 2026-09-09 项目写锁残留回收与启动诊断
+
+- `.agent/project.lock` 新增 `processStartedAt`（持有进程启动时间，Unix 秒）。PID 仍存活时必须先核对启动身份：身份不一致即判定 PID 复用，可直接回收；旧锁没有该字段时退回“进程启动时间晚于锁 `createdAt` 加 5 秒容差”的推断，锁创建时间未知时不做该推断。崩溃停在 `create_new` 与落盘 payload 之间的空锁 / 坏锁宽限期从 600 秒收紧到 30 秒；无法判定持有者是否存活、或 mtime 不可读时保持保守（前者 600 秒、后者不回收），活持有者仍然不回收。
+- 回收判据与删除必须基于同一次读到的锁文件快照：payload 只解析一次，删除前重新核对字节，只有内容仍是判定时的内容才 unlink；文件已消失或被替换时重试 `create_new`，不把并发回收当成错误。
+- 启动诊断日志改为 `StartupLogSlot`：优先用已经生效的配置目录（含 `--config-dir`），否则退到平台配置根（Windows APPDATA、macOS Application Support、其它平台 `XDG_CONFIG_HOME` / `~/.config`），成功后再切换到真实配置目录。`startup.*.failed` 与 `show_startup_error_dialog` 不再是死分支；日志路径未知时同样给出用户可见提示。Windows 启动失败恢复系统消息框并附诊断日志路径，其它平台写 stderr，同一进程只提示一次。
+- 边界与验证：残留的 `agent-runner.lock` / `agent-runner.gui-owner.lock` 是 OS 独占句柄锁，进程退出即释放，文件本身不阻塞下次启动；真正阻塞启动的是仍有活进程持锁。验证覆盖 `project_lock_recovery` 11 条（死 PID、非法进程号、空锁宽限、PID 复用时间推断、PID 复用身份不一致、身份一致不抢锁、旧格式活持有者不抢锁、新鲜空锁不抢锁、存活未知保守回收、mtime 未知保守回收、并发替换或已消失时不删除）、`diagnostic_log` 7 条，以及真实二进制双实例：第二个实例写入 `startup.runner.owner-lock.failed` 并弹出可见提示。
+
+## 2026-09-10 Direct 写通道项目锁等待、持锁方可诊断与权限分类
+
+- `agc_write_file` 是用户直接触发、失败即整轮无法落盘的项目写入通道，原先却用零等待 `acquire_project_write_lock`：任何重叠都在 24-42ms 内被判成“项目正在被其他写操作占用”，而 `file.write / file.patch / file.delete` 等入口用的是约 10 秒有界等待。现统一为 `acquire_game_creator_agent_runtime_project_write_lock_with_wait`：短暂重叠排队等成功，只有预算耗尽才报出带持锁方身份的错误；同一轮并行写多个文件按同一把锁串行。这是 2026-07-22 同一形状修复在 Direct 通道上的补齐，与 2026-08-13 一节“这些结果统一投影为争用并进入既有有界等待”的口径一致。**失败耗时是判据**：几十毫秒说明该入口没等，不是锁没释放。
+- 这条等待是**同步轮询**（2_000 × 5ms，最多约 10 秒），而 `handle_direct_tool_bridge` 是 async handler：直接在 handler 里跑完整条写路径会占住一个 tokio worker，争用窗口内同一轮并行写多个文件时会有多个 worker 被占，而这条 bridge 与只读端点、UI 命令共享同一个 runtime——Issue #318 现场“只读工具全部正常”这条诊断特征会在争用窗口内失效。因此写路径经 `bridge_write_file_in_blocking_pool` 走 `tokio::task::spawn_blocking`（仓库既有模式，如 `codex_app_server.rs` 的 DirectProject 历史落盘），等待语义与错误文案不变；定向用例用默认 `current_thread` runtime 加心跳任务锁住“等待期间 runtime 仍在推进”。
+- 争用错误必须带持锁方身份才可行动：`项目正在被其他写操作占用：<锁路径>（持锁方 commandId=<命令> pid=<进程> createdAt=<创建时间> ownerIsSelf=<是否本进程>）`。锁文件处于 delete-pending 或尚未写完时读不到身份，也必须显式表达成“不可读”，不得默认成“没有持锁方”。前缀逐字不变：`project_gates.rs`、`provider_recovery.rs`、`planning_session_v2.rs`、`direct_runtime.rs` 和前端 `App.tsx` 都按它把争用识别成可等待的瞬时状态；这句话已是 `crate::project::PROJECT_WRITE_LOCK_CONTENTION_PREFIX` 单一真源，四个站点不再各自手写中文。
+- `create_new` 的失败必须分三类处置，不能再共用一句文案：可重试（目标已存在、Windows `sharing violation(32)` / `lock violation(33)` / `ACCESS_DENIED(5)`）进入有界等待；明确判定不是争用的权限 / ACL 拒绝（Unix `EACCES`）失败关闭且文案不含争用前缀；其它 I/O 错误原样上报。**重试性只能由错误码决定，不能用 `path.exists()` 这类一次 metadata 观察决定**：目标被删除时目录项先消失、删除挂起随后才结束，`create_new` 会在这个拆链窗口里返回 `ACCESS_DENIED(5)`，而 `exists()` 往往已经报 false（本机实测 6 万次建锁 / 删锁竞争里 396-538 例命中该组合）。按“目标不存在”当场判成权限拒绝，等待层就会立刻失败关闭——正是本次要消灭的“毫秒级直接失败”，只是换成更误导的 ACL 文案。平台判据以 `project_write_lock_open_failure_for(platform, error)` 保留、平台由参数传入而不是 `#[cfg]`：CI 只有 Linux runner，Windows 分支必须在 Linux 上也能断言。
+- Windows 上真实 ACL 拒绝与删除拆链窗口在错误码上不可区分，所以终态改判放到**等待预算耗尽之后**：`ProjectWriteLockFailure::exhausted_projection(waited)` 只在“真的等过预算 + 目标此刻仍不存在 + 错误码是 `ACCESS_DENIED(5)`”三个条件同时成立时才投影成权限拒绝；单次试探（`max_attempts == 1`，例如 hydrate 的 `try_acquire_...`）没有等待证据，保持争用语义。代价是 Windows 上真实 ACL 拒绝会先等满等待窗口（约 10 秒）才报权限错误；Unix 的 `EACCES` 立即判定、不等待。
+- 重试与否改由**类型**决定，不再解析错误文案：`acquire_project_write_lock_failure` 返回 `ProjectWriteLockFailure::{Retryable, Terminal}`，有界等待按 `is_retryable()` 分流，`acquire_project_write_lock` 只是它的文案包装。零等待入口前缀不变，只在“错误码不可区分且目标此刻不存在”时补一句“可能是删除挂起、删除拆链窗口或权限 / ACL 拒绝”，把两种处置都交给调用方，而不是替它猜一个。
+- 复用 2026-09-09 的回收机制，不新增第二套：`ProjectWriteLockSnapshot` 补 `commandId` 与 `describe_holder()`，争用错误、`project.write_lock.reclaim_stale`、`project.write_lock.wait_exhausted` 三处共用同一份身份描述。“活持有者始终不回收”的判据不变。
+- 等待预算耗尽时按 `project.write_lock.wait_exhausted` 记录 `commandId`、尝试次数、等待毫秒数、`projection=`（contention / permission_denied）与持锁方身份，Unix 上明确判定的权限拒绝按 `project.write_lock.permission_denied` 记录；争用不在零等待入口里逐次记账，避免有界等待的上千次重试淹没日志。这条日志正是 Issue #318 现场缺的“谁在持锁、是不是自己人”。**这条日志与终态改判都只在真的等过（`max_attempts > 1`）时发生**：单次试探（hydrate 的 `try_acquire_*`）不写 `wait_exhausted`（`waitedMs≈0` 会让“耗尽”失去意义，而 hydrate 每次状态变化都会撞一次锁，写成日志就是噪声），也不做终态改判。
+- 定向验收覆盖：同进程重叠写等待后成功、同一轮并行写多个文件、有界等待不占 runtime worker（`current_thread` + 心跳任务）、活外部进程持锁（错误带 `ownerIsSelf=false` 且锁文件不被回收）、ACL 拒绝不投影成争用，外加两条平台无关判据用例（重试性只由错误码决定、终态改判三条件）——后两条让 Linux CI 也能盯住 Windows 分支。对应 `project_lock_recovery`、`direct_tool_bridge` 与 `project/write_lock` 定向测试；`tests/project_tools.rs` 既有的 `runtime_project_write_lock_waits_for_delete_pending_target` 继续覆盖“带句柄的 delete-pending 必须等到成功”。
+- 仍待收口（后续事项）：① 其余仍用零等待取锁的入口（`command.exec / project.verify / memory / conversation / task / checkpoint / 预览 / UI 编辑器 / 资源编辑器 / Tauri 命令`）本批不改，遇到同类争用仍会立刻失败；零等待入口无法区分“拆链窗口 / ACL 拒绝”，因此在前缀不变的前提下补一句“锁文件此刻不存在，可能是删除挂起、删除拆链窗口或权限 / ACL 拒绝”。② 锁策略已按“单一职责”收口到 `project/write_lock.rs`（887 行：取锁、等待分类、持锁方诊断、残留回收），`project/filesystem.rs` 回到项目文件 IO（680 行）；仍待收口的是 Direct 锁用例，它们还留在 `direct_tool_bridge.rs`（3135 行，锁用例与桥实现混在一起），后续移到 `tests/project_lock_recovery.rs` 或独立测试文件。③ 行为级 Windows 用例（delete-pending 等）仍只在 Windows 本地执行，CI 没有 Windows runner；关键判据已参数化到 Linux 可覆盖，行为级覆盖仍需本地执行或后续补 runner。
+
 ## 2026-09-11 AGC 登录态自动续期

 - AGC 前端请求客户端配套后端的鉴权 API（包括 `/api/llm/models`）收到 `401` 时，共享进行中的 refresh 请求；确认当前用户并安装 Rust / Runner 会话后，用新 access token 最多重试原请求一次。`403` 权限拒绝不触发续期；续期失败保留原鉴权错误，账号切换或登出后不重发旧请求。
@@ -0,0 +1,58 @@
+# DirectProject Codex 原始历史与异常恢复
+
+更新时间：`2026-09-07`
+
+## 目标
+
+DirectProject 只使用 `.agent/conversations/project.jsonl` 作为对话历史。历史保存 Codex Responses API 的完整 item，使聊天展示与新线程恢复使用同一份事实来源；两者只是不同读取动作。
+
+本方案只适用于 DirectProject，不改变 DirectHome、Agent session 历史或 `runtime/direct-codex/turns` 审计账本。
+
+## 文件格式
+
+每行采用 Codex CLI rollout 的最小事件外壳，不保存 AGC 自有的顺序号或运行环境字段：
+
+```json
+{"type":"response_item","payload":{"type":"message","role":"user","content":[{"type":"input_text","text":"你好"}]}}
+```
+
+`payload` 必须是未经改写的 Responses item。Direct 回合不由浏览器预写用户 message；Codex 返回的 `rawResponseItem/completed.params.item` 原样追加。显式的本地 user/assistant 补写只能通过受权限保护的 `append_direct_project_conversation_message` 命令完成。native 工具、MCP 工具、reasoning、调用参数和调用结果都保留完整内容，不截断、不摘要、不保存 delta/started 事件。
+
+DirectProject 不迁移旧 `{role,content}` 行；实现按新格式工作。
+
+## 正常回合
+
+1. 启动 `ephemeral: true` 线程，并启用 `experimentalRawEvents: true`。
+2. 新线程先把历史 item 数组一次注入；注入成功后执行新的 `turn/start`。本轮用户 item 只接受 Codex 回传的 `rawResponseItem/completed`，不由 AGC 预写。
+3. 收到 `rawResponseItem/completed` 后立即追加其 `params.item` 并 flush。
+4. 正常 `turn/completed: completed` 不生成额外记录。
+
+## 异常回合收尾
+
+AGC 判定本轮不会再产生新事件时收尾：用户中断、turn failed、无响应/idle timeout、硬超时、transport closed、stdout EOF 或 app-server 卡死终止均属于异常终态；正常 completed 不收尾。
+
+`item/agentMessage/delta` 正常带有 `itemId`；若协议异常缺失，AGC 记录 warning 并按当前 turn 生成稳定回退 id。AGC 在内存中按该 id 累计 assistant 文本，不实时写 delta。异常终态时，对仍有累计文本的 item 合成普通 Responses assistant `message` item：
+
+```json
+{"type":"response_item","payload":{"type":"message","role":"assistant","id":"msg_1","content":[{"type":"output_text","text":"已累计文本"}]}}
+```
+
+合成 item 在返回错误、销毁连接或启动恢复线程前追加并 flush。没有文本 delta 的半截工具/MCP 调用不合成，等待完整 `rawResponseItem/completed`。
+
+`rawResponseItem/completed` 缺少 `item`（包括 `null`）时视为反序列化错误；该回合按异常终态收尾，历史中不会写入非法空 item。
+
+Codex 启动时注入的 `host_skills.instructions`、`permissions.instructions` 和 `environments.environment_context` item 不属于项目对话历史；落盘时过滤，读取和线程注入时也过滤。过滤同时识别 role=user 的完整上下文标签包裹文本，即使该 item 没有 `internal_chat_message_metadata_passthrough` 元数据，也不能把它当成用户回合。
+
+## 恢复
+
+创建新的 ephemeral thread 后，读取 `project.jsonl` 中所有 `response_item.payload`，按文件行顺序一次调用 `thread/inject_items`，再执行新的 `turn/start`。Codex 负责上下文窗口管理；注入失败直接失败，AGC 不截断、摘要或改写历史。新 thread 已进入连接池但历史读取或注入失败时，必须先从池中淘汰并取消订阅该 thread，重试只能创建新 thread 并重新注入。
+
+`clientUserMessageId` 仅作为 Codex 用户消息的稳定标识随 `turn/start` 发送，不等价于 turn 级 exactly-once 幂等。断线后的重试仍须由项目侧持久化 turn ledger 或服务端去重合同决定，不能仅凭该字段再次执行。
+
+聊天界面只从 message item 提取 user/assistant 内容；工具 item 不再拼成 `tool: ...` 假文本。
+
+DirectProject 的浏览器层只负责显示和乐观状态，不再调用通用对话写入器；Rust 是该历史文件的唯一写入方。历史读写与回合累计分别位于 `agent/direct_project_history.rs` 和 `agent/direct_project_turn_history.rs`。
+
+## 写入与损坏边界
+
+写入使用 `write_all + flush`。读取时允许丢弃文件末尾一条不完整 JSON 行；中间坏行直接失败。不会对旧格式做迁移或兼容。
@@ -14,6 +14,10 @@

 ## 3. 已确定的产品边界

+### 3.0 客户端能力 MCP 暴露边界（2026-09-03）
+
+客户端仍由现有对话入口启动并驱动 Codex；MCP 只是把客户端已审核的项目、文件、资源、画布、生成和预览能力暴露给该 Codex 或其它 Host。客户端只负责账号、项目路径、权限、计费、幂等、锁和恢复等自身安全，不替 Codex 做高层意图/完成门禁。审核 Skill 的索引和正文可作为只读 MCP resource 提供，第三方扩展不得获得客户端会话凭据、内部路径或 bridge token；该能力与公网 `/api/external/v1/mcp` 保持独立。
+
 ### 3.1 客户端安装、运行时注入

 - 扩展内容保存在 AGC 客户端的扩展仓库。
@@ -89,6 +89,10 @@ Codex app-server 协议里，`commandExecution.commandActions` 已分类为 `Rea

 不升级 `GAME_CREATOR_AGENT_DB_SCHEMA_VERSION`；新 `recordType` 走 Ordinary 追加。`updatedAt` / `schemaVersion` 仍由 `serialize_agent_db_record` 写入。

+### 2026-09-03 客户端对话与 MCP 能力边界
+
+客户端对话仍由现有 Codex app-server 链路完成；MCP 只暴露客户端自身业务能力和审核 Skill 指导。客户端安全门禁限于账号、项目路径、权限、计费、幂等、锁、revision 与恢复，不根据 Codex 自然语言替代 Codex 决定业务动作。外部 Host 返回如需旁路归档，可使用显式记录工具，但不替代现有 conversation projection，也不触发资源、状态或完成判定。
+
 jsonl 每条自带 `recordedAtMs`（`unix_millis`）。同一 `clientTurnId` 若再次进入（当前 GUI 运行中互斥，结束后理论上可再来）：只追加，不截断；后一次 `turn_start` 视为新 attempt。读摘要时按文件内最后一次 `turn_start` 到对应 `turn_end` 计算 `offeredRead`。`agent.db` 每次 `turn_end` 再追加一条摘要，分析取该 `clientTurnId` 最后一条。

 ## 5. 记录合同
@@ -76,6 +76,7 @@
 ### 失败生成任务归档与任务侧栏

 - 用户界面的“删除失败任务”语义是归档，不物理销毁私有 generation ledger。只有平台明确失败的 `failed` 任务可归档；`reconciliation-required`、已受理、运行中和结果未知任务不得移出恢复队列。
+- 已受理 operation 在重试时若请求快照发生变化，客户端可先对原 operation 执行一次只读状态查询；仅当平台明确返回 `failed` 时才自动收口旧账本并允许新提交，排队、运行中、完成或未知状态继续保持原幂等身份并阻断替代请求。
 - 归档命令校验 project、draft、generation 与 expected draft revision，先把私有 ledger 写入可重放的 `archiving/archivedAt`，再从 `draft.generations` 移除公开投影并推进一次 revision；草稿删除成功并回读后才发布 `archived`。`archiving` 以及历史上已写 `archived` 但仍残留公开记录的状态都必须在恢复阶段幂等收敛，且不依赖图片生成服务凭证。
 - 失败占位和右上角任务项复用同一个归档动作，成功后两处同时消失，其它任务、图层和候选不受影响。
 - 任务侧栏折叠只属于当前会话 UI 状态，不写入 draft 或 manifest。视觉和交互复用现役美术画布：右上角独立“任务列表”图标按钮、20rem 白色模糊卡、总数徽标、`排队/生成中` 与 `已完成` 双 Tab、状态圆形图标、阶段进度和时间信息；折叠后只保留图标按钮，不显示摘要卡。用户显式新建 generation 时自动展开并切回活动 Tab，普通进度更新不得推翻用户已有折叠选择。Game Agent 的失败归档作为任务行扩展保留。
@@ -1,6 +1,7 @@
 # 立项策划 Agent（Fast GDD）技术方案

 - 日期：2026-08-10
+- 状态：**已退役**。本文描述的 V1 策划链路（`project-supervisor-plan` 根 Run、`project-planning` 子 Agent、`plan.submit_gdd` 工具、Fast GDD 审批门禁与恢复机制）已由策划会话 Runtime V2 取代，源码已于 2026-09 按四不写原则整体删除；现行方案见 `【技术方案】策划会话RuntimeV2接入与旧链路退役-2026-09-03.md`。本文仅作为历史推导记录保留。
 - 适用范围：AI 游戏创作独立 App、Project Supervisor、Agent Runtime、本地项目策划 sidecar 与后续完整构建准入

 > 当前口径（2026-08-30）：以本文件中标注的 D11 / 最新修订和当前 `apps/ai-game-creator-shell` 实现为准。D6～D9 等被明确标注为作废或被取代的段落仅保留推导背景，不得作为现行拓扑、入口或 Runtime 真相；产品入口与 DirectProject 总体口径见 `docs/README.md` 和 App 实施计划。
@@ -9,7 +10,7 @@

 当前普通完整构建会从简短需求直接进入 `autonomous-game-build`，用户在消耗完整构建成本前没有正式确认玩法方向、MVP 范围和原型验证项的环节。现有完整构建中的 `design-director` 是只读协调任务，`design-foundation` 又会自行补齐玩法定位；用户意图与后续实现之间缺少可版本化、可审批、可恢复的策划基线。

-本方案新增“立项策划”阶段：用户给出一句需求后，由 Project Supervisor 顶层 root run 通过 `agent.delegate` 发起一个独立 `agentId` 的静态委派子 Agent（`agentId=project-planning`；2026-08-13 起取代原“下游工作流节点由 manifest ready-task 调度器启动”的表述，见第 1.1 节「D11 新拓扑」与 D11），在最多 3 轮决策卡内形成 Fast GDD（该 3 轮上限依赖 WP1——静态委派澄清轮次与返工深度拆分——先落地，见第 1.1 节；落地前实际上限仍是 1 轮）；Runtime 校验并提交不可变版本，用户通过审批卡批准、修改或退回。只有不可变 GDD 与对应 approve receipt 同时有效时，后续完整构建才能取得 `approvedGddRef`。
+本方案新增“立项策划”阶段：用户给出一句需求后，由 Project Supervisor 顶层 root run 通过 `agent.delegate` 发起一个独立 `agentId` 的静态委派子 Agent（`agentId=project-planning`；2026-08-13 起取代原“下游工作流节点由 manifest ready-task 调度器启动”的表述，见第 1.1 节「D11 新拓扑」与 D11），在最多 3 轮决策卡内形成 Fast GDD（该 3 轮上限依赖 WP1——静态委派澄清轮次与返工深度拆分——先落地，见第 1.1 节；落地前实际上限仍是 1 轮）；Runtime 校验并提交不可变版本，用户通过审批卡批准、修改或退回。审批修改后的 continuation 沿用普通 Planning V2 回合协议，Provider 可以继续问询，也可以直接提交新的完整 GDD；既有问询计数和已确认问答继承，不因修改重置。只有不可变 GDD 与对应 approve receipt 同时有效时，后续完整构建才能取得 `approvedGddRef`。

 目标：

@@ -389,7 +390,7 @@ Runtime 注入并强校验以下精确结构：

 ### 5.1 对话循环

- 最多 3 轮主动追问，每轮只问 1 个主要决定。
+- 最多 3 轮主动追问，每轮只问 1 个主要决定；审批修改后的 continuation 仍沿用同一问询预算，可以继续问询或直接提交新的完整 GDD，问询计数不重置。
 - 建议顺序：核心行为与本局目标 → 重玩动力 → 制作边界与 MVP。
 - 满足任一条件即出稿：用户明确说“直接出稿”；已经完成第 3 轮；剩余问题不影响首个可玩闭环；Runtime 注入 240 秒 Agent 活跃时间软提示。
 - `accumulatedAgentMillis` 只累计 Provider 活跃区间，不包含等待用户、等待审批、进程休眠或应用关闭时间。
@@ -790,7 +791,7 @@ input 是当前 GDD 的完整快照，不要求与 source session 的 `decisions
 | title                    | 1～80 scalar                                                                                                                                   |
 | genre.primary / fusion   | primary 1～40；fusion 为 `null` 或 1～40                                                                                                       |
 | artStyle                 | visualType 1～80；keywords 3～5 个且去重，每项 1～32；其余各 1～400                                                                            |
-| oneLiner                 | 45～90 scalar                                                                                                                                  |
+| oneLiner                 | Runtime 实际接受 10～160 scalar；模型 schema 提示 25～90 scalar（有意不对称，不是缺陷或 bug）                                      |
 | pillars                  | 2～4 条；name 1～40，其余文本各 1～240；name 唯一                                                                                              |
 | coreLoop                 | 4～8 步，每步 1～120                                                                                                                           |
 | targetUsers              | 三个主文本各 1～240；referenceGames 0～5 项，每项 1～80                                                                                        |
@@ -1895,7 +1896,7 @@ M0 文档 PR 本身最低验证：Markdown 结构与三张 Mermaid 图可解析
 | 现役 pending wire                         | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver.rs:26-27`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/provider_action_batch.rs:3-46,219-270`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/pending_confirmation_ledger.rs:290-520`                                                                                                                                                                                                                                                                    | 保持 `game-creator-pending-action.v5`；M1 另建 planning pending，不升级全局 wire                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
 | submit 专用提交/恢复分支                  | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/main_loop.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/pending_recovery.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/recovery_scan.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/provider_action_batch.rs`                                                                                                                                                                                                               | **2026-08-14 按 M1B-2 收口**：在普通 dispatch 前处理 Runtime-owned submit；提交后终止策划子 run，并保留 generic v5 standalone pending + v4 batch anchors，不复用 `WaitingForUserInput`，不创建 planning pending。审批等待属于 M1C-1                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
 | JSON sidecar                              | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/json_sidecar.rs:44-104,122-250`                                                                                                                                                                                                                                                                                                                                                                                                                                                             | 现有 writer 可覆盖；不可变文件必须新增 no-replace helper                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
-| 项目锁                                    | `apps/ai-game-creator-shell/src-tauri/src/project/filesystem.rs:85-138`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/project_gates.rs:1467-1505`                                                                                                                                                                                                                                                                                                                                                                                         | 所有 planning mutation 在同一项目锁内重读事实                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
+| 项目锁                                    | `apps/ai-game-creator-shell/src-tauri/src/project/write_lock.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/project_gates.rs:1467-1505`                                                                                                                                                                                                                                                                                                                                                                                         | 所有 planning mutation 在同一项目锁内重读事实                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
 | completion blocker                        | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_approval.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/project_gates.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/main_loop.rs`                                                                                                                                                                                                                                                                                                      | **M1C-1 隔离 worktree 已补齐**：仅对 exact `project-supervisor-plan` standard 顶层根 Run 生效，读取 GDD lineage、approval pending/receipt、generic submit anchors、terminal observation、decision audit、planning session 与 recovery，且只读不创建 pending；现役 collaboration blocker 对策划子 Agent 仍不适用                                                                                                                                                                                                                                                                                                                                                                                                                                  |
 | plan 根 run 子 Agent 创建面               | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_tools/delegation.rs`（`observe_agent_runtime_agent_delegate` / `observe_agent_runtime_agent_spawn_isolated`）、`agent/runtime_protocol/run_configuration.rs`（`validate_project_supervisor_plan_root_binding_at`）、`agent/prompt.rs`（`game_creator_project_supervisor_tool_plan_prompt`）                                                                                                                                                                                                          | **2026-08-14 `M1A-4` 已落地**：plan 根 run 只能委派 `project-planning`，`agent.spawn_isolated` 一律拒，两条通道共用 typed `kind=plan-root-child-target-unsupported`；plan source 下不拼 `supervisorIntro` 与 `$visualContract`。**已知残留（有意保留，见 decision-log 2026-08-14 `M1A-4` 条）**：`$base` 的 `$isolatedAgentTemplates` 段仍会向 plan 根 run 列出全部专业角色名——那是 `agent.spawn_isolated` 的模板目录，因执行层硬拒而成为死文本；因此**不得**写「plan 根 run 上下文不出现其它 Agent 名」这类验收句                                                                                                                                                                                                                               |
 | plan retry                                | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/lifecycle_control.rs`（`resolve_game_creator_agent_runtime_retry_configuration_at`）、`runtime_driver.rs`（`supervisor_plan_root_identity_holds_at`）                                                                                                                                                                                                                                                                                                                                         | **2026-08-13 `M1A-3` 已落地 source 保源**：`task.source == project-supervisor-plan` 时先走强判据，通过则保留该 source，失败 `kind=plan-root-retry-identity-unsupported`、不降级。gui/cli 仍走 `agent-background-task`。plan-session revision / `gddId` / 按 `gdd-approval` kind 禁 retry 仍属后续包（现役已拒 `waiting-*`）                                                                                                                                                                                                                                                                                                                                                                                                                      |
@@ -176,7 +176,9 @@ error=unable to locate image at `<project>/memory/README.md`: (os error 2)

 ---

-## 4. 缺陷 4：普通 action 批次带 plan update 时预检自相矛盾（已修）
+## 4. 缺陷 4：普通 action 批次带 plan update 时预检自相矛盾（已修，2026-09 随策划 V1 退役删除相关代码）
+
+> 本节引用的 `plan.submit_gdd` 特判、`provider_batch_plan_update` 与 `planning_session_binding` 字段属于已退役的策划 V1 链路，2026-09 已按四不写原则整体删除；回归测试 `supervisor_collaboration_batch_keeps_plan_update_off_members` 保留并收敛为「非 planning 批次的 plan update 不落入成员」这一不变量。

 换成 `gpt-5.6-terra` 后 LLM 链路可用，但首次复现曾在第二步「委派 project-planning 产出 Fast GDD」失败。这一条与 Provider 无关，是当时实现引入、现已修复的回归。

@@ -0,0 +1,40 @@
+# UI 编辑器工作流完成通知弹窗
+
+## 目标
+
+UI 编辑器的“分析参考图”“识别界面结构”“绑定视觉素材”三个工作流动作在每次运行结束后，用独立的阻塞通知弹窗明确反馈结果，避免仅依赖卡片内一行状态文本而被忽略。
+
+## 交互约定
+
+- 三个动作的每次运行在终态（成功或失败）时自动弹出一次通知。
+- 弹窗打开期间遮挡并阻塞工作台底层交互；关闭后恢复当前步骤，不自动切换步骤、不自动重跑。
+- 使用现有 `ThemedModal` 的普通关闭行为（遮罩、Esc 和关闭按钮均可关闭）。
+- 弹窗仅承载通知，不提供“继续”“重试”或其他业务操作。
+- 关闭弹窗后，工作流卡片继续显示同一条结果状态；重新运行产生新的终态时再次通知。
+- 绑定动作包含多个批次时，只在最终批次结束后通知一次。
+
+## 文案
+
+弹窗标题由步骤名和结果态组成，例如“识别界面结构完成”或“绑定视觉素材失败”。正文复用卡片状态文本，并逐条扩展结果信息，统一以“请检查”收尾。
+
+成功状态的基线文案：
+
+- 分析参考图：保留已应用的语义建议数量；若现有状态可可靠取得问题/待确认数量，则一并展示。
+- 识别界面结构：保留替换的界面树数量，并展示识别结果中的待检查/必须修复数量（若可取得）。
+- 绑定视觉素材：保留现有 `B/B` 批次计数，改为用户可读的绑定结果。
+
+失败状态保留实际错误文本，仅在弹窗标题中补充步骤和失败上下文，正文同样以“请检查”收尾。
+
+## 实现边界
+
+- 新增独立的工作流通知弹窗组件文件，组件只负责展示和关闭，不包含工作流领域规则或后端副作用。
+- 在 UI 编辑器页面/会话投影中维护临时通知状态，并在三个异步动作的成功与失败终态写入。
+- 不新增后端字段或公开契约；数量只能使用当前前端已有且可靠的数据。
+
+## 验收
+
+1. 三个动作成功和失败终态各弹出一次通知；绑定批次只弹最终一次。
+2. 弹窗打开时底层工作台不可操作，且无继续/重试等业务按钮。
+3. 弹窗可通过标准关闭方式退出；关闭后卡片状态仍可见。
+4. 每条成功文案保留原有数量信息并增加可用的检查数量，所有文案包含“请检查”。
+5. 重新运行后新的终态会再次弹出通知。
@@ -48,13 +48,19 @@ UI 编辑器支持撤销最近一次或多次作品编辑，并支持重做被

 - 桌面端页面工具栏提供撤销和重做按钮。
 - 非文本编辑目标聚焦编辑器时支持 `Cmd/Ctrl+Z` 撤销、`Cmd/Ctrl+Shift+Z` 和 `Ctrl+Y` 重做。
- `input`、`textarea`、`select`、`contenteditable` 以及按钮/链接等控件交给浏览器原生行为，不拦截文本撤销。
+- `input`、`textarea`、`select`、`contenteditable` 等文本编辑控件交给浏览器原生行为，不拦截文本撤销；按钮/链接等非文本控件仍允许编辑器撤销/重做快捷键生效。
+- UI Editor 页面内选中节点后，支持不带修饰键的 `Delete` 删除节点及其子节点；快捷键复用 Inspector、树面板和右键菜单共用的 `deleteNode` 命令，因此沿用根节点/锁定禁删、单条历史记录、dirty 标记和后续保存语义。
+- `Delete` / `Backspace` 在 `input`、`textarea`、`select`、`contenteditable`、按钮和链接等交互控件聚焦时交给浏览器原生行为；无选中、根节点、锁定或目标不存在时不执行删除。长按重复事件不重复删除，成功处理后阻止默认行为和事件冒泡。
+- `Delete` / `Backspace` 在打开的对话框（`role="dialog"` 或 `aria-modal="true"`）内聚焦时交给对话框处理，不删除对话框背后的节点。
+- `Cmd/Ctrl+Z`、`Cmd/Ctrl+Shift+Z` 和 `Ctrl+Y` 在打开的对话框（`role="dialog"` 或 `aria-modal="true"`）内聚焦时暂停编辑器级撤销/重做，由对话框或浏览器原生行为处理。
 - 无可撤销或重做记录时按钮禁用，并提供可访问名称。

 ## 脏状态与选择

 撤销和重做恢复的 State 继续参与现有 dirty 判定、保存和后端持久化。历史快照不包含当前设计图、节点选择、隐藏集合或视口；恢复后若当前选择已不存在，页面清理无效选择并保持安全空态。

+删除节点后，若当前选中节点是被删除节点或其任意后代，页面将选区清空为 `null`；删除成功不强制抢占焦点。该选择清理属于 UI 临时状态，不写入撤销历史。
+
 ## 验收标准

 1. 单次字段编辑可撤销和重做。
@@ -67,3 +73,4 @@ UI 编辑器支持撤销最近一次或多次作品编辑，并支持重做被
 8. 工具栏按钮、禁用态和桌面快捷键可用，文本控件保留原生撤销。
 9. no-op、锁定、校验失败和不存在目标不进入历史。
 10. 颜色选择器和九宫格边界拖动不会按每个 pointer move 写入 State。
+11. `Delete` / `Backspace` 仅在非交互控件聚焦且存在可删除选中节点时生效；删除整棵子树、可撤销、长按只处理一次，并清理被删除子树内的无效选区。
@@ -0,0 +1,27 @@
+# 预览画布缩放滑杆
+
+## 交付目标
+
+将 UI 编辑器预览区现有的缩放按钮替换为桌面端可拖动滑杆，同时保留快速缩小、放大和适配画布操作。
+
+## 交互约定
+
+- 滑杆选择范围为 25%–200%，步进 5%；快捷加减继续使用核心视口的现有缩放边界。
+- 滑杆位于预览区右下角固定工具栏；不提供移动端或窄窗口 fallback。
+- 保留 `−` 与 `+` 按钮。点击轨道可跳转，拖动滑块实时更新画布和百分比。
+- 缩放以视口中心为中心，继续支持 Ctrl/Cmd + 滚轮缩放。
+- 滑杆支持方向键、Home、End；百分比文本可点击编辑并在失焦时限制到有效范围。
+- 百分比文本使用数字输入框呈现；输入提交后同步视口缩放，适配画布保持独立按钮，点击百分比不会触发适配。
+- 缩放滑杆获得焦点时，Delete/Backspace 不触发 UI 节点快捷删除；缩放按钮鼠标点击不改变快捷键焦点。
+- Windows/Linux 使用 `Ctrl`，macOS 使用 `Cmd`；`+`、`=` 与 `NumpadAdd` 放大，`-` 与 `NumpadSubtract` 缩小，允许按键重复时连续缩放。
+- 快捷键直接复用现有 `+`/`−` 按钮动作：以视口中心为锚点，按 `×1.16`/`×0.86` 改变缩放。
+- 鼠标悬停在预览画布上，或预览画布已获得键盘焦点时，快捷键生效。预览画布需提供可聚焦语义与无障碍名称。
+- 事件来自输入框、文本编辑区、按钮、链接、缩放工具栏或其他可操作控件时不拦截；不向 iframe 子文档注入监听。
+- 仅在存在可缩放视口且确认命中快捷键时调用 `preventDefault()` 与 `stopPropagation()`，防止浏览器页面同时缩放。
+- 保留现有 `Ctrl/Cmd+0` 适配画布与 `Ctrl/Cmd+1` 恢复 100% 行为，不增加其他重置快捷键。缩放仍是当前预览实例的临时 UI 状态。
+- 快捷键和百分比使用逻辑 `viewport.scale` 作为缩放真相；共享 `CanvasWorld` 的渲染 transform 可能包含超采样换算，验证时不得直接把 CSS transform 值当作用户可见比例。
+- 保留快捷键与缩放焦点边界的组件级回归测试，不扩展端到端测试。
+
+## 验收
+
+桌面端可通过按钮、轨道点击、拖动和键盘改变缩放；百分比与画布同步，边界不会越界。组件级测试覆盖平台修饰键、主键盘与小键盘变体、按键重复、悬停/焦点作用域、可编辑与可操作目标放行、无内容放行、浏览器默认行为拦截和现有 `0`/`1` 回归；另运行前端定向类型检查、编码检查和 `git diff --check`。
@@ -251,6 +251,7 @@ npm run check:server-rs-ddd
 10. 已有静态图片的 `POST /api/editor/images/pixel-art-snaps` 是免费 inline 派生操作，不调用外部 provider、不创建 `external_generation_job`、不读写泥点 ledger，也不进入任务侧栏。免费不放宽 owner、稳定引用、输入上限、持久化或处理阶段零持久化门禁。
 11. 主站编辑器生成队列使用同一次前端请求稳定复用的 `x-request-id`，按 namespace + owner + job kind + request id 生成唯一 `dedupe_key`；首次请求已入队但响应丢失时，重试必须返回原任务。同一幂等键携带不同 payload 返回 `409`，不得创建第二个任务或串到旧结果。外部 v1 的 `Idempotency-Key` 使用独立 namespace，不能与主站请求标识碰撞。幂等 payload 比较只对本次已迁移 sanitizer 的图片生成、图片修改、去背景、图标图集和 UI 提取任务，兼容“升级前旧任务仍含客户端 `generationInputs.references`、当前请求已删除该字段”的单向形状；当前请求仍含 references，或 job kind 属于音频 / 视频 / 角色动作等未迁移任务时必须完整比较，其余请求字段始终完全一致。
 12. `generationInputs.references` 是最终资产的服务端权威行引用，不接受客户端自报 provenance。图片生成类请求入队、完美像素及直接创建资源 / 素材时删除客户端 references；worker 和 inline 路径按本次真实参考图、当前 owner 的项目资源 / 素材记录重建 `refType/refId` 后再持久化。仅能证明 owned objectKey、但找不到对应资源或素材行时可以参与生成，不得制造虚假行引用；`title/label` 只作为展示快照，不提升为资源身份。完美像素为兼容升级前的未知结果重放，可继续用旧版 canonical 客户端输入计算 operation fingerprint；新操作持久化元数据只能使用服务端重建值。owner-scoped 项目快照发现同一 operation 的稳定 result `resourceId` 时，HTTP 路径必须在来源解析、OSS 下载、规整、preflight 和 PUT 前直接返回 `409`，携带 `operationResultAlreadyExists=true` 与 `resultResourceId`，客户端仅以 GET-only 项目对账判定权威结果，不复用既存 metadata 作 exact compare-and-return。
+13. 资产操作扣费必须在既有 `profile_wallet_ledger.metadata_json` 中记录服务端确定的 `assetKind`；外部生成任务继续同时记录 `externalGenerationJobId` 与 `externalGenerationClaimAttempt`。公开 `GET /api/profile/wallet-ledger` 不返回原始 metadata、资源 ID 或任务 ID，只为 `asset_operation_consume` 下发可选的用户可见 `reason`：图片、图标图集、美术规范、UI 设计和发布素材等图片生成统一显示“生成美术素材”，图片修改显示“编辑美术素材”，UI 素材提取显示“提取美术素材”，角色动画、视频、音效和背景音乐分别显示对应生成原因。未知、空值和未携带新 metadata 的历史流水不猜测业务含义，不下发 `reason`，共享前端继续回退到来源类型文案“资产操作消耗”。该展示投影不得改变定价、扣费顺序、幂等 ledger、失败退款或余额结算语义。

 ## 外部服务与资产

@@ -660,7 +661,7 @@ Responses 的终态载荷既是工具调用的恢复源，也是正文的恢复

 - 私有单例表，主键 `id=0`，保存 `catalog_json`、`revision`、`updated_at`；不存凭据。
 - `read_agc_model_catalog` / `save_agc_model_catalog` 只接受已登记的 runtime service identity，保存使用 revision 乐观锁。
- 后台 owner 通过 `GET/PUT /admin/api/agc-models` 管理稳定标识、必填别名、实际模型名、启用状态和默认项；客户端 `GET /api/llm/models` 仅返回启用项的稳定标识和别名。
+- 后台 owner 通过 `GET/PUT /admin/api/agc-models` 管理稳定标识、必填别名、实际模型名、启用状态和默认项；客户端 `GET /api/llm/models` 仅返回启用项的稳定标识、别名和目录 `revision`（供条件刷新，不暴露实际模型名）。
 - Responses / Chat 请求按目录解析模型；未知或停用项拒绝。AGC 的 `platform-default` 请求标识使用目录默认项。详细契约见 `technical/【技术方案】AGC后台模型别名与对话选择-2026-09-05.md`。

 ### `error_report`
@@ -62,9 +62,9 @@ Linux 本机多用户并发开发时，`npm run dev`、`npm run dev:*` 单模块

 后端日志默认写入 `logs/api-server/`，独立 BgFilter worker 日志默认写入 `logs/bgfilter-worker/`。后端 API smoke 使用 `npm run dev:api-server`，先检查 BgFilter worker `/readyz`，再检查 API `/healthz`；需要确认 API 实例可接生产流量时检查 API `/readyz`。不要使用旧 `api-server:maincloud` 或任何 `GENARRATIVE_SPACETIME_MAINCLOUD_*` 口径。

-AI 游戏创作客户端使用 `npm run agc`。该入口由 `apps/ai-game-creator-shell/scripts/start-tauri-dev.mjs` 解析 AGC Vite 实际端口：Linux 默认取当前用户端口段的 `start + 5`，占用时只在本用户段内漂移；Windows / macOS 保留 `3080` 为兼容首选并允许统一漂移。最终端口通过 `GENARRATIVE_AGC_VITE_PORT` 传给 `beforeDevCommand` 和配套后端端口解析器，通过 Tauri CLI 动态 `build.devUrl` 配置传给 WebView，并通过 Vite CLI `--port` 启动严格监听；Vite 继续使用 `strictPort`，任何一层都不得自行改到另一个端口。AGC 配套后端的 `backend` 模式启动 SpacetimeDB、独立 `bgfilter-worker` 和 `api-server`，并在复用现有后端前同时检查三者状态及 `/v1/ping`、`/readyz`、`/healthz`；worker 缺失时不得把不完整的 API/数据库组合误判为 ready。启动器在创建原生窗口前预检最终地址；若竞态中该地址被 AGC Vite、无响应监听器或其它服务占用，一律失败关闭，不复用、也不擅自终止无法证明归属的进程。
+AI 游戏创作客户端使用 `npm run agc`。该入口由 `apps/ai-game-creator-shell/scripts/start-tauri-dev.mjs` 解析 AGC Vite 实际端口：Linux 默认取当前用户端口段的 `start + 5`，占用时只在本用户段内漂移；Windows / macOS 保留 `3080` 为兼容首选并允许统一漂移。最终端口通过 `GENARRATIVE_AGC_VITE_PORT` 传给 `beforeDevCommand` 和配套后端端口解析器，通过 Tauri CLI 动态 `build.devUrl` 配置传给 WebView，并通过 Vite CLI `--port` 启动严格监听；Vite 继续使用 `strictPort`，任何一层都不得自行改到另一个端口。AGC 配套后端的 `backend` 模式启动 SpacetimeDB、独立 `bgfilter-worker` 和 `api-server`，并在复用现有后端前同时检查三者状态及 `/v1/ping`、`/readyz`、`/healthz`；worker 缺失时不得把不完整的 API/数据库组合误判为 ready。任一配套服务在启动阶段进入 `failed` 时，外层启动器必须立即报告具体服务和退出原因，不能继续等待前端地址超时。端口健康不等于归属正确：复用前还必须证明端口上的监听进程属于当前工作树（Windows 按 `server-rs/target/debug/api-server.exe` 绝对路径与 SpacetimeDB `--data-dir` 校验，探测不可用时退化为旧行为），无法证明归属时一律不复用，改为启动本工作树自己的后端并在需要时端口漂移；否则上个工作树 Ctrl+C 残留的后端会被当成自己的后端复用，改了数据库的工作树会连到旧库。启动器在创建原生窗口前预检最终地址；若竞态中该地址被 AGC Vite、无响应监听器或其它服务占用，一律失败关闭，不复用、也不擅自终止无法证明归属的进程。

-Tauri `beforeDevCommand` 默认与客户端构建并行，不能把上述检查只放在 `beforeDevCommand` 内：选定地址上若已有旧 Vite，Tauri 可能先创建加载旧前端的窗口，随后配套后端才因代理不匹配退出。外层启动器会把 Tauri CLI 放入受控进程树；CLI 正常退出、启动失败或收到终止信号后，POSIX 先向保留的 PGID 发送 `SIGTERM`、有界等待后升级 `SIGKILL`，Windows 使用 `taskkill /PID <pid> /T /F`。Linux 容器中的孤儿后代退出后可能暂时保留为 zombie，`kill(-PGID, 0)` 仍会返回成功；启动器必须结合 `/proc/<pid>/stat` 判断同组是否还存在非 zombie 成员，不能把等待 PID 1 回收误报为清理失败。配套后端和 Vite 仍由 `start-dev-stack.mjs` 各自持有，退出时同样有界收束，避免只剩客户端、Runner、Cargo 或旧订阅进程。排障时同时核对控制台输出的 AGC Vite 实际地址及其 marker、`.app/dev-stack.json` 的实际 API URL 和进程 cwd；不要把“终端已返回”当成客户端及其 Runner 已退出的证据。
+Tauri `beforeDevCommand` 默认与客户端构建并行，不能把上述检查只放在 `beforeDevCommand` 内：选定地址上若已有旧 Vite，Tauri 可能先创建加载旧前端的窗口，随后配套后端才因代理不匹配退出。外层启动器会把 Tauri CLI 放入受控进程树；CLI 正常退出、启动失败或收到终止信号后，POSIX 先向保留的 PGID 发送 `SIGTERM`、有界等待后升级 `SIGKILL`，Windows 使用 `taskkill /PID <pid> /T /F`。Windows 下每个长驻服务都经 `cmd.exe /d /s /c` 包装层启动，Ctrl+C 会先杀掉包装层（退出码 `0xC000013A`），因此清理不能只看直接子进程是否存活：`taskkill` 对已退出的 PID 只会失败，必须继续按记录下来的根 PID 遍历，并在退出时按本工作树 `api-server.exe` 绝对路径（以及本次自己拉起的 SpacetimeDB `--data-dir`）做一次身份兜底清扫；`scripts/dev-windows-process.mjs` 是这套判定的唯一实现。Linux 容器中的孤儿后代退出后可能暂时保留为 zombie，`kill(-PGID, 0)` 仍会返回成功；启动器必须结合 `/proc/<pid>/stat` 判断同组是否还存在非 zombie 成员，不能把等待 PID 1 回收误报为清理失败。配套后端和 Vite 仍由 `start-dev-stack.mjs` 各自持有，退出时同样有界收束，避免只剩客户端、Runner、Cargo 或旧订阅进程。排障时同时核对控制台输出的 AGC Vite 实际地址及其 marker、`.app/dev-stack.json` 的实际 API URL 和进程 cwd；不要把“终端已返回”当成客户端及其 Runner 已退出的证据。

 Windows 本地 `npm run dev` / `npm run dev:api-server` / `npm run dev:bgfilter-worker` 会用空的 `RUSTC_WRAPPER` / `CARGO_BUILD_RUSTC_WRAPPER` 覆盖 `server-rs/.cargo/config.toml` 里的 `sccache`，从而直连真实 `rustc`。完整栈和 `dev:api-server` 把 API 与 BgFilter worker 作为一个 Rust 重启单元：源码变化时先停两个进程，再先启动并验活 worker、最后启动并验活 API，避免两个 `cargo run` 并发链接同一个 Windows 可执行文件。不要把 wrapper 绕过值写成 `rustc`；Cargo 会按 wrapper 协议调用 `rustc <真实rustc路径> - ...`，最终报 `multiple input filenames provided` 并导致 api-server 无法启动。排查本地启动失败时，先看 dev 日志是否出现该错误，再确认脚本注入的 wrapper 为空。