系统化调试方法论（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/` |
显著优点
1. 根治而非治标：Iron Law 强制阻断"快速修复"冲动，避免技术债务累积
2. 可复现性优先：要求确定性复现，杜绝玄学调试
3. 知识沉淀：调试报告持久化存储，识别"反复出问题的代码区域"这一架构坏味道
4. 防御性决策：3-strike规则、>5文件改动预警等机制防止过度自信
潜在局限
- 时间成本高：简单Bug可能需数倍于传统调试的时间
- 依赖信息完整度：若用户无法提供复现步骤，Phase 1 可能长时间阻塞
- 间歇性问题挑战：竞态条件等难以稳定复现的场景，可能触发 DONE_WITH_CONCERNS 状态
- 不适合紧急止血：生产事故需快速回滚时，此流程可能过于沉重
适合人群
- 复杂遗留系统的维护团队
- 高频出现"修复一个Bug引入两个Bug"场景的开发组
- 追求可维护性优先于交付速度的工程项目
常规风险
- 过度工程化风险：简单拼写错误仍走完整流程会造成浪费
- 认知负荷：多阶段上下文切换对新手不友好
- 工具链依赖：需配合 Git、结构化日志、内存存储等基础设施
安全评估
流程本身不执行代码，仅提供方法论指导，无直接安全风险。但 Phase 2 建议的"外部搜索"环节要求先脱敏再搜索，已内置数据安全意识。