lhk229
33ee790b92
Project CI / Repository checks (pull_request) Failing after 4m24s
Project CI / Frontend tests (pull_request) Failing after 5m31s
Project CI / Native shell tests (pull_request) Failing after 5m50s
Project CI / Backend tests (pull_request) Successful in 7m5s
审批判据改走全量扫描，不再拿有界尾窗证明「不存在」
上一版把尾窗的截断位改成 fail-closed，方向错了。这次连同它一起修掉根因。
新增 read_agent_db_records_matching：只读流式全量扫描，上限与写侧幂等扫描完全一致
（256 MiB / 100 万条）。读得到的范围从此等于写得进的范围，尾窗那道两个数量级的缺口
在这两条判据上不复存在。
- approval_terminal_observation_exists_locked 改走全量，恢复返回 Ok(found)。它在
project_generic_submit_observation_locked 里是「这次是不是重放」的探针，首次审批时
false 就是正确答案，紧接着才会去写 terminal observation。上一版在那里报 Err，`?`
直接抛出，append_agent_db_terminal_observation_if_missing_for_action 永远到不了，
调用方置 recoveryPending 后重试同构——审批永久停摆。而且 truncated 也会被崩溃残留
的残缺末行置位，而有界读不修尾巴，所以任意大小的项目都能踩中。
- plan_gdd_decision_audit_state_locked 改走全量。它的过滤器只到 (gddId, version)，
比写侧幂等键 (gddId, version, responseId) 少一格，是故意的：同版本不同 responseId
的两条 audit 写侧不拦、能共存，这里就是那个跨 responseId 的冲突检测器。上一版靠
「命中即成立」跳过截断，等于让滑出窗口的旧冲突隐形，收束闸会错误放行。
用例改名 approval_judgements_scan_the_whole_agent_db_not_just_the_tail_window，把冲
突副本放在填充之前（窗口之外），并自检尾窗确实截断、副本确实在窗口外。两条改动分别
退回旧行为都会让它失败。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 03:50:54 +00:00
..
2026-08-22 13:17:26 +08:00
2026-08-25 03:50:54 +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