lhk229
9a3b9dce15
Project CI / Repository checks (pull_request) Failing after 12s
Project CI / Backend tests (pull_request) Failing after 13s
Project CI / Frontend tests (pull_request) Successful in 2m51s
Project CI / Native shell tests (pull_request) Failing after 12m11s
0 轮直出可以标原型验证项；坏信封降级成可返工而不是判死委派
两条都是 run 17（571 字完整需求走生产链路）实测撞出来的，都在既有代码里，
都比刚修的台账约束更早触发。
N1 —— round=0 决定被钉死成 default_pending。用户一次把需求说全时全部决定都是
round=0，于是没有任何决定可能成为 prototype_pending；而 validate_decisions 的双射
又要求 prototypeValidationItems 逐项对应 prototype_pending 决定，结果首次
plan.submit_gdd 必被预检拒收，这份稿子也永远不可能带上原型验证项。实测子 Agent
读懂了拒绝理由，代价是把「触控手感」「30 回合是不是真的 8-12 分钟」这类没人验证过
的假设一律标成「默认，待确认」——那是在说谎，它们不是默认值。
round=0 真正要守的是「从未提问过的决定不得声称任何用户权威」，即
answerSource 必须是 default，而不是把状态钉死。改成允许 default_pending 与
prototype_pending 两种，answerSource 仍强制 default，confirmed 照旧拒。双射保持
严格不动——Agent 现在有合法途径同时给出决定和验证项。
N2 —— AGC_NEEDS_USER_INPUT_V1 的解析在 build_static_delegate_structured_result_at
里 `?` 往外传，而这个函数跑在投递回执时，子 run 已经 idle/completed，没有任何一轮
可以把解析错误回灌回去。实测一次 option 多写 `id` 字段就让整条委派 result_failed、
父 Supervisor 直接 needs-reconciliation 停下等人。不是预算设成 0，是结构上没地方
重试；对照原型，它在 run 循环内解析、坏了注入 INJ_ENVELOPE_REJECTED 重试 3 次。
信封格式属于「本次 Provider 输出写错」，与 plan.submit_gdd 的业务拒绝同类，不是
durable 权威损坏。降级成 needs-repair，并把解析失败在哪当返工理由带上（而不是把
那段无法解析的原文照抄回去，那对子 Agent 没有可操作信息）。Supervisor 用既有的一次
返工额度即可自愈。
role brief 补上 prototypeValidationItems：schema 把它列为 required，brief 此前
一个字没提它、也没提双射，模型只能靠撞。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 07:37:28 +00:00
..
2026-08-06 16:57:38 +08:00
2026-08-21 07:37:28 +00:00
2026-08-05 19:15:46 +08:00
2026-07-17 16:56:46 +08:00
2026-08-17 12:42:29 +08:00