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-commandPADDED_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 madefixed 计数与已创建的提交数一致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。判断结论与下一步把上面结果组合起来现象文档定义的判定fix(0X):提交存在REVIEW-FIX.md 缺失部分成功提交有效报告缺失检查提交后决定下一步fix(0X):提交存在报告存在且fixed数与提交数一致修复实际已完成或大部分完成失败发生在报告之后/清理阶段恢复哨兵.review-fix-recovery-pending.json存在上次运行在清理阶段被中断重跑命令自愈git log中没有任何fix(0X):提交文档提示的No fixes applied.情形成立失败为真实失败下一步操作以文档为准重试/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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 get-shit-done 子代理报失败但提交已存在时如何判断是误报
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-commandPADDED_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 madefixed 计数与已创建的提交数一致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。判断结论与下一步把上面结果组合起来现象文档定义的判定fix(0X):提交存在REVIEW-FIX.md 缺失部分成功提交有效报告缺失检查提交后决定下一步fix(0X):提交存在报告存在且fixed数与提交数一致修复实际已完成或大部分完成失败发生在报告之后/清理阶段恢复哨兵.review-fix-recovery-pending.json存在上次运行在清理阶段被中断重跑命令自愈git log中没有任何fix(0X):提交文档提示的No fixes applied.情形成立失败为真实失败下一步操作以文档为准重试/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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考