Files
Genarrative/docs/technical
lhk229 8a349c633e
Project CI / Repository checks (pull_request) Successful in 1m18s
Project CI / Frontend tests (pull_request) Successful in 2m56s
Project CI / Backend tests (pull_request) Successful in 4m14s
Project CI / Native shell tests (pull_request) Failing after 12m24s
文档:补审批前置门与用户修订不计返工两处空白
第 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>
2026-08-13 12:06:39 +00:00
..