修复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:
kdletters
@@ -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