企业官网建设流程全解析

get-shit-done 子代理报失败但提交已存在时如何判断是误报

【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done

在 get-shit-done 中执行/gsd:code-review <phase> --fix时，工作流会派生gsd-code-fixer子代理去修复 REVIEW.md 中的问题。你有时会遇到这样的情况：子代理报了失败（或输出⚠ No fix report generated），但git log里却能看到几条fix(...)提交。这篇文章给出文档定义的判断路径：先确认修复报告REVIEW-FIX.md是否存在，再用git log核对修复提交，最后结合恢复哨兵文件判断这次"失败"是文档定义的**部分成功（partial success）**还是真正需要重跑的执行错误。

先理解文档对这个现象的定义

get-shit-done 的修复流程是按 finding 逐条提交的：gsd-code-fixer每修好一个问题就立刻原子提交一次，而REVIEW-FIX.md报告是在全部 finding 处理完之后才写的。gsd-code-fixer agent 文档在Partial Failure Semantics一节明确说明：

• Mid-run crash（运行中途崩溃）：部分 fix 提交可能已经存在于 git 历史中，这是BY DESIGN—— 每个提交都是自包含且正确的，即使 agent 在写 REVIEW-FIX.md 之前崩溃，这些提交依然有效。
• Agent failure before REVIEW-FIX.md（报告写之前就失败）：工作流检测到 REVIEW-FIX.md 缺失，会提示Agent failed. Some fix commits may already exist — check git log.，然后由用户检查提交并决定下一步。

也就是说，"报失败"指的是子代理没有跑完整个流程，不等于提交无效。文档没有使用"误报"这个词，而是把它定义为按设计工作的部分成功语义。你要做的是用下面的检查确认现有提交是否为真实修复。

判断步骤

以下三步都来自 code-review-fix 工作流 的Agent failure handling、commit_fix_report和present_results步骤。

1. 检查 REVIEW-FIX.md 是否存在

修复报告路径由工作流计算为：

FIX_REPORT_PATH="${PHASE_DIR}/${PADDED_PHASE}-REVIEW-FIX.md"

其中PHASE_DIR是阶段目录（例如.planning/phases/02-code-review-command），PADDED_PHASE是补零后的阶段号（例如02）。检查文件是否存在即可，例如：

ls .planning/phases/02-code-review-command/02-REVIEW-FIX.md

（将路径替换为你项目实际的阶段目录与阶段号。）

文档定义了两个分支：

• 报告存在→ 工作流判定为Partial success — some fixes may have been committed.，说明部分修复已提交，继续第 2、3 步核对。
• 报告不存在→ 工作流提示No fixes applied.，但文档仍然要求Some fix commits may already exist in git history — check git log for fix(${PADDED_PHASE}) commits.，所以不能跳过第 2 步。

2. 用 git log 核对修复提交

文档给出的检查方式是在 git log 中查找以fix(<阶段号>)开头的提交。gsd-code-fixer的提交消息格式在 agent 文档 中固定为：

fix({padded_phase}): {finding_id} {short_description}

文档给出的示例（示例结果）：

fix(02): CR-01 fix SQL injection in auth.py fix(03): WR-05 add null check before array access

因此核对命令可以写成（02换成你的补零阶段号）：

git log --oneline | grep "fix(02):"

看到符合该格式、且 finding_id（如CR-01、WR-05）能与 REVIEW.md 中的 finding 对应的提交，就说明这些是 fixer 按设计提交的修复提交，而不是其他来源的提交。

3. 报告存在时交叉核对数量

如果REVIEW-FIX.md存在，文档要求用它的 frontmatter 做一致性核对。frontmatter 包含findings_in_scope、fixed、skipped、iteration和status字段，取值：

• all_fixed：范围内所有 finding 均已修复；
• partial：部分修复、部分跳过；
• none_fixed：全部跳过，未应用修复。

agent 文档 的REVIEW-FIX.md accuracy一节给出的核对标准是：Fixed count matches number of commits made（fixed 计数与已创建的提交数一致），skipped 原因逐条有记录。如果报告中的fixed数与你在第 2 步数到的fix(<阶段号>)提交数一致，且报告状态与"报失败"的时点吻合（例如 agent 在写完报告后的清理阶段中断），那么这次失败报告可以判定为文档定义的部分成功场景，提交可以保留。

4.（可选）检查恢复哨兵，判断是否发生过中断

gsd-code-fixer在独立 worktree 中工作。文档说明：如果进程在最后一次提交和git worktree remove之间被中断（系统重启、OOM kill 等），阶段目录下会留下恢复哨兵文件：

ls .planning/phases/02-code-review-command/.review-fix-recovery-pending.json

哨兵存在说明上次运行在收尾阶段被中断——这正是"有提交、但流程报了失败"的一个已记录成因。此时文档给出的处理方式是：重新运行/gsd:code-review <phase> --fix即可自愈，新运行会解析旧哨兵、尽力清理孤儿 worktree 和临时分支（gsd-reviewfix/<阶段号>-<pid>），然后删除旧哨兵再开始（对应缺陷 #2839）。

判断结论与下一步

把上面结果组合起来：

下一步操作以文档为准：

• 重试：/gsd:code-review <phase> --fix。注意文档明确说明，对同一份 REVIEW.md 重跑 fixer可能产生不同结果（fixer 适应当前代码状态而非历史审查上下文），这不是 bug。
• 如果REVIEW-FIX.md的 status 最终为all_fixed，工作流给出的下一步是/gsd:verify-work验证阶段完成。
• 工作流文档 code-review-fix.md 的平台说明：该流程依赖 bash 特性，Windows 上需要 Git Bash 或 WSL，不支持原生 PowerShell。

相关文档：code-review 命令、gsd-code-fixer agent、code-review-fix 工作流、USER-GUIDE。

【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done