debuglisted

# Debug Skill ## 目标 当 verify 门禁失败时，自动分析错误并尝试修复。 最多尝试 N 次（默认 3），超过则暂停等待人工。 ## 执行流程 ``` verify.fail │ ▼ [分析错误类型] │ ├── 编译错误 → 语法/类型修复 ├── 测试失败 → 逻辑修复 ├── 启动失败 → 配置/依赖修复 └── 安全问题 → 报告给用户（不自动修复） │ ▼ [应用修复] │ ▼ [重新 verify] │ ├── PASS → 继续流程 └── FAIL → 递增计数器 │ ├── count < limit → 重新分析 └── count >= limit → 断路器打开 ``` ## 错误分析策略 ### 编译错误 ``` 1. 提取错误信息（文件、行号、错误类型） 2. 读取相关代码上下文（前后 10 行） 3. 判断错误类型： - 类型错误 → 修正类型定义 - 导入错误 → 修正导入路径 - 语法错误 → 修正语法 - 缺失定义 → 补充定义 4. 应用修复 5. 重新编译验证 ``` ### 测试失败 ``` 1. 提取失败的测试名和断言信息 2. 区分： - 测试本身有误 → 不修改测试（除非明确是测试 bug） - 实现逻辑有误 → 修改实现代码 3. 读取测试期望和实际输出的差异 4. 分析 root cause 5. 修复实现代码 6. 重新运行失败的测试 ``` ### 启动失败 ``` 1. 检查启动日志 2. 常见原因： - 端口占用 → 使用其他端口或等待 - 环境变量缺失 → 检查 .env.example - 依赖未安装 → 运行安装命令 - 配置错误 → 修正配置文件 3. 修复后重新启动验证 ``` ## 已知问题匹配 在尝试修复前，先检查 `known-issues.md`： - 如果错误模式匹配已知问题 → 直接应用已知解法 - 节省反复试错的时间 ## 修复记录 每次修复都记录： ```markdown ## Debug Attempt {N} - Gate: {which gate failed} - Error: {error message} - Analysis: {root cause} - Fix: {what was changed} - Result: {pass/still-fail} ``` ## 断路器 ```yaml circuit_breaker: max_attempts: 3 # 同一错误最多尝试 3 次 consecutive_fails: 2 # 连续 2 个不同错误也触发 cooldown: "human_input" # 暂停等待人工 output_on_break: - error_summary - attempted_fixes - suggested_directions - related_known_issues ``` ## 暂停时输出格式 ```markdown # Debug Paused — Human Input Needed ## 问题 {错误描述} ## 已尝试