修复AGC无人值守生成阻断的交付收口与验收
- 可信 code-prototype 父 Run 认领并观察直属美术 delivery,普通失败立即收束,合法安全默认 marker 由 Runtime 确定性执行唯一同合同返工 - 补齐 suppressed 无 child 与父身份链丢失时的 completion 失败关闭边界 - 修复 Windows project.lock delete-pending 竞争并收紧 HTML 内联 JS 语法 fail-open - 同步技术方案、决策记录与实施计划,并完成确定性及真实 Provider 分层验证
This commit is contained in:
@@ -241,7 +241,18 @@ git diff --check
|
||||
- 相关定向测试、类型检查、编码检查和 diff 检查通过。
|
||||
- 使用真实 Provider 的空项目 smoke 成功;若现场外部服务不可用,则代码可以提交为“实现完成、真实现场验收未完成”,不得宣称目标已完全达成。
|
||||
|
||||
## 9. 回滚边界
|
||||
## 9. 实施与验证记录(2026-08-15)
|
||||
|
||||
在 `codex/agc-runtime-generation-reliability` 分支完成:
|
||||
|
||||
- 可信 `code-prototype` 父 Run 可认领并观察直属美术 delivery、按 `delegationId` 精确读取合同;错误 Agent/Run、未知合同与身份篡改统一失败关闭。父 task/chain 无法证明但仍有活跃或已认领 delivery 时 completion 必须 blocked;Suppressed 且未形成 child 的失败前置记录不参与 capability、claim 与 completion barrier。
|
||||
- 普通失败或不合法安全默认 marker 认领后立即收束;合法 `game-chat-safe-default-repair.v1` marker 由 Runtime 直接生成唯一一层、同目标、同合同 `agent.delegate`,repairRequired 状态下重复 route/read/query 被 liveness 门拒绝。
|
||||
- Windows `.agent/project.lock` 不再对最终 `create_new` 目标做 metadata 预检,delete-pending 的 5/32/33 统一进入有界竞争等待;新增 delete-pending 回归,复现真实 `create_new` ACCESS_DENIED 后证明等待可收束。
|
||||
- 验证结果:`game_chat_` 113 通过、`autonomous_completion_contract` 107 通过、`safe_default` 4 通过、`static_smoke` 9 通过、`action_receipt` 10 通过、`project_execution_owner` 8 通过、runner 重启恢复与 Windows 锁回归通过;串行全量 Rust `1856 passed / 0 failed / 15 ignored`(含新增 HTML 内联语法 fail-open 回归);`platform-llm` 与 `agent-runtime-core` 全绿;前端 typecheck、`check:encoding`、`git diff --check`、变更文件 `rustfmt --check` 通过。
|
||||
- 真实 `gpt-5.6-sol / reasoningEffort=max` 隔离轮次:14 个 Provider 请求全部完成并闭合,无确认、追问、steer、路径/密钥/正文泄漏,Runner 与后代进程清理为零残留;在未配置 External Editor 的边界下 art-director 失败后由主 Run 认领并快速明确收束,未再次空转。
|
||||
- 待完成:用有效 External Editor 配置跑一轮完整 playable 真实验收;当前结果不能宣称现场完整生成已通过。
|
||||
|
||||
## 10. 回滚边界
|
||||
|
||||
- 默认路由可回退到原 `project-supervisor-gui`,但不能同时保留两套普通入口形成随机分流。
|
||||
- 自动权限只由可信 source + root profile + binding fingerprint 共同启用;回滚时删除该窄例外,不修改全局策略默认值。
|
||||
|
||||
@@ -1,5 +1,28 @@
|
||||
# 决策记录
|
||||
|
||||
## 2026-08-15 AGC game-chat 主代码 Run 接管直属美术 delivery
|
||||
|
||||
- 背景:真实 `gpt-5.6-sol / max` 验收中,`art-director` 失败后已形成 `ready + needs-repair` delivery,但认领、合同读取、claim observation 和完成 blocker 均硬编码为 Supervisor-only;实际直属父 Run `code-prototype` 无法消费回执,随后又发起 29 次 Provider 请求。
|
||||
- 决策:保留原 Supervisor 能力,并把 delivery 管理权限窄扩展给身份链完整的当前可信 game-chat `code-prototype` 父 Run。Runtime 在存在 ready 回执时确定性执行 `agent.run_status(scope=self)`;claim 未完整 Observed 前不请求 Provider;普通失败或不合法 marker 认领后立即终止。完整 `game-chat-safe-default-repair.v1` marker 不再交回 Provider 决策,而是由 Runtime 按原 Agent、原合同和原 delegationId 直接生成唯一一层 `agent.delegate`;repairRequired 状态的重复 route/read/query 由 liveness 门拒绝。
|
||||
- 安全边界:权限必须同时证明 game-chat 根 source/profile、root/parent/child task、父 binding fingerprint、delivery parent/session/run、delegationId 和目标 Agent;Agent ID、任务正文或错误关键词不能授权。身份损坏时 capability、run status 和 completion gate 全部失败关闭;父 task/chain 无法证明但仍有活跃或已认领 delivery 时也必须 blocked,不能静默当作“不适用”。Suppressed 且未形成 child 的失败前置记录不再参与 capability、claim 或 completion barrier,以保留同 action reopen / 新 action 重试语义。`code-prototype` 只能管理内部 delivery,正式用户 assistant 与根 completed 投影仍只允许根 `project-supervisor`。
|
||||
- 验证方式:覆盖合法认领与合同精确读取、错误 Agent/Run/delegation 拒绝、delivery 身份篡改阻断、唯一安全默认返工、普通失败零后续 Provider lifecycle,以及新的真实 Provider 空项目轮次。顺带收紧 `validate_executable_inline_javascript_syntax`:正文游离 `<` 不再吞掉后续 `<script>`,未闭合或非标签状 `<` 继续扫描,避免后置脚本被静默跳过语法校验。
|
||||
- 关联文档:`docs/technical/【技术方案】AI游戏创作Agent Runtime V1.1-2026-07-12.md`、`docs/technical/【技术方案】AI游戏创作智能体App实施计划-2026-06-24.md`。
|
||||
|
||||
## 2026-08-14 AGC 将 reasoningEffort=max 作为独立强度贯通
|
||||
|
||||
- 背景:`gpt-5.6-sol / max` 真实验收预检发现,AGC 与 `platform-llm` 只接受到 `high`;同时 canonical Agent 会先用角色默认强度覆盖全局值,空 `agentLlm` 不能证明实际请求使用 `max`。
|
||||
- 决策:新增独立 `max` 枚举和 wire 值,贯通配置、Provider 适配、Codex 映射、请求指纹、前端类型与配置检查;禁止把 `max` 静默映射成 `high` 或 `x-high`。本轮真实验收使用 `agentMode=provider`,并为 Supervisor、主代码 Agent 和两个条件美术 Agent 显式设置 `max` 覆盖。
|
||||
- 验证方式:定向验证配置解析、Responses 请求 JSON、Provider 双向适配和 Codex effort;真实 E2E 报告必须同时绑定 `providerModel=gpt-5.6-sol`、`providerReasoningEffort=max`、`providerApiKind=openai_responses` 与 endpoint SHA-256。
|
||||
- 关联文档:`docs/technical/【技术方案】AI游戏创作智能体App实施计划-2026-06-24.md`。
|
||||
|
||||
## 2026-08-14 首份结构化计划完整替换 legacy 计划脚手架
|
||||
|
||||
- 背景:真实 Luna 无人值守轮次在 revision 2 的 `game.static_smoke` 失败后,于同一 `code-prototype` Run 成功 patch 到 revision 3,但没有重新验证。取证确认 smoke 失败发生在 `planRevision=0` 阶段,Runtime 先把 legacy 活动步骤标为 `failed`;随后首份结构化 `planUpdate` 错误保留该 legacy 终态,game-chat 快车道因“结构化计划含 failed 步骤”在读取当前 revision 门禁前终止。
|
||||
- 决策:`planRevision=0 -> 1` 是 legacy 到 structured 的一次性迁移边界。第一次有效结构化更新完整替换 legacy `plan / planSteps / activePlanStepIndex`,不继承任何 legacy `completed / failed` 脚手架步骤;只有函数入口处已经存在结构化计划时,才合并并保护历史终态。
|
||||
- 安全边界:已建立结构化计划后的 `completed / failed` 单调与不可改写语义保持不变,普通失败继续 fail-closed;不新增 smoke receipt 特判恢复通道,不放宽项目 revision、static smoke、desktop/mobile 试玩、身份绑定或最终完成门。
|
||||
- 验证方式:覆盖 legacy failed 被首份结构化计划替换、structured failed 仍不可改写,以及 `smoke failed -> structured repair plan -> same-run patch -> current revision smoke recheck`;运行 `structured_plan_`、`game_chat_` 分组和串行 Rust 全量,并以新的独立 `gpt-5.6-sol` / `max` 真实 Provider 空项目轮次取得完整最终证据。
|
||||
- 关联文档:`docs/technical/【技术方案】AI游戏创作智能体App实施计划-2026-06-24.md`。
|
||||
|
||||
## 2026-08-12 Repository checks 采用 CI 与本地共用的单一门禁入口
|
||||
|
||||
- 背景:master run 1037 的 Backend/Frontend 已通过,但 `Repository checks` 因 3 个 `simple-import-sort/imports` 错误失败。原 pre-commit 只运行 Prettier,Prettier 不处理 ESLint import 排序;推送前又未运行完整仓库 lint,因此本地与 CI 的覆盖范围长期存在漂移。
|
||||
@@ -7166,6 +7189,12 @@
|
||||
- HTTP 传输边界:根 H5 包不得依赖 Tauri guest 插件;AGC 独立包保留 `@tauri-apps/plugin-http`。Rust 插件显式关闭默认特性,只启用 `charset`、`cookies`、`http2` 和 `rustls-tls`,避免 `reqwest/system-proxy` 通过 Cargo feature union 把画布、Provider、Runtime 与本地回环夹具统一接入 OS 自动系统代理;如未来产品要求正式客户端继承系统代理,必须按各客户端明确设计并单独完成跨平台验证。
|
||||
- 运行决策:Godot 项目提交给 Project Supervisor 时使用 `standard` Run Profile,避免触发 Web 专用 `game/index.html`、HTTP preview 与自主 Web 完成门。Godot 编辑器启动和内嵌运行预览不在本切片范围。
|
||||
|
||||
## 2026-08-14 AGC Web game-chat fresh-init 真实验收基线
|
||||
|
||||
- fresh-init 决策:`supervisor-game-chat-single-main-playable` 的 disposable 项目只预置 Git、`AGENTS.md`、三份隔离 evidence 与敏感诱饵,不再预写 `package.json`、`verify-e2e.mjs` 或 `game/index.html`;入口必须由正式 `--init` 写入生产 `DEFAULT_GAME_INDEX_HTML`。canonical 副本由无 Provider self-test 与 Rust 常量逐字节比对,防止验收基线静默漂移。
|
||||
- 报告门禁:同一真实 E2E 报告必须记录初始入口 SHA-256,并同时断言初始字节命中生产默认入口、根下唯一固定 child 为 `code-prototype`、最终入口不同于 baseline、`game.static_smoke` 凭证 SHA-256 等于最终入口,以及 desktop/mobile 两个 viewport 各自 passed;任一项不成立均失败关闭。
|
||||
- 范围边界:这条真实 Provider 验收仅覆盖普通 Web 工作台的 `project-supervisor-game-chat + autonomous-game-build` 单 Supervisor 链,不覆盖显式 `professional-dag` 或固定 16 节点 CLI/GUI 链。后者的 owner-artifact verify、产物所有权与 path-scope 仍是独立未解决项;seeded deterministic E2E、普通 self-test 和 game-chat 报告均不得据此声称该问题已修复或该链已通过真实验收。
|
||||
|
||||
## 2026-08-13 AGC 普通 Web 工作台默认单主无人值守生成
|
||||
|
||||
- 决策:项目首页进入的普通 Web 工作台默认 `single-supervisor`,提交固定映射为 `project-supervisor-game-chat + autonomous-game-build`。该决策覆盖此前“普通 GUI autonomous 继续固定完整 DAG”的现行入口规则;固定专业 autonomous DAG 只保留给显式 `professional-dag` 和专业 CLI 验收,Supervisor 调试与 Godot 继续 `standard + project-supervisor-gui`。
|
||||
|
||||
@@ -99,6 +99,8 @@ game-chat 条件快车道采用单主口径。父 Run 与全部 child Run 共用
|
||||
|
||||
失败续跑还必须覆盖同 Session 同 source 继承、跨 Session / 跨 source 不继承、首次与连续 successor 的 effective task / contract / scheduler 一致性,以及中英文纯继续短语使用同一识别函数。非占位入口的新 `code-prototype` 必须先产生本人 mutation 再 smoke;连续只读 smoke 不得收束。占位 fallback 只允许显式支持的真实玩法模板,俄罗斯方块必须验证棋盘、下落、旋转、锁定和消行语义,未知玩法必须失败关闭。
|
||||
|
||||
legacy 计划迁移到结构化计划时以 `planRevision` 为唯一边界:`planRevision=0` 的 `planSteps` 只是 Runtime 脚手架,第一次有效 `planUpdate` 必须完整替换它,即使 legacy 活动步骤已因工具 observation 变成 `completed / failed`;不得把该脚手架终态合并进首份结构化计划。入口处已经存在结构化计划后,后续更新仍必须保留 `completed / failed` 终态,Provider 不得重开失败步骤。修改此边界至少运行 `first_structured_plan_replaces_terminal_legacy_scaffolding_steps`、`structured_plan_failed_step_remains_immutable_after_migration`、真实 smoke 修复序列回归,以及 `structured_plan_`、`game_chat_` 串行分组;最终无人值守结论仍必须来自新的独立真实 Provider 空项目轮次,不能由历史失败轮和本地单测拼接。
|
||||
|
||||
game-chat GUI 恢复还要覆盖两类竞态:root Runtime 先终态、单主 Run 或其必要美术 child 后终态时,必须等到所有必要 delivery 的最终状态后仅持久化一条 `【Supervisor 阶段记录】`;页面初始 hydration 直接读到真实终态时也要补写缺失记录,但不得把 `idle` 当作完成。同时,GUI 启动的 `agent.resume` 自动扫描必须先做只读恢复工作预检:新项目或无 task / retry / handoff / finalization / pending / reconciliation 工作的已终态项目不弹确认,存在任何 durable recovery artifact 则仍必须命中 `agent.resume` policy。
|
||||
|
||||
```bash
|
||||
|
||||
@@ -1080,18 +1080,18 @@ Runtime 只在以下客观条件同时满足时写 `contractStatus=evidence-read
|
||||
|
||||
### 单层 repair
|
||||
|
||||
Supervisor 只有在同一父 run 已认领原 delivery,且原回执为 `needs-repair` 或 Supervisor 明确判定语义未满足时,才能发出新的 `agent.delegate`,并把 `repairOfDelegationId` 指向该原 `delegationId`。被引用记录必须属于同一 `project-supervisor` 父 run、状态为 `claimed-by-parent`,且自身不是 repair;返工目标必须与原 delivery 的专业 Agent 完全一致。
|
||||
当前可信父 Run 只有在已认领同一父 Run 的原 delivery,且原回执为 `needs-repair` 或父 Run 明确判定语义未满足时,才能发出新的 `agent.delegate`,并把 `repairOfDelegationId` 指向该原 `delegationId`。可信父 Run 包括原 `project-supervisor`,以及通过 `project-supervisor-game-chat` 根绑定、父 binding fingerprint 和 task/session/run/delegation 身份链完整证明的唯一 `code-prototype` 主 Run;仅凭 Agent ID、task 文案或错误关键词不得获得该权限。被引用记录必须属于当前可信父 Run、状态为 `claimed-by-parent`,且自身不是 repair;返工目标必须与原 delivery 的专业 Agent 完全一致。
|
||||
|
||||
repair 深度固定为 `1`;同一原 delivery 同时最多存在一个非 `suppressed` repair。相同 durable action/身份重放必须幂等复用已预留或已创建的 repair;不同 action 的重复或并发竞争必须在 delivery 锁内发现既有非 suppressed repair 后拒绝,不能创建第二个活跃目标 run、第二份可认领回执或 `-dup-*` repair。repair 结果继续唤醒、认领并收束到原 Supervisor Session/run;它不能创建第二条面向用户的 assistant。repair 再次 `needs-repair` 时不得继续嵌套委派,Supervisor 只能基于现有证据裁决或走用户输入门禁。`suppressed` repair 不视为已完成返工,原 `repairRequired` 门禁必须继续阻断 finalization;同一 durable action 可以在无终态字段时把原 delivery 恢复为 `dispatched`,若该 action 已持久失败,新 action 也只可在既有 repair 全部 suppressed 时创建替代的基础设施投递,不能形成第二轮语义返工。
|
||||
repair 深度固定为 `1`;同一原 delivery 同时最多存在一个非 `suppressed` repair。相同 durable action/身份重放必须幂等复用已预留或已创建的 repair;不同 action 的重复或并发竞争必须在 delivery 锁内发现既有非 suppressed repair 后拒绝,不能创建第二个活跃目标 run、第二份可认领回执或 `-dup-*` repair。repair 结果继续唤醒、认领并收束到原可信父 Session/run;它不能创建第二条面向用户的 assistant。repair 再次 `needs-repair` 时不得继续嵌套委派,当前可信父 Run 只能基于现有证据裁决或由根 Supervisor 走用户输入门禁。`suppressed` repair 不视为已完成返工,原 `repairRequired` 门禁必须继续阻断 finalization;同一 durable action 可以在无终态字段时把原 delivery 恢复为 `dispatched`,若该 action 已持久失败,新 action 也只可在既有 repair 全部 suppressed 时创建替代的基础设施投递,不能形成第二轮语义返工。已 suppressed 且未形成 child task 的旧 delivery 不再参与 capability、claim 或 completion barrier 的身份验证,避免恢复入口被失败前置记录永久堵死;所有非 suppressed delivery 仍必须逐条通过完整可信链校验。
|
||||
|
||||
Supervisor 认领回执后必须能够再次从 durable delivery 取回权威返工合同,不能依赖首次 `agent.run_status` observation 或模型记忆。普通 `agent.run_status` 要返回有界的 `claimedDelegateContracts` 目录,至少包含 `delegationId / targetAgentId / repairOfDelegationId / contractStatus / acceptanceCriteriaCount / expectedArtifactsCount`;带可选 `delegationId` 查询时,只允许原 `project-supervisor` 父 run 读取属于自己且已 `claimed-by-parent` 的 delivery,并返回未截断的 `delegationId / targetAgentId / acceptanceCriteria / expectedArtifacts / repairOfDelegationId / deliveryStatus / terminalStatus / contractStatus`。该查询是只读、可幂等重放的私有 observation,不返回 task 正文、Provider payload、凭据或绝对路径;合同超过明确有界输出上限时失败关闭,不能截断后让模型猜测。返工被“合同未完整继承”拒绝时,失败 observation 必须携带同一 durable delivery 的完整 `claimedDelegateContract` 权威快照,Supervisor 可直接逐字段据此修正;该字段缺失或身份不确定时才必须按原 `delegationId` 重读,不得重复无目标地轮询状态或从 action history 的摘要反推。
|
||||
当前可信父 Run 认领回执后必须能够再次从 durable delivery 取回权威返工合同,不能依赖首次 `agent.run_status` observation 或模型记忆。普通 `agent.run_status` 要返回有界的 `claimedDelegateContracts` 目录,至少包含 `delegationId / targetAgentId / repairOfDelegationId / contractStatus / acceptanceCriteriaCount / expectedArtifactsCount`;带可选 `delegationId` 查询时,只允许当前可信父 Run 读取属于自己且已 `claimed-by-parent` 的 delivery,并返回未截断的 `delegationId / targetAgentId / acceptanceCriteria / expectedArtifacts / repairOfDelegationId / deliveryStatus / terminalStatus / contractStatus`。该查询是只读、可幂等重放的私有 observation,不返回 task 正文、Provider payload、凭据或绝对路径;合同超过明确有界输出上限时失败关闭,不能截断后让模型猜测。返工被“合同未完整继承”拒绝时,失败 observation 必须携带同一 durable delivery 的完整 `claimedDelegateContract` 权威快照,当前可信父 Run 可直接逐字段据此修正;该字段缺失或身份不确定时才必须按原 `delegationId` 重读,不得重复无目标地轮询状态或从 action history 的摘要反推。
|
||||
|
||||
### Prompt 与完成门禁
|
||||
|
||||
- 专业 Agent 的 task prompt 必须带完整委派合同:`delegationId / task / acceptanceCriteria / expectedArtifacts / repairOfDelegationId`,以及当前 Agent/Session/run 与父 Supervisor 身份;同时明确它只提交内部回执和证据,不直接回答正式用户。
|
||||
- 结构化计划 checkpoint 只有在步骤或状态真实变化时才允许单独提交。当前 `in_progress` 步骤所需事实、权限和合同已经齐全时,Agent 必须在同一 Provider 响应附带具体 action;格式修复也必须保留原本可执行的动作意图,不能连续只改 `explanation` 或反复只调用 `update_agent_plan`。Runtime 的未完成计划 observation 和 `nextStep` 使用同一口径,真实 E2E 对 repair 创建另设有界父 loop 门禁。
|
||||
- Supervisor prompt 必须明确:不得把 `evidence-ready` 当作自动语义通过,不得忽略或吞掉 `needs-repair`;对无法自行裁决的冲突、缺失决策或用户偏好,只能汇总后通过既有 `user.input_request` 向用户提问,专业 Agent 与 child 不得各自直达用户。
|
||||
- finalization 在项目锁内必须确认所有必要 static delivery 已终态、ready 已认领、claim 已 Observed、允许的单次 repair 已收束;同时要求结构化计划全部完成,并清零 verification、pending confirmation、`user.input_request`、process/reconciliation、isolated join、Goal/steer 等既有 blocker。只有原 `project-supervisor` Session/run 可以随后写入唯一正式用户 assistant 和 completed 投影。
|
||||
- 当前可信父 Run 的 prompt 必须明确:不得把 `evidence-ready` 当作自动语义通过,不得忽略或吞掉 `needs-repair`。game-chat `code-prototype` 发现 ready delivery 时必须先以确定性 `agent.run_status(scope=self)` 认领并观察;普通失败或不合法安全默认 marker 在认领后立即失败收束,不得再发 Provider 请求。只有完整合法的 `game-chat-safe-default-repair.v1` marker 允许一次同合同返工;该返工由 Runtime 直接按原 `targetAgentId / acceptanceCriteria / expectedArtifacts / delegationId` 生成确定性 `agent.delegate`,不再请求 Provider 决策。repairRequired 存在时重复 route、读取、查询或其它计划全部由 liveness 门拒绝;第二层返工、目标 Agent 变化、合同扩大或身份漂移全部失败关闭。对无法自行裁决的冲突、缺失决策或用户偏好,只能由根 Supervisor 汇总后通过既有 `user.input_request` 向用户提问,专业 Agent 与 child 不得各自直达用户。
|
||||
- finalization 在项目锁内必须确认所有必要 static delivery 已终态、ready 已认领、claim 已 Observed、允许的单次 repair 已收束;同时要求结构化计划全部完成,并清零 verification、pending confirmation、`user.input_request`、process/reconciliation、isolated join、Goal/steer 等既有 blocker。可信 `code-prototype` 只能管理其绑定的内部 delivery 并收束自身 Run;只有根 `project-supervisor` Session/run 可以写入唯一正式用户 assistant 和根 completed 投影。
|
||||
|
||||
### Provider 多 action 原批次门禁
|
||||
|
||||
|
||||
@@ -8,6 +8,23 @@ Supervisor 认领该回执后,由父 run 自己为每个原 delivery 逐一创
|
||||
|
||||
问题 envelope、问题数量、字段长度和 SHA 校验均 fail-closed;问题正文只在受保护的 Runtime sidecar / 父 run 上下文中流转,不写入公共审计。若合并后的问题超过用户输入上限,Runtime 停止自动提问并进入 reconciliation,等待人工核对。
|
||||
|
||||
## 2026-08-14 真实 Provider 无人值守验收修复计划
|
||||
|
||||
2026-08-14 使用 `gpt-5.6-luna` 的独立真实 Provider 轮次已经证明 Provider 链路可达:7 个唯一请求全部完成,confirmation、user-input、steer 和公开泄漏均为零;但该轮结果为 **FAIL**,不得作为无人值守验收通过证据。`code-prototype` 在 revision 2 的 `game.static_smoke` 得到可修复合同失败后,于同一 Run 成功 `file.patch` 到 revision 3;下一轮却在重跑 smoke 前被本地计划门禁终止,因此没有进入 desktop/mobile `preview.validate`。Supervisor 的 fixed-graph stalled 只是该 child 失败的下游结果。
|
||||
|
||||
根因位于 legacy 计划向首份结构化计划的迁移边界。首轮 smoke 失败发生时 `planRevision=0`,Runtime 把 legacy 脚手架中的活动步骤标为 `failed`;旧 `apply_agent_runtime_plan_update` 又把这个 legacy 终态合并进首份结构化计划,导致修复 mutation 成功后仍被“结构化计划含 failed 步骤”失败关闭。该 `failed` 不属于 Provider 提交的结构化计划,也不应成为后续结构化计划的历史终态。
|
||||
|
||||
本轮按以下最小边界修复,禁止通过增加 loop 预算、删除完成门或把失败步骤普遍视为成功来绕过:
|
||||
|
||||
1. `planRevision=0` 表示尚未建立结构化计划。第一次有效 `planUpdate` 必须完整替换 legacy `plan / planSteps / activePlanStepIndex`,不得保留 legacy 的 `completed / failed` 脚手架步骤。
|
||||
2. 只有函数入口处已经存在结构化计划时,后续更新才保留 `completed / failed` 终态。结构化 `failed` 仍不可被 Provider 改写,普通工具失败和完成门失败继续 fail-closed;本修复不新增 receipt 特判恢复通道,也不放宽 static smoke、revision、desktop/mobile 试玩或最终交付门。
|
||||
3. 修复序列回归必须覆盖 `revision 2 smoke failed -> 首份结构化修复计划 -> 同 Run file.patch 到 revision 3 -> 自动重跑当前 revision smoke -> desktop/mobile preview`;同时单独证明已建立结构化计划后的 failed 步骤仍不可变。
|
||||
4. Windows real-E2E 把直属 CLI 终态与 stdio 完整关闭拆成两阶段:完整换行的 turn report 是输出边界;直属 CLI `exit/error` 后不再向其 PID 发信号;finally 先按 sentinel、endpoint、boot、进程指纹和稳定 Windows process HANDLE 停止 suite 自有 Runner,再有界等待继承管道关闭。临时 AppData 和 sentinel 必须归当前用户私有 ACL,稳定 HANDLE 自测必须同时证明 close 不杀目标、signal 终止原目标。
|
||||
5. 验收按“Rust 定向与分组回归 -> real-E2E self-test -> 串行 Rust 全量 -> 前端类型检查 -> 编码和差异门禁 -> 新的独立 `gpt-5.6-sol` / `max` 真实 Provider 空项目轮次”执行。真实轮次必须在同一父/子 Run 中取得当前 revision 的 static smoke、desktop/mobile 试玩和唯一 completed 终态;失败轮不得与后续轮拼接。
|
||||
6. professional DAG 的图片产物任务必须保持任务文案与计划门禁一致:External Editor 已配置时,`art-director` 是只允许 `canvas.asset_generate` 受控素材事务的非只读视觉任务,不得被通用“只读协调”文案拒绝;`assets/art-spec.png` 的固定 `icon-spec / 1:1` 合同、其它文件写入禁令、mutation revision 和验证凭证均不放宽。
|
||||
7. 真实 E2E 报告必须绑定 effective model、API kind 和 endpoint 指纹,并递归核验唯一 Supervisor 根链、全部后代终态、最终入口 SHA-256 与 static smoke 凭证、交互 CLI 与隔离 AppData 的路径泄漏,以及清理后本轮 Runner/helper/Node/browser/command 后代残留为零;任一项无法证明即 FAIL。
|
||||
8. `reasoningEffort=max` 必须作为独立强度贯通配置校验、`platform-llm` Responses 请求、Provider 适配、Codex 映射、请求指纹和前端配置类型,不得静默降级为 `high` 或 `x-high`。本轮真实验收固定使用 `agentMode=provider`;由于 canonical Agent 会先应用角色默认推理强度,隔离配置必须为 `project-supervisor`、`code-prototype`、`art-director`、`art-asset-plan` 分别显式覆盖 `max`,并由报告中的 effective binding 证明四者一致。
|
||||
|
||||
## 目标
|
||||
|
||||
在 Genarrative 内建设独立桌面 App:普通用户通过项目开发工作台中的陶泥儿对话、资源画布、运行状态和确认操作,让平台生成保存在本地的可运行 Web 游戏原型,并通过本地 HTTP server 预览;主窗口提供运行时配置入口,用于保存发布版 AppData / Tauri 配置目录里的 LLM 配置及受控开发者 External Editor 配置。普通客户素材画布使用平台登录态调用内部编辑器 API,不展示或要求填写画板 Base URL / API Key。任务明细、原始文件、命令日志和专业 Agent 调试控制仍放到开发构建的独立开发窗口。v1 的生成闭环仍以 Web 小游戏为主,同时允许用户打开已有 Godot 项目:所选含 `project.godot` 的目录直接成为项目根,Agent 使用标准运行档在该目录内继续修改,只新增并保留 `.agent/` 作为运行元数据,不创建 `game/`、`assets/`、`memory/`、`exports/` 平行目录;本期不扩展 Unity、Godot 内嵌预览、云同步或插件市场。
|
||||
@@ -1079,8 +1096,10 @@ game-project/
|
||||
|
||||
- **入口覆盖**:本节取代本文更早“普通 GUI autonomous 继续固定完整 DAG”的现行含义。项目首页进入的普通 Web 工作台必须显式使用 `single-supervisor` 编排,提交映射为 `project-supervisor-game-chat + autonomous-game-build`;持久化 Supervisor 决策前零 child,决策后只启动唯一 `code-prototype` 主 Run,美术仅在该 Run 完成 `asset.list` 并形成可证实缺口后一次委派一个受限 child。独立 game-chat 入口沿用相同规则。显式 `professional-dag` 与 CLI 专业 autonomous 验收继续使用 `project-supervisor-gui|cli + autonomous-game-build` 的原有完整 DAG;Supervisor 调试与 Godot 继续 `project-supervisor-gui + standard`,不得被普通入口默认值误改。
|
||||
- **普通界面**:`single-supervisor` 工作台不展示固定专业 DAG、子 Agent Dock 或“严格审批”,只显示总控对话、生成状态与“自动执行”。这只是产品投影收敛,不删除开发诊断入口,也不放宽权限;项目外写入、任意 shell、发布、凭据、系统设置和未知外部副作用继续失败关闭。
|
||||
- **无人介入语义**:可信 game-chat autonomous 根链路及其绑定 child 不得停在普通 `waiting-for-confirmation` 或 `waiting-for-user-input`。child 的信息不足交付在严格身份校验后转为同一父链可执行的安全默认返工,问题正文与公开问题指纹清除,内部只保留不公开的 SHA-256 幂等 marker;standard、GUI/CLI 调试和非可信绑定继续保留人工澄清。可恢复失败必须回到同一 `code-prototype` Run,不能要求用户发送“继续”。
|
||||
- **无人介入语义**:可信 game-chat autonomous 根链路及其绑定 child 不得停在普通 `waiting-for-confirmation` 或 `waiting-for-user-input`。child 的信息不足交付在严格身份校验后转为同一父链可执行的安全默认返工,问题正文与公开问题指纹清除,内部只保留不公开的 SHA-256 幂等 marker;standard、GUI/CLI 调试和非可信绑定继续保留人工澄清。可信 `code-prototype` 主 Run 可以且只能认领 task/session/run/binding/delegation 身份全部匹配的直属美术 delivery:存在 ready 回执时由 Runtime 确定性执行 `agent.run_status(scope=self)`,claim 尚未完整 Observed 时禁止请求 Provider;普通失败或 marker 不完整时认领后立即失败,合法 `game-chat-safe-default-repair.v1` marker 则由 Runtime 直接生成唯一一层、同目标、同合同 `agent.delegate`,repairRequired 状态下的重复 route/read/query 被 liveness 门拒绝。父 task 或 binding 链丢失且仍有活跃 delivery 时完成门必须 blocked;只有 suppressed 记录不再参与 capability、claim 和 completion barrier。可恢复失败必须回到同一 `code-prototype` Run,不能要求用户发送“继续”,也不能在已知不可修复或返工已确定后继续消耗 Provider 轮次。
|
||||
- **验证反馈与完成门**:`game.static_smoke` 先校验 `<script>` 闭合和全部可执行内联 JavaScript 语法,再检查 Canvas、输入、状态、胜负与重开合同。失败回执的公共投影只包含 `commandId/passed/failureCode/check/path=game/index.html`;同一 owner 可额外读取经脱敏、有界的 `diagnostic`,以执行“诊断 → mutation → 当前 revision static smoke → desktop/mobile preview.validate”循环。根 Run 只有在正式 artifact、manifest、当前 revision 静态凭证和双视口试玩一致时才能唯一 completed;同 revision 同失败且无新 mutation 必须命中停滞门,不能无限猜测。
|
||||
- **Runner 接管**:新 boot 取得跨 boot `execution-owner` 后必须在释放 owner-map 锁后幂等触发既有 durable recovery scan。纯 Provider、项目内文件和验证动作按 checkpoint 续跑;结果未知的进程、付费生成或其它外部副作用进入 `needs-reconciliation`,禁止盲目重放。重复 hydration/read 或同 boot claim 不得重复 child、消息、action 或付费请求。
|
||||
- **验收层级**:确定性 loopback E2E 必须覆盖普通入口路由、唯一 `code-prototype`、首次语法 smoke 失败、同 Run 取得结构化诊断并修改、当前 revision 静态与桌面/移动试玩通过、根 Run 唯一 completed、确认/追问为零。该结果只证明 Runtime 控制面;使用真实 Provider 的空项目单输入 smoke 全程无人介入成功后,才能宣称现场目标完成。
|
||||
- **真实 Provider 开发验收入口**:`--game-chat-smoke` 是受限 CLI 标记,只允许与默认 `project-supervisor` 的 `--swarm-chat --autonomous-game-build` 组合,将新根 Run 绑定为 `project-supervisor-game-chat`,不作为产品 UI、公开 API 或通用 source 覆盖能力。现有 playable harness 通过 `npm run ai-game-creator-shell:agent-runtime:supervisor-game-chat-single-main-playable-real-e2e` 显式启动该模式,启动前同时校验 `project-supervisor` 与 `code-prototype` 的 Provider 配置,并在隔离 AppData 中验收唯一单主 child、当前 revision 的 static smoke 及 desktop/mobile 试玩回执。只有显式执行这条真实 E2E 命令才会发起 Provider 请求;普通 self-test 不读取凭据、不调用 Provider。现场 smoke 若在配置门因缺少 API Key 阻断,必须报告 `providerUsed=false`,只能证明入口、验收逻辑与无 Provider 自测已落地,不能宣称真实现场验收完成。
|
||||
- **fresh-init 取证边界**:`supervisor-game-chat-single-main-playable` 不再预写 `package.json`、`verify-e2e.mjs` 或 `game/index.html`,由正式 `--init` 生成生产 `DEFAULT_GAME_INDEX_HTML`。self-test 必须逐字节核对 harness 中的 canonical 默认入口与 Rust 生产常量,并证明空项目仍保留 Git、`AGENTS.md`、隔离 evidence 和敏感诱饵基线;真实报告必须同时证明初始 SHA-256 命中生产默认入口、根下唯一固定 child 为 `code-prototype`、最终入口已变化、static-smoke SHA-256 绑定最终入口且 desktop/mobile 各自通过。
|
||||
- **不外推范围**:上述真实 Provider 命令只验收普通 Web 工作台所采用的 `project-supervisor-game-chat + autonomous-game-build` 单 Supervisor 链。显式 `professional-dag` 与固定 16 节点 CLI/GUI 链的 owner-artifact verify、产物所有权和 path-scope 仍是独立未解决项;seeded deterministic E2E、普通 self-test 或本 game-chat 报告都不得冒充该链已修复或已完成真实验收。
|
||||
|
||||
Reference in New Issue
Block a user