Files
Genarrative/docs/technical
lhk229 db740d8ae6
Project CI / Repository checks (pull_request) Successful in 3m13s
Project CI / Frontend tests (pull_request) Successful in 3m49s
Project CI / Backend tests (pull_request) Successful in 4m49s
Project CI / Native shell tests (pull_request) Successful in 16m15s
台账逐项比对失败改判为可回灌的输入错误
plan.submit_gdd 的 session_decisions_match_input 校验此前与三条真 CAS 判据
(sessionRevision 溢出、session 已被其它动作推进、Runtime source
revision/fingerprint 无效)共用 PLAN_SESSION_CAS_CONFLICT,因此被
plan_submit_error_is_business_rejection 漏掉,一次不匹配就 needs-reconciliation
硬阻断整个策划子 Agent。

两者性质不同:真 CAS 说明 durable 权威已变或已坏,重交同一份 input 不可能成功;
台账不匹配时权威完好,错的是本次 Provider input——子 Agent 把决策摘要抄漏、抄错,
或多追加了一条非 default_pending 决定。按第 12 节自己的判据,后者属于「本次
Provider input」,该走 rejected observation 回灌并受既有 5 次预算约束。

拆出 PLAN_SESSION_DECISIONS_MISMATCH 并纳入 business rejection,真 CAS 三支
原样保留 reconciliation。不变量未放松:不匹配照样拒、照样不产生任何事实,
伪造用户确认仍然不可行,只是拒绝的后果从叫人变成让它改稿。

实测触发:子 Agent 连撞三次形状层(PLAN_INVALID_REQUEST),每次都按回灌理由
改对一部分,机制运转正常;第四次形状合法后随即撞上台账比对,直接阻断,
整条链路零产物。即越接近提交成功越容易撞上不给重试的门。

覆盖:改写既有决定正文 → 新码;同一份 input 只改陈旧 revision → 仍是 CAS;
追加伪造 confirmed 决定 → 新码且不落任何事实;分类器两向断言。分类器一条
已变异验证。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 02:45:37 +00:00
..