完成 AGC 直连 Codex 与审核 Skill 工具链
收口首页和项目聊天为唯一 Direct Codex thread 内置五项审核 Skill Pack 与受控 MCP、浏览器及美术工具桥 补齐 Codex Windows 侧车组件、Provider 代理和凭据幂等边界 同步客户端资源投影、交互测试及技术文档
This commit is contained in:
Git Hooks Test
@@ -95,6 +95,66 @@
|
||||
- 运行页已直接移除“测试切片”控制行及其本地播放/序号状态和样式，只保留游戏运行画面、信息展示与数值微调；AppSurface 合同同时锁定该控件不再渲染、对应 CSS 不再存在。
|
||||
- 当前 direct 产物是多文件入口，而历史 `validate_game_html_smoke` 仍按单文件内联 HTML 契约检查；本次 direct 链路不隐藏触发该旧门禁，若要把多文件产物纳入旧门禁需另行设计读取工作区文件的验证契约。
|
||||
|
||||
## 7.1 默认纯转发收口（2026-08-19）
|
||||
|
||||
### 已确认偏差
|
||||
|
||||
- 虽然普通聊天已经调用 `chat_with_game_creator_direct_codex`，`direct_runtime` 仍会在每条消息前自行判断美术、在消息后强制浏览器试玩、二次整改和版本登记。
|
||||
- 这使“你好”“今天多少号”等非项目消息也被包装成游戏交付任务，用户看到了“准备运行当前本地游戏”“静态烟测”等旧 Runtime 痕迹；已有游戏的普通对话同样被强制拖入完整验收。
|
||||
|
||||
### 收口决策
|
||||
|
||||
1. 普通客户端默认链路固定为 `客户端消息 -> 同一项目 Codex app-server thread -> 原样可读回复`。客户端不根据关键词、文件存在性或模型回复推断/决定“新建、续做、生成美术、试玩、修复”。Codex 回合确实改动标准游戏文件后，客户端只按磁盘事实做资源与版本投影，不把投影本身当作另一次创作流程。
|
||||
2. 默认 direct turn 只负责：项目根边界、同线程复用、系统提示词/skills 注入、进程与凭据隔离、协议异常安全错误、消息显示，以及实际文件变更后的确定性客户端投影。它不自动调用陶泥儿生图、浏览器预览、static smoke、二次 LLM 或隐藏返工；没有文件变化的普通聊天不得修改 manifest、revision 或版本。
|
||||
3. Codex 是唯一执行主体：它根据用户消息、系统提示词、工程结构和自身可用工具判断是否聊天、修改已有游戏、创建游戏或执行验证；客户端不得恢复 Supervisor、专业 Agent、harness 或固定游戏流程作为补偿。
|
||||
4. 系统提示词必须清楚区分：非项目问题直接正常回答且不触碰工作区；项目修改按需要读写当前项目；用户明确要求生成/验收时由 Codex自行执行或如实说明工具限制。客户端不以“安全”为由把任意消息重写成生成任务。
|
||||
5. 回归验收至少覆盖同一实际项目中连续发送“你好”“今天多少号”：均不得触发平台美术、预览、试玩、版本登记或文件变更；再发送一个明确项目修改请求，必须仍复用同一 Codex thread 且由 Codex 自行处理，实际变更的 `game/` 文件随后应出现在客户端“游戏代码”和“项目版本”中。
|
||||
|
||||
## 7.2 当前桌面端验收的内置 Codex 侧车 staging 修复（2026-08-20）
|
||||
|
||||
### 现场问题
|
||||
|
||||
- 当前 checkout 执行 `npm run agc` 后，前端 `127.0.0.1:3080`、本地 API `127.0.0.1:8082` 与 SpacetimeDB `127.0.0.1:3101` 均已健康，但桌面壳没有稳定出现。
|
||||
- 原因是 `src-tauri/build.rs` 每次 Cargo 构建都无条件覆盖 `src-tauri/resources/codex/win-x64/codex.exe` 与 `manifest.json`。Tauri dev watcher 将资源写入识别为源码变化，再次启动 Cargo 构建，形成“构建 -> 覆盖约 300 MiB 侧车 -> watcher 重建”的循环。
|
||||
|
||||
### 修复与验收计划
|
||||
|
||||
1. 内置 Codex 侧车继续从锁定的 npm 原生包 stage 到正式 bundle resource，保留版本与 SHA-256 完整性清单；但仅当二进制内容实际变化时复制，且仅当清单文本变化时写入。
|
||||
2. 不取消 `cargo:rerun-if-changed` 对上游侧车与声明文件的监听；上游升级仍必须触发重新 stage，运行时仍拒绝 hash 不匹配的内置可执行文件。
|
||||
3. 真实回归：从干净的本次 AGC dev 进程重启，确认一次必要的首次构建后不再出现连续的 `codex.exe changed` 重建，Tauri 窗口稳定打开；再完成 direct Codex 普通对话与项目修改的客户端验收。
|
||||
|
||||
## 7.3 首页无项目陶泥儿对话收口（2026-08-20）
|
||||
|
||||
### 现场偏差
|
||||
|
||||
- 首页仍保留“做游戏 / 做素材 / 做方案”分类器，并在提交时无条件调用 `create_automatic_local_game_project`。
|
||||
- 因此“你好”“今天多少号”等普通问题也会创建可见 `gameagent-*` 项目，并被前端改写为“初始意图：...”。这既不是用户原话，也违反了“由 Codex 自己理解意图”的直连边界。
|
||||
- 自动创建后再进入项目聊天，页面还会显示“自动执行”“项目总控”等旧 Runtime 产品文案，容易让人误判仍在运行 Supervisor。
|
||||
|
||||
### 收口契约
|
||||
|
||||
1. 首页只保留一个“陶泥儿”输入入口；移除模式选择、首条 `初始意图` 包装和由首页触发的自动项目创建。用户输入及附件说明原样交给独立的 home Codex thread。
|
||||
2. home thread 使用临时、隔离、只读工作区：不绑定用户项目目录、不读取项目 `.agent`、不生成陶泥儿素材、不启动预览/试玩、不登记版本，也不创建可见项目或最近项目记录。客户端在 home thread 期间拒绝所有写入、命令、MCP、权限扩大和文件变更审批。
|
||||
3. Codex 是唯一意图判断者。普通问题直接回复；当它判断用户明确要开始游戏创作时，只能返回一个受限的“请求创建工作区”动作，客户端据此展示创建入口或进入既有新建项目流程。前端不得重新按关键词分类或自行创建目录。
|
||||
4. 当前项目工作台继续复用 project-bound direct Codex thread，可读写当前项目；其产品文案统一使用“陶泥儿”“智能创作”，不显示“项目总控”“自动执行”“Supervisor”或“专业 Agent”。旧 Runtime 只保留在开发诊断入口。
|
||||
5. 首页回归必须至少覆盖“你好”“今天多少号”和显式“做一个三消游戏”：前两项只产生 home direct turn、没有项目/美术/预览/版本副作用；第三项由 Codex 的受限创建请求触发，而不是由客户端关键词分类触发。真实桌面端需从当前 checkout 逐项验证。
|
||||
|
||||
### 实施补强
|
||||
|
||||
- 创建协议只接受回复原始第一行精确为 `[[AGC_CREATE_PROJECT]]`（可使用 CRLF）；前置空白、解释前缀、第二行标记或标记后拼接其它字符一律只是普通回复，不能创建项目。
|
||||
- `DirectHome` 的 app-server 连接池身份独立于可写项目会话；`thread/start` 固定 `approvalPolicy=never` 与 `sandbox=read-only`，`turn/start` 不发送可写 `sandboxPolicy`。任何 file-change、command、MCP 或审批 item 均失败关闭。
|
||||
- 已移除旧 `create_automatic_local_game_project` 的 Tauri 前端 handler；首页和普通 WebView 即使被错误调用也不能绕过 Codex 的受限创建请求直接落盘。
|
||||
- 首页附件以独立结构化参数传入：用户正文保持原样，编辑器附件占位符不得混入正文；仅补充有界的文件名、媒体类型和字节数，不传本地路径、二进制内容或浏览器 `File` 对象。允许只发附件说明；home Codex 只能理解元数据，创建工作区并经用户确认后才由既有导入流程读取实际附件。
|
||||
|
||||
## 7.4 真实项目验收发现的 Codex 原生组件闭包（2026-08-20）
|
||||
|
||||
- 真实创建项目时，Codex 0.147.0 能启动 app-server，但首轮文件修改明确失败为缺少 `codex-code-mode-host.exe`；项目只有初始化占位页，未生成游戏。
|
||||
- 根因是旧 staging 只复制 `bin/codex.exe`，没有保留同版本 npm 原生包依赖的 code-mode host、`rg`、command runner、sandbox setup 和 `codex-package.json` 相对布局。
|
||||
- Windows x64 内置资源现按固定白名单 stage 完整原生组件闭包；清单升级为 `genarrative-codex-sidecar.v2`，逐文件记录并校验 SHA-256，Tauri resources 保持 `bin/`、`codex-path/`、`codex-resources/` 布局。API Key、登录状态和用户配置仍不进入安装包。
|
||||
- 同次真实验收还发现 direct 项目页的可访问名称残留“项目总控”；视觉文案虽已是“陶泥儿”，读屏仍会暴露旧产品模型。direct 分支现统一使用“陶泥儿项目对话 / 陶泥儿消息 / 陶泥儿实时回复 / 陶泥儿对话内容”，旧名称只保留给显式 legacy 诊断入口。
|
||||
- 修复后同一客户端已真实写入 `game/index.html`、`game/style.css`、`game/game.js`。客户端必须继续把这次真实文件变化确定性登记为游戏代码和项目版本；该步骤不启动 Supervisor、harness、平台美术或二次 LLM。
|
||||
- direct 产品入口的显式“播放”只做用户授权、本地路径/权限边界和预览服务器启动，不再先执行旧 `game.static_smoke` 的 Canvas-only 形态合同；DOM、Canvas、WebGL 及外链 `game.js` 均可进入客户端运行视图。显式 legacy `/smoke` 与旧诊断入口仍保留原严格检查，不能冒充真实浏览器试玩。
|
||||
|
||||
## 8. 陶泥儿美术闭环与资源分类收口（2026-08-16）
|
||||
|
||||
### 问题
|
||||
@@ -245,3 +305,58 @@
|
||||
2. 若本机目录预检失败，客户端返回稳定的“本机开发者凭据存储目录未安全初始化；未创建远端凭据”分类，不请求远端创建接口、不发起美术生成、不写 operation 或账本，也不刷新登录态或自动重试。
|
||||
3. 远端响应后原子写入仍可能因并发或磁盘故障失败；该极窄路径必须单独分类为“凭据已创建但未能安全保存”，提示用户在账户开发者凭据页面撤销后再试，不能自动创建第二把凭据。诊断和正式 UI 只展示上述安全摘要与恢复建议，不包含 access token、开发者凭据、响应正文、绝对路径或签名 URL。
|
||||
4. 验收先在当前失败项目上恢复：对遗留的空且 owner 不匹配目录做可恢复隔离后，再复用同一项目发送“继续完成此前三消游戏”。成功标准包括本机私钥存在但不读取其内容、平台素材与版本登记完成、desktop/mobile Chromium 试玩证据和隔离进程恢复；此前已创建但无法恢复的远端孤儿凭据作为明确剩余风险，绝不自动撤销。
|
||||
|
||||
## 14. 审核 AGC Skill Pack、按需加载与真实工具内核（2026-08-20）
|
||||
|
||||
### 14.1 目标架构
|
||||
|
||||
普通项目链路固定为 `薄 Runtime + Codex 唯一执行 + 按需 Skill + 真实工具`。Runtime 不再通过关键词、固定步骤或产物字符串计数替 Codex 判断用户意图，也不恢复 Supervisor、专业 Agent 或 harness；它只负责工作区、凭据、不可逆副作用、进程协议和确定性客户端投影。
|
||||
|
||||
系统提示词只保留最小核心约束、当前项目文件的有界快照和一份审核 Skill 索引。不得再把项目中的 `.codex/skills`、`.agents/skills`、`.hermes/skills` 全文批量拼入 64 KiB 提示词，也不得把主站全部 Skill 复制给普通游戏项目。完整 `SKILL.md` 与直接引用文件由 Codex 原生 Skill 机制在命中意图后按需读取。
|
||||
|
||||
### 14.2 审核索引与五类 Skill
|
||||
|
||||
客户端内置 `agc-skill-pack.v1` 清单。每项只公开名称、用途、触发条件、所需工具、版本和内容 SHA-256；启动时逐文件复核清单和编译进客户端的内容，任何缺失、额外文件、路径越界或指纹不匹配都失败关闭。审核包只包含：
|
||||
|
||||
1. `agc-project-structure`：项目根、`game/`、`assets/`、`.agent/` 的职责和禁止创建平行项目的约束。
|
||||
2. `taonier-art-assets`：陶泥儿标准美术包、平台来源、警告语义和真实素材使用；`grid-2x2` 与四切片只是推荐路径，不是所有游戏的完成门。
|
||||
3. `agc-web-game-development`：根据当前需求自由选择 DOM、Canvas 或 WebGL，并完成可玩的 HTML/CSS/JavaScript 实现。
|
||||
4. `agc-browser-playtest`：调用客户端提供的真实双视口浏览器工具，读取截图、控制台、网络、Canvas/WebGL 和交互证据后自行修复。
|
||||
5. `agc-client-projection`：解释客户端如何按磁盘事实投影代码、素材、revision 和版本；Codex 不直接伪造或改写 manifest 中的平台身份。
|
||||
|
||||
`genarrative-external-editor-api` 的异步、凭据、operation 和 warning 语义经审核后融入 `taonier-art-assets`；不把原始主站技能目录直接暴露给游戏项目。`gpt-image-2-apimart` 只有在对应受控工具真正配置时才能作为显式备用能力，首版不以文字假装可用。`genarrative-play-type-integration`、SpacetimeDB、微信支付和其它主站工程 Skill 明确排除。
|
||||
|
||||
### 14.3 渐进加载实现
|
||||
|
||||
DirectProject app-server 启动前，把上述审核包安装到本次隔离 HOME 的 `.agents/skills/`；DirectHome 不安装项目创作 Skill，也不暴露项目工具。Codex 首轮只得到五项元数据和索引，不得到完整正文；触发后由原生 Skill 读取对应 `SKILL.md`，引用最多一层且只能命中清单文件。项目内任意 Skill 不再由 AGC 提示词构建器主动读取或拼接。
|
||||
|
||||
Skill 包版本与内容指纹参与 DirectProject app-server 连接池身份。客户端升级或 Skill 内容变化后必须建立新进程/新 thread，不能复用旧目录中的过期 Skill；同一版本的连续聊天仍复用同一 Codex thread。
|
||||
|
||||
### 14.4 真实工具与安全边界
|
||||
|
||||
DirectProject 仅配置客户端自身的本地 stdio MCP，首版暴露三个受控工具：
|
||||
|
||||
- `agc_read_skill_resource`：只读取审核清单中某个 Skill 直接声明的一层 `references/*.md`；不接受绝对路径、`..`、未声明文件、主站 Skill、项目文件或宿主文件。它补足禁用通用 shell 后的渐进引用读取能力，不扩大工作区权限。
|
||||
- `taonier_prepare_game_art`：按 Codex 提供的游戏 brief 创建或恢复陶泥儿标准美术包。工具内部继续使用当前 External v1 请求、持久生成账本、稳定幂等键和 `operationId`；未知提交只轮询或以原请求/原 key 恢复，绝不因模型重试重新扣费。完整可信图集缺切片时返回 warning 并保留完整图集，不能伪造切片或阻断后续代码实现。
|
||||
- `agc_browser_playtest`：由当前客户端启动 loopback 预览和受限 Chromium，对 desktop/mobile 采集真实截图、页面状态、控制台异常、失败请求、Canvas/WebGL 图片使用与有限交互探针，并把结构化证据和截图作为工具结果返回 Codex。该工具不使用旧固定玩法 harness。
|
||||
|
||||
MCP 子进程复用当前客户端二进制的专用无窗口模式，从工作目录取得唯一项目根；命令行不传项目路径或凭据。它只处理 MCP 和审核引用读取；真实浏览器与付费美术通过随机 loopback 地址回到持有项目上下文的客户端主进程执行，避免 Codex 隔离用户环境阻断 Chrome，也避免把 GUI 登录态复制给子进程。陶泥儿开发者 Key 只由客户端主进程按受信任 origin 从当前用户私有文件读取并在内存中使用，不进入 Codex 环境变量、系统提示词、argv、项目文件、日志或工具结果。凭据缺失时工具返回可行动的“先在客户端登录并准备本机开发者 Key”，不得假装生成成功。
|
||||
|
||||
DirectHome 继续禁用 MCP、命令和写入。DirectProject 仍禁用通用 shell、任意网络和多 Agent；文件修改只走 Codex 受限原生能力，外部副作用只走上述本地工具。付费生成、路径权限、文件事务、图片下载/解码、来源身份和客户端投影继续由确定性代码守住。
|
||||
|
||||
### 14.5 验收合同
|
||||
|
||||
- Rust 单测：清单五项精确、SHA-256 匹配、路径无越界；新项目没有本地 Skill 目录仍能安装审核包；DirectHome 不安装；项目中的主站/SpacetimeDB/支付 Skill 不进入系统提示词。
|
||||
- 提示词测试：普通问候只包含索引，不包含任一完整 Skill 正文；美术 Skill 正文由 Codex 原生触发读取；API Key、Bearer、auth.json、宿主绝对路径不进入上下文。
|
||||
- fake app-server：DirectProject 配置本地 MCP 且 DirectHome 保持 `mcp_servers={}`；连续回合复用 thread；MCP item 可完成而不是被当成协议违规；无 Supervisor/child/harness。
|
||||
- MCP 协议测试：initialize、tools/list、tools/call 均为有界 JSON-RPC；未知工具、路径越界、缺凭据明确失败；美术调用复用同一账本/operation，不重复提交；浏览器调用返回双视口真实报告和截图内容。
|
||||
- 回归：typecheck、AppSurface、Rust 定向与完整串行测试、编码检查、rustfmt 和 diff check 全部通过。
|
||||
- 真实客户端：从当前 checkout 新建项目，由同一项目 Codex thread 自主选择陶泥儿美术 Skill、调用真实平台工具、写入游戏、调用真实浏览器试玩并按证据修复；客户端最终显示平台美术、游戏代码和项目版本。单独验证“你好”“今天多少号”不调用美术或浏览器工具、不改文件、不登记版本。
|
||||
|
||||
### 14.6 当前实施与验收状态（2026-08-20）
|
||||
|
||||
- 五项审核 Skill 已由版本化清单和逐 Skill SHA-256 编译进客户端；DirectProject 初始化后显式调用 `skills/extraRoots/set` 与 `skills/list`，缺项或解析错误直接失败。DirectHome 不安装该包。项目内 `.codex/.agents/.hermes` Skill 正文不再被系统提示词批量拼接。
|
||||
- 本地 `agc_tools` MCP 已实际暴露 `agc_read_skill_resource / taonier_prepare_game_art / agc_browser_playtest` 三项工具并固定自动审批；引用读取严格限制为清单内一层 Markdown。真实 `gpt-5.6-sol max` 回合已读取 `agc-project-structure` 的直接引用并正确返回路径边界。
|
||||
- 浏览器和美术副作用由随机 loopback 工具桥回到客户端主进程；真实 Codex 工具调用已得到 desktop/mobile `readyState=complete`、整体 `passed=true` 与 2 张截图。普通“你好，今天多少号”真实回合只回答日期，游戏文件、manifest、revision 均未变化。
|
||||
- 开发网关会在 API Key Responses 成功响应中附带 `X-Codex-*` ChatGPT 额度头；隔离 app-server 会把它误判为余额 0。Direct conversation 现经只接受 Bearer `/responses` 的 loopback 流式代理转发，并剥离该组账户头；真实回合从 `usage-limit-exceeded` 恢复为完成。旧 ToolHost 不经过此代理。
|
||||
- 真实陶泥儿美术调用已到达本地 External v1，但现有唯一私有 Key 绑定 `127.0.0.1:8082` 且在当前恢复的本地数据库中已失效，服务端明确返回 401；未创建生成账本、operation 或素材，也未发生重复提交。按照凭据安全合同，客户端不会自动覆盖旧文件或创建第二把 Key。完成真实生图仍需用户在动作时确认撤销/轮换该本机开发者 Key，然后复跑同一 Codex 工具调用。
|
||||
|
||||
@@ -4773,3 +4773,17 @@
|
||||
- 原因：测试代码仅为动态生成 RSA fixture 引入 `openssl` dev-dependency，从而把原本使用纯 Rust 加密实现的 crate 额外绑定到本机原生 OpenSSL 工具链；Strawberry 附带的库面向 MinGW，不等于可用的 MSVC OpenSSL SDK。
|
||||
- 处理：测试优先使用明确标记、只供测试的固定 PEM fixture，并继续通过项目自身的密钥解析与签名验证路径覆盖真实行为；不要仅为生成 fixture 引入系统原生库，也不要把 MinGW OpenSSL 路径写入 `OPENSSL_DIR` 冒充 MSVC 依赖。
|
||||
- 验证：运行目标 crate 的 `cargo tree -i openssl-sys --target all` 确认依赖已退出，再执行包含测试目标的 `cargo test --tests`，不能只用不会编译 dev-dependency 的 `cargo check --lib` 代替。
|
||||
|
||||
## 隔离 Codex app-server 会误吃代理的 ChatGPT 额度头（2026-08-20）
|
||||
|
||||
- 现象：同一自定义 Responses endpoint 和 API Key 直接 HTTP 为 200，普通用户 HOME 下的 smoke 也完成，但隔离 `CODEX_HOME/HOME` 的 app-server 在真正发请求前返回 `usageLimitExceeded`，并投影 credits balance 0。
|
||||
- 原因：开发网关把 `X-Codex-*` ChatGPT 账户额度头附在 API Key Provider 响应上；隔离进程没有用户 ChatGPT 额度状态覆盖，Codex 0.147 将这些头当作本地账户限制。模型、Key、MCP 和 Skill 均不是根因。
|
||||
- 处理：只为 Direct conversation 启动随机 loopback `/responses` 流式代理；它不注入 Authorization，只转发请求自带 Bearer，拒绝其它方法/路径并剥离 `X-Codex-*` 账户头。不要复制用户 `auth.json` 来掩盖问题，也不要把 Provider 切换当根因修复。
|
||||
- 验证：同时记录上游直接 200、未过滤时 credits=0/usage-limit、过滤后真实 turn completed；代理测试必须证明无 Bearer 拒绝、路径收窄、正文流式保留和额度头不下传。
|
||||
|
||||
## Codex MCP 子进程不适合直接启动桌面浏览器（2026-08-20）
|
||||
|
||||
- 现象：同一 `agc_browser_playtest` 在普通进程中能返回双视口截图，但从 Codex 启动的 STDIO MCP 子进程调用时 Chrome 启动超时。
|
||||
- 原因：MCP 子进程继承隔离 HOME/AppData 和 Codex 进程约束；把真实浏览器或 GUI 登录态硬塞给子进程既不稳定，也扩大凭据边界。
|
||||
- 处理：STDIO MCP 只做 schema 与协议适配；浏览器和付费美术通过随机 loopback 工具桥回到持有项目、登录态和正常桌面环境的客户端主进程。桥只绑定当前项目、限制请求大小和审核工具名，返回脱敏文本与有界 PNG。
|
||||
- 验证：必须从真实 Codex thread 发起 MCP 调用并观察 desktop/mobile `readyState=complete` 与两张截图；直接运行 MCP 二进制成功不能替代该链路。
|
||||
|
||||
@@ -113,6 +113,7 @@ Supervisor 认领该回执后，由父 run 自己为每个原 delivery 逐一创
|
||||
|
||||
- 模式合同：客户端 AppData 配置新增全局 `agentMode`，只接受 `codex_cli / provider`。缺省和新安装默认使用 `codex_cli`，原有 HTTP LLM Provider 路径完整保留并可显式切回 `provider`；切换只影响下一次节点请求，不新增 Runner、任务图、会话库、配置库或业务事实源。
|
||||
- 调度边界：正式 DAG、manifest、Agent task/session/run 身份、队列、锁、委派、all-join、完成门、Provider lifecycle、持久 retry/handoff 与 `needs-reconciliation` 继续由现有 AGC Runtime 掌控。每个被调度节点在 `codex_cli` 模式下直接启动一次非交互 `codex exec` 充当该节点的推理 Agent；Codex 返回当前 Runtime 广告函数的结构化调用，Runtime 仍是唯一 ToolHost，不允许 CLI 自己写项目、执行命令、调用 MCP 或形成第二套 revision / verification 真相。
|
||||
- 安装包侧车：Windows x64 release 固定随 Tauri resource 打包 `@openai/codex@0.147.0` 的原生 `codex.exe`；Rust build script 从 AGC 子包锁定依赖 stage 到 resource，并写入版本与 SHA-256 清单。运行时只在文件摘要和 `codex-cli` 版本同时匹配清单时优先选内置侧车；缺失、损坏或版本漂移时跳过它，按既有 npm 安装、PATH 顺序回退。安装包同时携带 Apache-2.0 第三方声明；API Key、`auth.json`、Cookie、Token、用户 `CODEX_HOME`、用户配置和项目数据绝不打包。
|
||||
- CLI 安全边界：CLI 固定使用 argv 启动，禁止 shell 拼接；工作目录使用本次请求专用的空临时目录，不把游戏项目绝对路径写入 prompt、stdout、stderr 或持久记录。调用固定使用 ephemeral、忽略用户配置和 exec rules、read-only sandbox、never approval，并关闭 Codex shell tool；只继承 CLI 运行和认证所需的最小环境，显式移除宿主 `CODEX_API_KEY`。用户级 Codex 登录态继续由本机 Codex 自己读取，API Key、auth 文件、Cookie、Token、`CODEX_HOME` 私有内容不得复制到项目配置、Runtime sidecar、Agent DB、conversation 或日志；stdout / stderr 无换行时也受硬上限约束，stderr 诊断只记录固定分类、字节数和 SHA-256。
|
||||
- 协议边界：Runtime 把既有 `LlmRunRequest` 的消息和当前函数目录编码为有界 prompt，并从同一函数 JSON Schema 生成 Codex structured-output schema。CLI 输出转换为现有 `LlmRunResponse / LlmToolCall` 后，继续经过 native tool / MCP 参数校验、动作上限、权限、pending、receipt、验证与格式修复链；最终回复仍走现有脱敏和唯一提交路径，不新增平行响应协议。
|
||||
- 取消与恢复：Codex 子进程绑定当前 Provider request lifecycle，取消、暂停、Runner draining 或 GUI owner 丢失时终止并回收当前进程；started 后没有可信终态仍沿现有 Provider reconciliation 处理。`agentMode`、CLI 可执行身份和影响输出的 Codex 参数进入 `providerConfigFingerprint`，模式切换不得消费另一模式遗留的 retry/handoff。
|
||||
@@ -1086,6 +1087,14 @@ game-project/
|
||||
- 发布 GUI 内的 Codex CLI 可用性探测（包括候选版本检查和 `app-server --help`）必须与实际 Codex、MCP、Runner 和项目命令一样使用 `CREATE_NO_WINDOW`；读取对话或配置状态时即使连续探测多个候选，也不能创建或闪烁控制台窗口。
|
||||
- Node ESM 脚本必须用 `fileURLToPath()` 把 `import.meta.url` 转为 Windows 本地路径，禁止直接把 URL pathname 交给 `path.resolve()`；真实 agent-run smoke 的浏览器探测覆盖 Windows Chrome/Edge 固定安装位置。开发态 smoke 在旧安装版持有默认 AppData GUI owner 时使用独立 `--config-dir`，不得终止用户现有客户端。
|
||||
|
||||
## 2026-08-20 Direct Codex 审核 Skill Pack 与受控工具内核
|
||||
|
||||
- 普通项目对话只由一个 project-bound Codex app-server thread 执行。客户端系统提示词只放最小工程合同、当前游戏源码有界快照、项目 prompts 和审核 Skill 索引；不再批量读取项目 `.codex/.agents/.hermes` Skill 正文，也不恢复 Supervisor、专业 Agent 或 harness。
|
||||
- `agc-skill-pack.v1` 只包含项目结构、陶泥儿美术、Web 游戏实现、真实浏览器试玩、客户端资源投影五项 Skill。清单记录用途、触发条件、所需工具、版本和内容 SHA-256；客户端把审核文件安装到隔离目录后通过 app-server `skills/extraRoots/set + skills/list` 注册并复核，完整正文由 Codex 原生 Skill 机制按意图加载，一层引用只能经 `agc_read_skill_resource` 读取清单内 Markdown。
|
||||
- DirectProject 只连接客户端内置的 `agc_tools` STDIO MCP，工具固定为审核引用读取、标准陶泥儿美术准备和 desktop/mobile 浏览器试玩。MCP 进程只做协议；真实浏览器和付费 External v1 调用通过随机 loopback 地址回到客户端主进程，因此不复制 GUI 登录态、开发者 Key 或项目路径到模型上下文。三项工具固定自动批准，通用 shell、任意网络、多 Agent、插件和外部 MCP 继续关闭。
|
||||
- 陶泥儿生成继续复用既有私有 Key、持久幂等账本、operation 恢复、来源/下载/PNG 解码和 manifest 登记。完整可信图集缺切片可以继续，固定四切片只是推荐路径；凭据失效、来源不明或结果未知时失败关闭，不能自动换 Key 或重新扣费。
|
||||
- 自定义 LLM API Key 路由只在 DirectHome/DirectProject 经 loopback `/responses` 流式代理转发。代理不注入 Key，只要求请求自带 Bearer，并剥离开发网关错误携带的 `X-Codex-*` ChatGPT 账户额度头，防止隔离 app-server 把 API Provider 误判为余额 0；旧 ToolHost 保持原 Provider 行为。
|
||||
|
||||
- 2026-08-12 计划拒绝恢复：结构化 `runtime.plan_update` 被 Runtime 拒绝后，下一轮 Provider 请求按请求级目录收窄到实际项目 mutation 与 `respond_to_user`（已进入协作编排的 Supervisor 保留 `agent.delegate / agent.run_status`），并明确禁止再次规划、读取、搜索或验证；后续已有真实 mutation observation 后解除临时目录，不改变持久 executable policy。
|
||||
|
||||
- Goal Contract 绑定 project、可信根 Run Profile、source task SHA-256 和不可变 fingerprint；同一根 Run 只允许幂等重放完全相同的合同，语义变化必须进入新根 Run。已有合同的根 Supervisor 收到 steer 时，Runtime 必须按旧 rootRunId 串行化转换并在持锁后重验 Session 当前权威 Run，再取消并确认旧 rootRunId 的静态、ready、isolated 整棵树已进入终态或 `needs-reconciliation`；旧树未停稳时拒绝启动 replacement，停稳后才在同一 Session、source 和 Run Profile 创建唯一的新根 Run，不能把新增要求塞进旧合同继续完成。合同摘要作为 `decision` 投影到共享黑板，JSON sidecar 才是权威源；黑板冲突条目和专家事实仍追加保留。
|
||||
|
||||
Reference in New Issue
Block a user