[code-review] trial_fork: verify-passed but uncommitted winner worktree force-deleted, work silently lost

[topcheer]

文件: internal/tool/trial_fork.go
行号: 232-247（keep 判定 + cleanupWorktrees）、190-230（verify 执行条件）、378-397（scoreTrial）

问题描述

胜者 worktree 保留条件为 winner >= 0 && results[winner].Commits > 0，但打分中 VerifyPass 占 100 分（远超 Commits 的 20 分），且 verify 只要求 status == "completed"、在 dirty 未提交树上执行。一个未 commit 的 trial 可以仅凭 verify 通过胜出，随后 git worktree remove --force 删除其 worktree——验证通过的全部未提交工作被静默销毁，trial/* 分支上也无任何内容。

触发场景

1. 两 trial 并行；trial 1 编辑文件、测试通过但未 commit（sub-agent 未服从 "commit all changes" 软性提示词），status=completed
2. trial 2 正常 commit 但 verify 失败
3. 打分：trial 1 = 100+5 = 105 > trial 2 ≤ 35 → trial 1 胜出
4. winner.Commits == 0 → keep=-1 → worktree remove --force 销毁 trial 1 worktree
5. 报告输出 WINNER: trial 1 + adopt 提示 git diff base..trial/... | git apply（diff 为空），anyUsable=true、IsError=false

预期行为 vs 实际行为

• 预期：verify 通过的胜者成果应保留（worktree 或分支上至少一处）
• 实际：未提交成果被 force 删除且不可恢复；报告误宣告可用；调用方 agent 以为有产出继续后续步骤

注意 keep 判定与 anyUsable 判定对同一 trial 的 "usable" 语义不一致（VerifyPass 在 anyUsable 算 usable、在 keep 不算）——明确的逻辑矛盾。注释 "no committed work is lost" 恰恰掩盖了未提交胜者工作丢失。

修复建议

• keep 条件放宽为 Commits > 0 || VerifyPass；或
• inspect 后对胜出且 Dirty 的 trial 自动快照提交（如 trial: uncommitted winner snapshot）
• 报告在 winner 无 commit 时明确警告 adopt diff 为空

严重程度

high（仅限 trial_fork 试验产物，不影响主 checkout；独立复核 subagent 已确认触发路径）

[topcheer]

【认领】复核属实，修复认领（本轮限额 1/2）：

验真（五主张全实证）：

1. keep 单条件 winner >= 0 && results[winner].Commits > 0（L232-234）——verify-passed 胜者零 commit 时 keep=-1，其 worktree 进 cleanupWorktrees 的 remove --force 名单。
2. scoreTrial：VerifyPass=100 分 vs Commits=20 分——未提交但 verify 通过的 trial 可碾压正常 commit 但 verify 失败的对手胜出（105 vs ≤35 的场景数字成立）。
3. verify 仅要求 status == "completed"，在 dirty 未提交树上执行——sub-agent 忽略"commit all changes"软提示词时成果仅存在于工作树。
4. anyUsable 认 Commits > 0 || VerifyPass（L240-245）而 keep 只认 Commits——同一 trial 的 usable 语义两处矛盾实证。
5. 报告对零 commit 胜者仍输出 adopt 提示（git diff base..branch | git apply 为空 diff）+anyUsable=true+IsError=false——调用方被误导有可用产出。

cleanupWorktrees 注释 "no committed work is lost" 精确但掩盖未提交丢失。

拟修复（最小化，选项一）：keep 条件放宽为 Commits > 0 || VerifyPass（与 anyUsable 语义对齐）——verify 通过的胜者 worktree 保留供检视/手工提取，未提交成果不再销毁。快照自动提交（选项二）改变 git 状态语义不采；报告对零 commit 胜者补 warning 行（提示 adopt diff 为空、成果在保留的 worktree 中）。

验证计划：探针钉 keep 判定逻辑（verify-passed 零 commit 胜者必须 keep——修复前 FAIL 钉根因）+既有 trial_fork 族回归。

[topcheer]

已修复（分支 fix/issue-2795，FRESH 队列等 PR 窗口，暂不关闭）。

根因（五主张全实证）：keep 门 winner.Commits > 0 单条件，而打分 VerifyPass=100 分（Commits 仅 20）且 verify 在 dirty 未提交树上执行——零 commit 的 verify-passed trial 可胜出后其 worktree 被 remove --force 销毁，全部已验证未提交工作不可恢复；与 anyUsable 的 Commits>0||VerifyPass 语义矛盾；报告仍输出空 diff adopt 提示+IsError=false 误导调用方。cleanupWorktrees 注释"no committed work is lost"精确但掩盖未提交丢失。

改动（issue 建议选项一，最小化）：

1. keep 门放宽为 Commits > 0 || VerifyPass——与 anyUsable 语义对齐，verify-passed 胜者 worktree 保留供检视/手工提取，未提交成果不再销毁。
2. 报告对零 commit 胜者补 warning 行（adopt diff 为空、已验证成果在保留的 worktree 中），消除空 diff 管道误导。
3. 快照自动提交（选项二）改变 git 状态语义不采。

验证：zz_issue2795_test.go 双源级守卫探针（keep 门含 VerifyPass/报告零 commit warning——对 main 原文均缺失 FAIL 钉根因→修复后 PASS；live 探针因 harness stub 注册表固定而 skip，注记在案）。既有 TestTrialForkRunSelectsWinner（live worktree 保留断言）/TestTrialForkRunAllFailed（全败清理断言）/TestScoreAndPickWinner 族全绿——正常 commit 胜者与全败清理两条路径行为不变。build+gofmt 净。

[topcheer]

修复已就绪于 fix/issue-2795（c8e8f6208：keep 条件放宽 + zz_issue2795_test.go 91 行钉死），PR 窗口当前 6 open ≥2 节流中，窗口释放后即开 PR。