d86ea61a68
approval_receipt_consumes_submit_batch_and_folds_final_provider_usage_once 本该覆盖上一个提交修掉的那条链路,却一直是绿的。原因在夹具:它手搓 child_completed 再用 append_game_creator_agent_runtime_task 写终态,而这个入口 不往记录里写 actionId。生产侧走的是 ensure_project_planning_submit_child_completion_at,它用 append_game_creator_agent_runtime_task_projection_once 把 actionId 一起盖进去。 差别正好落在被测的那把幂等键上。磁盘上没有 (runId, actionId, phase=completed) 这一行,receipt 消费时的投影就找不到冲突对象,顺利追加——于是一条 100% 必现的 线上故障在单测里完全看不见。 改成调用生产入口本身,并按它的前置补齐 durable delivery(沿用同模块 2400 行 一带的既有写法,结果文案与生产的 last_response 一致,避免 publish 时身份不符)。 A/B 验证过测试确实抓得住:临时撤掉上一个提交的修复,此测试报 assertion failed: !first.recovery_pending,正是线上症状;装回修复即通过。 同批 planning_submit 并发跑有 6 条失败,逐条单跑全过,是本机 agent.db 文件锁 竞争,与本改动无关。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>