（1434期）gstack Investigate – 系统化根因调试，根治技术债务

系统化根因调试，根治技术债务 四阶段系统化调试方法论，强制根因调查后再修复，杜绝治标不治本的"打地鼠"式调试 使用说明 系统化调试方法论（OpenClaw Investigate） 核心用法 gstack-openclaw-investigate 是一套严格的四阶段调试框架，核心原则是"Iron Law：未经根因调查，不得修复"。当用户遇到错误、堆栈跟踪、异常行为或功能失效时自动触发。 四阶段流程： | 阶段 | 目标 | 关键动作 ||------|------|----------|| Phase 1: Root Cause Investigation | 收集证据 | 读取错误信息、追溯代码路径、检查近期变更 (git log)、确认可复现性 || Phase 2: Pattern Analysis | 模式匹配 | 对照6类已知缺陷模式（竞态条件、空值传播、状态损坏、集成失败、配置漂移、缓存失效） || Phase 3: Hypothesis Testing | 验证假设 | 添加临时日志/断言确认假设，实行3-strike规则——3次失败则停止并上报 || Phase 4: Implementation | 精准修复 | 最小化改动、编写回归测试、全量测试通过 || Phase 5: Verification & Report | 验证归档 | 原始场景复测、结构化调试报告写入 memory/ | 显著优点 根治而非治标：Iron Law 强制阻断"快速修复"冲动，避免技术债务累积 可复现性优先：要求确定性复现，杜绝玄学调试 知识沉淀：调试报告持久化存储，识别"反复出问题的代码区域"这一架构坏味道 防御性决策：3-strike规则、>5文件改动预警等机制防止过度自信 潜在局限 时间成本高：简单Bug可能需数倍于传统调试的时间 依赖信息完整度：若用户无法提供复现步骤，Phase 1 可能长时间阻塞 间歇性问题挑战：竞态条件等难以稳定复现的场景，可能触发 DONEWITHCONCERNS 状态 不适合紧急止血：生产事故需快速回滚时，此流程可能过于沉重 适合人群 复杂遗留系统的维护团队 高频出现"修复一个Bug引入两个Bug"场景的开发组 追求可维护性优先于交付速度的工程项目 常规风险 过度工程化风险：简单拼写错误仍走完整流程会造成浪费 认知负荷：多阶段上下文切换对新手不友好 工具链依赖：需配合 Git、结构化日志、内存存储等基础设施 安全评估 流程本身不执行代码，仅提供方法论指导，无直接安全风险。但 Phase 2 建议的"外部搜索"环节要求先脱敏再搜索，已内置数据安全意识。 原始说明 Provides systematic root cause analysis and verified fixes for bugs or errors using a four-phase debugging process without guessing or premature fixes.