get-shit-done Node Repair 工作流解析：任务验证失败后的自主修复算子-北京尧图网络

get-shit-done Node Repair 工作流解析任务验证失败后的自主修复算子【免费下载链接】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 系统中的node-repair 工作流get-shit-done/workflows/node-repair.md——一个在计划任务plan node未通过完成标准done-criteria验证时自动介入的自主修复算子。它由 execute-plan.md 中的verification_failure_gate在任务验证失败时触发在把问题抛回给用户之前先按纪律尝试 RETRY重试、DECOMPOSE拆分、PRUNE剪除三种结构化修复策略。读完本文你将掌握该工作流的触发条件、四类修复策略的选择逻辑、修复预算REPAIR_BUDGET的运作机制以及如何通过config.json的两个配置键workflow.node_repair与workflow.node_repair_budget对它进行开关与调参并理解其在 get-shit-done 自主执行体系中的位置。一、为什么需要自主修复算子验证失败是执行流程的常态在 get-shit-done 的规范驱动spec-driven执行模型中每个任务都必须通过验收标准acceptance_criteria验证才能继续。在 execute-plan.md 的execute步骤中有一条 HARD GATE硬性闸门完成任务后若存在acceptance_criteria必须运行验证循环逐条执行 grep、文件检查或 CLI 命令来证明标准通过任何一条标准失败任务就被视为未完成且被阻塞在下一任务之前。现实世界的失败原因多种多样命令路径写错、依赖缺失、环境变量未就绪、任务粒度过粗导致验收标准混杂了多个关注点、甚至前置条件根本不存在。若每次失败都直接中断并询问用户会显著拖慢自主执行节奏若让 Agent 无限重试又可能陷入无效循环或擅自做出越权决策例如悄悄修改架构方向。node-repair 工作流正是这两者之间的纪律层在预算REPAIR_BUDGET约束下自主、有结构、可审计地尝试修复预算耗尽或涉及架构决策时才升级ESCALATE给用户。这一点与其在 FEATURES.md 中登记的需求REQ-REPAIR-06系统必须可通过workflow.node_repair_budget与workflow.node_repair配置相呼应。二、触发场景与输入参数谁在什么情况下调用它node-repair 不是独立运行的命令而是由执行编排器在任务验证失败这个精确时机调用的子工作流。调用入口位于 execute-plan.md 的verification_failure_gate步骤NODE_REPAIR$(gsd-sdk query config-get workflow.node_repair 2/dev/null || echo true)若workflow.node_repair为true默认开启则加载并调用 node-repair.md若为false则跳过修复直接进入面向用户的验证失败闸门若 node-repair 返回ESCALATE预算耗尽同样会回到该闸门。调用时需要向 node-repair 提供四个输入对应文档中的inputs块输入含义来源FAILED_TASK失败任务的任务编号、名称与 done-criteria计划PLANERROR验证产出实际结果 vs 期望结果验证循环输出PLAN_CONTEXT相邻任务与阶段目标用于约束感知执行上下文REPAIR_BUDGET剩余修复尝试次数默认2workflow.node_repair_budgetPLAN_CONTEXT的用意很关键修复不是孤立发生的修复方案必须与相邻任务和当前阶段目标兼容防止某个修复动作修好了 A 却破坏了 B。而REPAIR_BUDGET则从机制上防止无休止的自我修复。三、四种修复策略RETRY / DECOMPOSE / PRUNE / ESCALATEnode-repair 的核心是repair_directive分析失败原因后必须且只能选择一种修复策略。四种策略的语义、适用场景与输出格式如下策略何时使用典型触发场景输出格式RETRY方法正确但执行失败命令错误、依赖缺失、路径错误、环境问题、瞬时失败RETRY: [重试前需做的具体调整]DECOMPOSE任务粒度过粗实现缺口是结构性的done-criteria 覆盖多个关注点DECOMPOSE: [子任务1] \| [子任务2] \| ...最多 3 个PRUNE当前约束下任务不可行前置条件缺失且此处无法修复、超出范围、与先前决策矛盾PRUNE: [一句话理由]ESCALATE修复预算耗尽或涉及架构决策对应偏差规则 Rule 4RETRY 用不同方案失败超过一次、修复需要结构性变更ESCALATE: [已尝试的内容] \| [需要做的决策]几个值得注意的设计要点RETRY 不是盲目重试它要求先给出具体调整再重试即每次重试都必须携带一次实质性的修正而非原地重跑。DECOMPOSE 的子任务必须有单一可验证结果并且文档在constraints中明确要求拆出来的子任务必须比原任务更具体而不是同义改写。这是防止假拆分把一个失败任务换个说法拆成三个还是同样失败的任务的关键约束。PRUNE 需要理由跳过任务不是默许的必须在 SUMMARY 中留下可审计的剪除理由。ESCALATE 对应偏差规则 Rule 4在 execute-plan.md 的deviation_rules中Rule 1-3bug、关键缺失、阻塞允许自动修复而Rule 4架构性变更必须 STOP 并等待用户批准。node-repair 的 ESCALATE 正是该规则在修复场景中的落地。四、诊断决策流程五问定策略node-repair 的process以diagnose步骤开场要求修复算子仔细阅读错误与 done-criteria并按顺序自问四个问题这是瞬时/环境问题吗→RETRY任务是否可验证地过于宽泛→DECOMPOSE前置条件是否确实缺失且在范围内无法修复→PRUNE该任务是否已经尝试过 RETRY检查REPAIR_BUDGET若为 0 →ESCALATE这组问题构成一条明确的决策漏斗先排除擦一擦就能过的表面问题再判断是不是任务划分本身的问题再排除不可行任务最后才把真正啃不动的硬骨头交给用户。整个诊断过程强约束在计划上下文PLAN_CONTEXT内进行避免修复动作越出当前阶段的边界。五、四种策略的执行过程5.1 RETRY带着具体调整重来应用指令中声明的具体调整重新运行任务实现重新运行验证通过 → 继续正常流程并在日志中记录[Node Repair - RETRY] Task [X]: [调整内容]再次失败 →递减REPAIR_BUDGET携带更新后的上下文重新调用 node-repair。注意第 5 步RETRY 失败后会递归进入下一轮修复但预算每轮递减直至归零触发 ESCALATE。文档约束也写明RETRY 用不同方案失败超过一次即应升级。5.2 DECOMPOSE在内存中拆分绝不改盘上的 PLAN.md就地用子任务替换失败任务constraints明确要求绝不修改磁盘上的 PLAN.md拆分的子任务仅在内存中存在顺序执行各子任务每个子任务独立验证全部通过 → 原任务视为成功记录[Node Repair - DECOMPOSE] Task [X] → [N] sub-tasks某子任务失败 → 针对该子任务重新调用 node-repairREPAIR_BUDGET按子任务分别计数。不落盘这条约束意义重大它把修复过程与计划文档的持久化状态解耦避免 Agent 为了让验证通过而悄悄改写计划本身——计划是规范修复是执行层的应变两者不能混为一谈。5.3 PRUNE带理由地跳过将任务标记为 skipped跳过并附理由在 SUMMARY 的 Issues Encountered 中记录[Node Repair - PRUNE] Task [X]: [理由]继续下一个任务。5.4 ESCALATE带着完整修复历史回到用户通过verification_failure_gate将问题呈现给用户附完整修复历史呈现内容每次 RETRY/DECOMPOSE 尝试了什么、当前阻塞点是什么、有哪些可选方案等待用户指示后再继续——不允许自作主张。升级到用户侧后execute-plan.md 的verification_failure_gate会以固定格式呈现Verification failed for Task [X]: [name]. Expected: [criteria]. Actual: [result]. Repair attempted: [summary of what was tried].并给出三个选项Retry重试、Skip标记为未完成跳过、Stop停止调查。若用户选择跳过则记入 SUMMARY 的 Issues Encountered。六、日志规范每一次修复都必须可审计node-repair 的logging块要求所有修复动作必须出现在SUMMARY.md的 ## Deviations from Plan 小节下格式统一类型格式RETRY 成功[Node Repair - RETRY] Task X: [adjustment] — resolvedRETRY 失败 → ESCALATE[Node Repair - RETRY] Task X: [N] attempts exhausted — escalated to userDECOMPOSE[Node Repair - DECOMPOSE] Task X split into [N] sub-tasks — all passedPRUNE[Node Repair - PRUNE] Task X skipped: [justification]这与 execute-plan 的deviation_documentation要求一致SUMMARY 必须包含偏差小节若无偏差则写None - plan executed exactly as written.。统一格式的意义在于无论是人工复盘还是后续的审计/verifier 流程都能从 SUMMARY 中快速还原每个任务失败后到底发生了什么。七、约束与配置两个键控制整个修复机制node-repair 的constraints块给出了三条硬性约束REPAIR_BUDGET每个任务默认 2可通过config.json的workflow.node_repair_budget配置绝不修改磁盘上的 PLAN.md拆分的子任务仅存在于内存若config.json中workflow.node_repair为false直接跳到verification_failure_gate保持用户原本的行为即不做任何自主修复。配置默认值在整个仓库中保持一致可以从多个层面交叉印证docs/CONFIGURATION.md 中的默认配置片段workflow: { ... node_repair: true, node_repair_budget: 2, ... }get-shit-done/references/planning-config.md 的配置参考表workflow.node_repairboolean默认true取值true/false对失败的计划节点尝试自动修复、workflow.node_repair_budgetnumber默认2任意正整数每个失败节点的最大修复重试次数sdk/shared/config-defaults.manifest.json 中的 SDK 默认值清单同样登记node_repair: true与node_repair_budget: 2从源码结构看sdk/src/query/config-gates.ts 通过node_repair: workflowBool(wf.node_repair, true)读取该配置缺省时回退为trueget-shit-done/bin/lib/config.cjs 中也以node_repair: true、node_repair_budget: 2作为默认值测试侧tests/config.test.cjs 显式断言默认配置中config.workflow.node_repair true且config.workflow.node_repair_budget 2tests/gsd-settings-advanced.test.cjs 也将这两个键列入高级设置默认值清单。一个常见的调参场景对于失败率较高但危害较小的探索性任务可以把node_repair_budget从 2 调高到 3planning-config.md 的配置示例中即展示了node_repair_budget: 3的写法反之对于高风险的执行阶段如发布流程则可以将其调低甚至将workflow.node_repair设为false让每次验证失败都直接交由人工决策。八、在更大执行体系中的位置修复只是执行纪律的一环node-repair 并非孤立存在它嵌在 get-shit-done 的执行纪律链中验收硬门acceptance_criteria HARD GATE每个任务完成后强制验证失败即阻塞偏差规则deviation_rulesRule 1-3 自动修复并记录偏差Rule 4架构变更STOP 等待用户——与 ESCALATE 策略一一对应验证失败闸门verification_failure_gate作为 node-repair 的调用入口与升级出口负责读取workflow.node_repair配置、注入四个输入参数、接收 ESCALATE 结果并向用户呈现完整修复历史修复算子node-repair本文主体在闸门与用户之间插入一层受预算约束的自主修复。从职责划分看闸门管要不要修、何时交回给人node-repair 管怎么修、修到什么程度算完。两者配合使 get-shit-done 在保持自主执行节奏的同时始终把架构级决策权和最终判断权保留在用户手中——这正是其轻量但强大的执行体系设计意图的缩影。总结node-repair 工作流通过诊断四问四策略预算约束统一日志的机制把任务验证失败后的处理从无限重试或直接打断用户两个极端中解放出来能擦的擦RETRY、能拆的拆DECOMPOSE、该弃的弃PRUNE、碰到底线的交人ESCALATE。配合workflow.node_repair/workflow.node_repair_budget两个配置键团队可以按阶段风险自由调节自主程度。如果你正在使用或研究 get-shit-done 的规范驱动执行流程node-repair.md 及其调用方 execute-plan.md 是理解其自主但有纪律哲学的最佳起点。【免费下载链接】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 Node Repair 工作流解析：任务验证失败后的自主修复算子

相关推荐

DDR内存调试核心：ODT、ZQ校准与Vref的联动解析

STM32双串口同时中断接收实战：优先级配置与HAL库回调拆分

BMI160六轴传感器STM32驱动开发与调试实战指南

更多资讯

STM32F407ZGT6标准库工程模板搭建避坑指南

格式工厂v2.70绿色版实测：从视频格式转换到老文件归档

Android端跌倒检测识别Demo解析：基于MediaPipe的人体姿态关键点实现

LLC模块并联均流实战：硬件均流+PI控制+PFM变频调参全解析

海康威视NVR WEB管理端实战指南：插件机制、RTSP取流与故障排查

ICM45686六轴IMU驱动开发实战：从寄存器配置到数据稳定读取

今日更新

CopilotKit Vue Demo 与 React Demo 的 Parity 实现指南：路由、运行时端点与交互语义的全框架对齐

Harbor RBAC 实战：db_auth 模式下非管理员用户管理项目成员的完整验证与权限模型解析

STM32平衡车纯平衡程序从拆包到参数整定的完整调试指南

本周精选

超人会飞不算本事：系统稳定依赖清晰规则与边界设计

超人VS蜘蛛侠：拆解超级IP的影响力与传播方法论

基于CNN的调制信号识别：MATLAB实现时频图分类实战

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？