lhk229
9e2648893b
修通修订轮出稿：投影守卫不再假设「一条 lineage 只提交一次」
审批卡点「修改/退回」后，策划子 Agent 能提交 v2、GDD 也落盘了，但
`project_submit_successors_locked` 拒绝写 session successor，返回
recoveryPending=true。Runtime 把这次工具动作标成 needs-reconciliation，
hydrate 再看到「未审批的 v2 vs session 还指着 v1」，抛
PLAN_SESSION_RECOVERY_REQUIRED。UI 上「重试恢复」走的是同一个投影守卫，
永远清不掉；「结束旧任务」不重写 session，同样清不掉——项目就此砖掉。
根因是 source_session_matches_gdd 里的 latest_submitted_ref.is_none()。
它不是安全判据：相邻的 sessionRevision + sessionFingerprint 已经是全内容
CAS——读取路径 parse_plan_session_bytes → validate_plan_session 会重算指纹
并拒绝不自洽的 session，所以指纹相等即意味着 session 与出稿时的快照逐字段
相等。那一条只是「一条 lineage 只提交一次」的残留假设，而同文件的提交闸
validate_current_session_cas 早在 §M1C-2b 那段注释里宣布该假设作废。删掉
之后，投影守卫的判据集与提交闸逐条相同——本来就该是这个关系。
顺带：已经砖掉的项目重放时命中同一条路径补写 successor，点一次「重试恢复」
即可自愈，不需要迁移。
守门扩在既有的 rejected_session_needs_a_collecting_continuation_not_a_wider_submit_gate
上。那条测试本来就构造出了这个 session 形状（带 v1 的 latestSubmittedRef 和
reject 的 lastDecisionRef），却只断言提交闸放行就收尾，差一步没走到。补上真正
提交 v2 并断言 !recovery_pending；把 is_none() 加回去这条会红，已验证非空转。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-26 08:13:40 +00:00
..
2026-08-22 13:17:26 +08:00
2026-08-26 08:13:40 +00:00
2026-08-24 16:27:33 +08:00
2026-08-24 16:27:33 +08:00
2026-08-22 13:17:26 +08:00