lhk229
41adfea134
策划 hydrate 收窄到策划链路，并收口三处重复事实源
审查四条：
1. GDD hydrate 原本挂在任意 run 的任意一次监工状态变化上，而后端
hydrate 要抢项目写锁、扫 authority、必要时修投影，等于让做游戏和
做素材两条链路的每一拍心跳都去抢一次写锁。加一道门收窄。
门不能只看 source：审批卡的可见性判据是
`displayGdd && (pendingApproval || recoveryPending)`，跟当前 run 的
source 无关，非策划分支的监工面板也要靠 pendingApproval 点亮等待
审批位。所以判据是「策划链路 或 策划状态尚未落定」。
判据取 source 标量而不是 runtime 本体，保住那条 effect 依赖里只放
标量的原设计；策划状态读 ref 不进依赖，否则 hydrate 触发 hydrate。
后端把能力位读取提到取锁之前——它读的是应用配置不是项目文件，跟锁
无关，而 load_game_creator_app_config 每次都遍历所有配置路径读盘。
返回值不变，只是少占一段写锁。
2. 删掉零调用方的 append_plan_provider_usage_fact_for_test，cargo 的
never used 告警随之消失。
3. 前端 'project-supervisor-plan' 从三处收到 app/constants 一处：
AgentRuntimeState.source 只是裸 string，改名没有任何编译期提示。
Rust 侧 filesystem.rs 两个守卫统一走 PLAN_FAST_GDD_PATH，顺带修掉
其中一处大小写敏感、另一处不敏感的不一致（两者串联使用，原先没有
实际绕过）。跨语言没有共享常量通道，TSX 与 mjs 只能留交叉引用注释。
4. App.tsx 里 game-chat 终态判定的两个本地实现删除，6 处调用改用
gameChatRuntimeProjection 的出口。保留 App.tsx 冻结 manifest 快照
的那道闸门——它判实时 manifest 决定要不要冻快照，与
canArchiveGameChatStage 判已冻快照不是重复检查。
验证：cargo check --all-targets 无新告警；agc:typecheck、eslint、
cargo fmt、prettier、check:encoding 通过；appSurface.test.ts 425/425。
Rust plan 过滤 404 passed / 2 failed，两条均已逐条定性为非回归：
planning_clarification_answer_prepared_recovery_releases_execution_before_project_wait
在纯基线上同样失败（既存红），tool_plan_handoff_repair_restart_replays_chain_without_network_request
单独跑通过（本机批量 flaky）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:35:27 +00:00
..
2026-08-22 13:17:26 +08:00
2026-08-24 12:35:27 +00:00
2026-08-22 13:17:26 +08:00
2026-08-22 13:17:26 +08:00
2026-08-22 13:17:26 +08:00