文档：补审批前置门与用户修订不计返工两处空白
第 13.0 节（新增）审批前置门：原文只规定「取证必须在 GDD 落盘之后」， 未规定相对用户审批的先后，第 13.3 节投影顺序里也没有验收图。 反序会产生无回退路径的死角——用户已批、receipt 不可回滚、根 run 却因 验收图未收敛完不成，GDD 状态是 approved 但流程卡死。 固定为：取证通过才允许暴露审批卡；未通过则不建审批卡，改发返工委派。 并列出三道门各自的失败路径：schema 不过不分配版本号、验收不过走返工 不惊动用户、用户不满意走修订。第 1.1 与 23.1 节的第 3 条约束同步补全。 第 23.7 节（新增）用户修订不计入 repair_depth：给 StaticDelegateContractStatus 增加第四个变体 UserRevisionRequested。 repair_depth 防的是 runaway agent，而用户点修改每轮都由人触发、 人本身就是循环边界，两者不应共用计数。本裁决不推翻 WP1 的 depth<=1，也不需要按 source 分流——做游戏链路不会出现该变体。 如实记录「无限修订」兑现不了：链上推断有 32 跳硬上限、版本链 128 上限， 产品阈值定 16 次软提示。反序列化须 fail closed，不得降级为 NeedsRepair。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -98,7 +98,7 @@ M0 三个代码工作包无一行按 D6 编写，**不需要为新设计回退
|
||||
|
||||
1. **Supervisor 第一轮必须且只能提交 `agent.goal_contract`**，不得夹带其它 action、`plan_update`、legacy plan 或 response。做方案场景下可满足——交付物「一份获批的方案」开工即确定，不存在自主构建里「目标未澄清就要冻结」的矛盾。
|
||||
2. **验收节点的 `requiredEvidence` 锚定 `game/fast_gdd.md` 配 `tool:file.read`，不得指向 `.agent/planning/**`。** `reject_agent_runtime_private_control_path`（`apps/ai-game-creator-shell/src-tauri/src/project/filesystem.rs:253-266`）目前只挡 `.agent/runtime`、`.agent/checkpoints`、`.agent/workbench` 三类，planning 不在内；但该函数**不区分读写**，若为落实第 19 节第 3 条的写保护而把 planning 加入此列，`file.read` 会被一并挡死、出口门永久 blocked。planning 的写保护必须用只挡写的独立判据实现。
|
||||
3. **Supervisor 取证必须在 GDD 落盘之后。** 验收节点 passed 要求非 mutation evidence 的 before / after / 当前 revision 三者相同；`.agent/planning/**` 与 `game/fast_gdd.md` 尚未实现，其写入是否推进 project revision属于待定设计而非待查事实，故无论如何定，都以「落盘后取证」为准。
|
||||
3. **Supervisor 取证必须在 GDD 落盘之后、且在交付审批卡之前**（后半句为 2026-08-13 补充，见第 13 节「审批前置门」）。验收节点 passed 要求非 mutation evidence 的 before / after / 当前 revision 三者相同；`.agent/planning/**` 与 `game/fast_gdd.md` 尚未实现，其写入是否推进 project revision属于待定设计而非待查事实，故无论如何定，都以「落盘后取证」为准。
|
||||
|
||||
#### `M0A-3` 门禁与完成定义
|
||||
|
||||
@@ -1151,6 +1151,33 @@ type PlanSubmitGddResult = {
|
||||
|
||||
> **2026-08-13 按 D11 更正。** `gdd-approval` pending 建在 **Supervisor 根 run** 上（`source=project-supervisor-plan`），因为审批卡是给用户看的、而用户只跟 Supervisor 对话；提交 GDD 的策划子 run 在 `plan.submit_gdd` 返回后即终态，不等待审批。receipt、幂等域、`decisionFingerprint` / `receiptFingerprint` 与投影顺序**未变**。
|
||||
|
||||
### 13.0 审批前置门：验收取证必须先于审批卡（2026-08-13 补充）
|
||||
|
||||
原文只规定了「取证必须在 GDD 落盘之后」，**没有规定取证在用户审批之前还是之后**，第 13.3 节的 receipt 后投影顺序里也没有验收图这一步。该空白必须补上，因为反序会产生一个无回退路径的死角：
|
||||
|
||||
```
|
||||
用户点批准 → receipt durable（线性化点，此后不回滚批准）
|
||||
→ Supervisor 才取证 → fast-gdd-serves-intent 判定不 passed
|
||||
→ goal_contract_acceptance_completion_blocker_at_locked 返回 blocked
|
||||
→ 根 run 完不成，而 GDD 状态已是 approved
|
||||
```
|
||||
|
||||
此时用户以为已经定稿、系统却卡住，且 receipt 不可回滚（要改只能提交并决定新版本），这个状态对用户不可解释。
|
||||
|
||||
**固定顺序**：Supervisor 收到 `plan.submit_gdd` 的 `Submitted` 回执后，**必须先**以 `tool:file.read` 对 `game/fast_gdd.md` 取证并确认合同的全部 required 验收节点，**通过后才允许把 `gdd-approval` pending 暴露给用户**。取证未通过时**不创建审批卡**，改为发起返工委派（`repair_of` 指向原 delivery），由策划子 Agent 修订后重新提交。
|
||||
|
||||
**为什么必须是这个方向**：两道检查的性质不同，混序会让它们互相抵消。
|
||||
|
||||
| 检查 | 判什么 | 谁判 | 不通过怎么办 | 计数 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| strict schema（第 12 节） | 字段存在性与约束 | Runtime | 工具错误回灌，**不分配版本号** | 不计 |
|
||||
| Goal Contract 验收图 | 产物是否服务本次意图 | Supervisor（agent） | **返工委派，不惊动用户** | `repair_depth += 1`，上限 1 |
|
||||
| 用户审批 | 满不满意 | 人 | 用户修订委派 | 两个计数都不动（见第 23.7 节） |
|
||||
|
||||
机器判合格在前、人判满意在后，三道门各自的失败路径互不干扰；反序则会出现「人已经批了、机器才说不合格」这种没有出路的组合。schema 那道天然满足本约束——校验失败不产生版本，不产生版本就没有审批卡，结构上不可能反序。
|
||||
|
||||
**恢复语义**：取证已完成但 pending 尚未创建时，按既有 identity 幂等补建审批卡，不重新取证；pending 已创建则证明取证已通过，恢复路径不得再次要求取证。取证结果本身不落新的 durable 记录，它就是现役 Acceptance Graph 的 evaluation。
|
||||
|
||||
### 13.1 `gdd-approval` pending
|
||||
|
||||
M1 新增独立 `.agent/planning/pending.json`，不升级、不迁移、不重写现役全局 `game-creator-pending-action.v5`，也不能把普通 `user.input_request` 或 confirmation pending 改名冒充审批。独立文件使用 `plan-gdd-approval-pending.v1` strict schema：
|
||||
@@ -1746,7 +1773,7 @@ D9 之后，root 是未变的 Project Supervisor，它在 `standard` 下天然
|
||||
|
||||
1. Supervisor 第一轮必须且只能提交 `agent.goal_contract`；做方案场景可满足。
|
||||
2. 验收 `requiredEvidence` 锚定 `game/fast_gdd.md` 配 `tool:file.read`；`.agent/planning/**` 的写保护必须用只挡写的独立判据，不得加入 `reject_agent_runtime_private_control_path`。
|
||||
3. Supervisor 取证必须在 GDD 落盘之后。
|
||||
3. Supervisor 取证必须在 GDD 落盘之后、且在交付审批卡之前（后半句 2026-08-13 补充，见第 13 节「审批前置门」）。
|
||||
|
||||
**M1 入口前置决策（2026-08-13 起全部关闭，以下逐条保留处置记录）**：
|
||||
|
||||
@@ -1884,6 +1911,40 @@ M0 完成不表示任何策划功能已上线。M1 的功能实现仍未开始
|
||||
- 跨 run 全局预算缺口：第 23.5 节的 7 跳上界是**单条链**（同一 `parent_run_id`）粒度的界，不是某专业 Agent 在项目生命周期内的累计界；只要不断开新 run 就能不断获得新配额。本阶段只记录不实现。
|
||||
- 「做游戏」路径改造（删 `design-director`、收窄 `design-foundation`、调整 16 任务 DAG），等 GDD 真正被完整构建消费时另开工作包；见第 1.1 节「`M0A-3` 明确不做」。
|
||||
|
||||
### 23.7 用户修订不计入 `repair_depth`：新增 `UserRevisionRequested`（2026-08-13 裁决）
|
||||
|
||||
**问题**：静态委派的跳分类判据只看父节点的 `structured_result.contract_status` 是否为 `NeedsUserInput`（`apps/ai-game-creator-shell/src-tauri/src/delegation.rs` 的 `static_delegate_original_is_awaiting_clarification`），凡「父节点不在等回答」的续跑一律 `repair_depth += 1`。用户在审批卡上点「修改」时父节点回执是 `Submitted`，因此必然落进返工计数，而 `WP1` 冻结的 `repair_depth` 上限是 1——**后果是用户每条 plan lineage 只能修订一次**，第二次被 `静态委派返工深度最多为 1` 直接拒。
|
||||
|
||||
**裁决**：`repair_depth` 防的是 **runaway agent**——autonomous 链路上 Supervisor 是 LLM，自行判定产出不合格就重新委派，无人拦截时会无限消耗预算。用户点「修改」则**每一轮都由人触发，人本身就是循环边界**，两者性质不同，不应共用计数。
|
||||
|
||||
给 `StaticDelegateContractStatus`（现有 `EvidenceReady | NeedsRepair | NeedsUserInput`）**新增第四个变体 `UserRevisionRequested`**，分类判据保持纯函数，只增加一个分支：
|
||||
|
||||
| 父节点 `contract_status` | 该跳性质 | 传播 |
|
||||
| --- | --- | --- |
|
||||
| `NeedsUserInput` | 澄清 continuation | `round += 1`，`depth` 不变 |
|
||||
| `UserRevisionRequested` | **用户修订**（新增） | **两个计数都不动** |
|
||||
| 其它 | 质量返工 | `depth += 1`，`round = 0` |
|
||||
|
||||
审批命令写下 `action=revise | reject` 的 receipt 后，把原 delivery 的 `structured_result.contract_status` 置为 `UserRevisionRequested`；Supervisor 随后的续跑委派仍挂在原链上（`repair_of` 指向原 delivery），谱系与澄清轮次预算完整保留。
|
||||
|
||||
**本裁决不推翻 `WP1`**：「`repair_depth` 上限维持 1 不放松」继续成立，因为用户修订压根不算 repair。也**不需要**给 `repair_depth` 按 source 分流上限——做游戏链路不会出现该变体，不受任何影响。
|
||||
|
||||
**「无限修订」在机制上兑现不了，必须如实告知产品**：
|
||||
|
||||
| 硬边界 | 值 | 性质 |
|
||||
| --- | --- | --- |
|
||||
| `STATIC_DELEGATE_LINEAGE_MAX_HOPS` | 32 | 链上推断每次走完整条链，超限 fail closed 返回 `(u32::MAX, u32::MAX)`；防环/防越界兜底，不是可调参数 |
|
||||
| 单 lineage 版本数（第 8.8 节） | 128 | 版本链只增不改 |
|
||||
|
||||
只要修订挂在同一条链上，真实上限就是 **32 跳**。让修订不挂链（`repair_of=None` 另起）可绕开，但会丢失谱系关联并重置澄清预算，等于绕开整套约束，不采纳。产品阈值定为 **16 次修订且为软提示**：远低于机制边界、又高到用户实际碰不到；超过时不拒绝，提示「已修订 16 次，建议退回重做重新梳理需求」——每次修订都是一次完整 Provider 调用加一个新版本，改到十几次仍不满意时问题多半在需求本身，此时应走退回重做（新 lineage、重新问询）而非无限微调。
|
||||
|
||||
**落地约束**：
|
||||
|
||||
- 变体新增、判据分支与 receipt 写入必须**同一个 PR 同进同退**——只置 status 不写 receipt（或反之）会让链路计数与审批事实脱节。
|
||||
- `StaticDelegateContractStatus` 是 durable schema 的一部分。新增变体属**前向兼容**问题（旧代码读不了新记录），非后向兼容问题：只有做方案链路会写它，做游戏链路既有记录不受影响。反序列化必须 fail closed，**不得静默降级为 `NeedsRepair`**——那会让用户修订被误计成返工，正是本裁决要消除的行为。
|
||||
- 本裁决改的是 master 已发布的静态委派机制，须在 `decision-log.md` 补 dated 记录，写明 `WP1` 的 depth≤1 结论未被推翻。
|
||||
- 回归必须覆盖：用户修订跳不增 `depth` 也不重置 `round`；连续多次修订均可通过；做游戏链路的返工仍在 `depth=1` 被拒；无该变体的历史记录分类行为不变；32 跳边界仍 fail closed。
|
||||
|
||||
## 24. 最终不变量摘要
|
||||
|
||||
- 策划与构建是两个不同 profile/source 的 run，由用户动作连接，不由 Agent 自行升级。
|
||||
|
||||
Reference in New Issue
Block a user