lhk229
6234b420fc
修复 HEAD 既存红：策划恢复门用例改建可达状态
planning_recovery_contains_session_identity_conflict_before_provider 自 M1C-2b
（152cc40c7）写下起一天都没绿过：它伪造一个 source=agent-background-task、且没有
Run Profile 绑定的策划任务，而 agent_runtime_tool_policy_snapshot_for_run_at 早在
M1A-2（09c7d7af8，152cc40c7 的祖先，已核对该门在 152cc40c7 当时就一模一样）就按
agent 身份挡死了这种 run。被告造不出来，庭开不了。当时的定向门禁过滤器
planning_clarification_* 恰好匹配不到它的名字，加上本 crate 不在 CI 里编译，两层
网都没接住。
那道创建门不能放宽：放宽后伪造的策划 run 就能拿到默认宽工具面，正是 M1A-2 关掉的
洞。所以改测试而不是改生产代码。
也不删：该用例第四条断言「身份门必须早于任何 Provider lifecycle」是全 crate 唯一
一处该不变量的否定断言（AGENT_RUNTIME_PROVIDER_REQUEST_LIFECYCLE_RECORD_TYPE 共
22 处引用，否定断言仅此一处），且 plan_session_recovery_gate_tests 模块只有这一条
用例，删掉等于整个门失去覆盖。
先试了更贴现实的「事后删父绑定」，实测走不到本门：entrypoints 的 tool policy 收容
（currentAction=Run Profile 工具策略需要人工核对）先把 run 打成 failed，
read_recoverable_... 随即不再认它，审计里只有 agent.runtime.turn。也就是说绑定层的
破坏到不了 session 门；能到这里的只有「绑定完好、task record 自身不满足 D11 契约」
这一类持久不一致——这正是本门存在的理由。
- 改成：supervisor plan 根与 planning child 绑定都合法（创建门放行），但裸 start
不带 task link，task record 上没有 parentAgentId/delegationId
- 四条断言原样保留：resume 必须 Ok（收容不外溢）、该 run failed/needs-reconciliation
且 error 含 PLAN_SOURCE_PROFILE_MISMATCH、审计有 plan.session_recovery.
needs_reconciliation、且没有任何 Provider lifecycle 记录
- 断言失败信息带上实际审计记录类型与 currentAction，下次判因不用再加探针
- 变异验证：把 exact_plan_child_identity_at 的策划识别翻成直接 Ok(None)，用例报出
"PLAN_NEEDS_RECONCILIATION: project-planning 恢复任务未命中 planning session 协调器"
——证明它确实在考这道门，而不是碰巧绿
- recovery 107/0、planning_ 151/0、session 88/0、plan_ 160/0、approval 11/0
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 06:02:33 +00:00
..
2026-08-06 16:57:38 +08:00
2026-08-18 06:02:33 +00:00
2026-08-05 19:15:46 +08:00
2026-07-17 16:56:46 +08:00
2026-08-17 12:04:31 +08:00