iomgaa
76495d9e39
fix(session,_recovery,types): 修 Codex 对抗审查报的五条
逐条核实全部成立。最重的是第一条：停止判定的结果只存在于结束记录里，而步记录与结束记录是
两次写。崩在两者之间那次判定就丢了，恢复照常回到预算准入——一次「恰好用满预算完成」被改写
成「预算耗尽」（两条轨迹长度一模一样），一次已经达成目标的运行接着往下跑，一次该以连续解析
失败收尾的运行再花一次模型调用。修法是续跑时把那次判定重演一遍：判定要的东西全在日志里
（动作结果在步记录那条原子写里、工具名在步记录上、模型回复在模型调用结果里）。最终回答那
一档更麻烦，答案文本只存在于结束记录里，靠重新解释那条已存下来的回复找回来——那时副作用还
没发生，重新解释是安全的。五种收尾各一条测试。
其余四条：
- 模型调用失败步在续跑时补写，prompt_chars 填了 0。重新装配出来的和被打断时是同一份，
照它算。填 0 是把轨迹里那一列改写成假值。
- 取消正好落在写运行开始记录那一下时不留取消标记，留下一份只有开始记录的日志：run 因标识
已存在而拒绝、resume 当成可以从第 0 步续跑。用 shield 让那条记录一定落地，取消结束记录
才有地方挂（反过来先写结束记录会拼出结构上说不通的日志）。
- ModelCallResult 能同时带 reply 和 failure，而恢复只看 reply is None，于是把一次失败的
调用当成成功、接着解释那段回复执行动作。加构造期不变量。
- call_id 空串一路能进持久化记录。docstring 里那句「绝不能是空串」原本没有任何东西守着。
顺带把主循环里重复的一次上下文装配去掉，并把只在续跑第一次迭代成立的那个分支挪出循环。
2026-08-10 03:12:42 -04:00
..
2026-08-09 23:56:38 -04:00
2026-08-07 07:02:09 -04:00
2026-08-07 07:02:09 -04:00
2026-08-10 03:12:42 -04:00