lhk229
9bad7121b5
Project CI / Repository checks (pull_request) Successful in 1m24s
Project CI / Frontend tests (pull_request) Successful in 2m58s
Project CI / Native shell tests (pull_request) Successful in 14m58s
Project CI / Backend tests (pull_request) Successful in 3m56s
修复 Native shell tests 既存红：委派用例改调 _at_locked
CI task 3784 的 Native shell tests 报 2121 passed / 3 failed，三条同因：
agent.delegate -> failed, "无法取得一致项目快照"
项目正在被其他写操作占用：$PROJECT_ROOT/.agent/project.lock
- autonomous_direct_child_collaboration_mutations_require_the_current_root
- autonomous_delegate_descendant_inherits_and_enforces_the_current_root_guard
- standard_delegate_collaboration_mutations_remain_compatible
根因是又一次「把动作挪到调用链更前面，改变的不是严格度而是作用范围」。
bc1fe7d8f 写这几个用例时，观察点是「测试先持项目写锁、再调
observe_agent_runtime_agent_delegate」，当时无害：老薄壳压根不碰项目锁，它调的
start_..._with_link_at 只对 planning 身份取锁，其余身份走
..._with_project_lock_at(..., None)。
152cc40c7（完成 M1C-2b 策划澄清与预算接线）为了让 planning 子 session 的投影按
project -> session 取锁，把锁的所有权上提，拆出
observe_agent_runtime_agent_delegate_at_locked，并让同名薄壳在入口无条件取项目写锁。
而 .agent/project.lock 是 create_new(true) 的文件锁、不可重入：调用方已持锁再进薄壳
就死等满 2000x5ms 预算再失败。确定性红，不是抖动——本机复现逐字一致。
这不是生产漏洞。生产侧调 agent.delegate 的只有 action_execution.rs:436 和
pending_recovery.rs:162，两处都持锁后调 _at_locked；取锁的薄壳如今零生产调用方，
只剩测试在用（main_loop_tests、autonomous_completion_contract_tests 那些都不持锁，
所以一直是绿的）。所以改测试面，生产代码零行改动。
- delegation.rs 四处（2515/2584/2678/2740）改调 _at_locked 并传入已持有的
&project_lock。这不是迁就实现：_at_locked 才是生产唯一的调用形状，改完这三个用例
覆盖的是真实路径。首处留注释说明为何必须绕开同名薄壳——否则下次「顺手统一」回去
会复发，而症状是 10s 静默卡顿，很难往锁不可重入上想
- runtime_tools.rs 补一条 #[cfg(test)] pub(crate) 再导出。生产侧靠
pub(in crate::agent) 的 glob 即可见，测试模块在 crate::agent 之外需单独放行；
沿用旁边 #[cfg(test)] pub(crate) use delivery::{...} 的既有写法，不动生产可见面
验证：tests::collaboration::delegation 改前 22 passed / 3 failed（18.68s），改后
25 passed / 0 failed（5.54s）。少掉的 13 秒正是三条各自空等 10s 锁预算的量——那三次
等待没再发生，不是断言被放宽。cargo fmt --check 干净。
另记一条前提更正：AGC shell crate 是有 CI 的。project-ci.yml 的 native-shell-tests
job 跑 npm run check:native-shells，本次覆盖 2124 条。此前「这个 crate 在 CI 里从不
编译也不测试」的判断是错的。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 08:35:27 +00:00
..
2026-08-06 16:57:38 +08:00
2026-08-18 08:35:27 +00:00
2026-08-05 19:15:46 +08:00
2026-07-17 16:56:46 +08:00
2026-08-17 12:42:29 +08:00