当 .NET 构建损坏或测试失败且错误会级联时…

适用于 .NET 项目在重构、依赖升级、合并或代码生成后出现构建错误或测试失败，需要自动迭代修复并避免无限重试的场景。

适用场景

解决思路

1. 有界迭代：默认最多 5 轮，硬上限 10 轮；用户说 keep going 可加 3 轮，但不超过 10 轮；超过 5 轮仍无法解决就交给人工判断，不要重复第 6 次相同尝试。
2. 进展或退出：每轮必须减少错误/失败数；修复后错误相同视为 STUCK，停止、报告并重新规划不同方案；绝不重试已经失败的同一修复。
3. 先分类再修复：按根因分组错误，先修最高杠杆项，例如一个缺失的 using 可消除大量下游错误。
4. 每轮透明报告：报告改动及原因，例如 `Iteration 3/5: fixed CS0246 by adding using System.Text.Json, 2 remain`；绝不静默修改文件。
5. 原子性：每轮结束后代码库不差于之前；如果第 3 轮失败，代码保持第 2 轮状态。
6. 按 build-fix 主循环最多 5 轮执行：运行 `dotnet build`，捕获完整错误输出。
7. 解析每个 `error CS####`，提取文件、行号和消息。
8. 按根因分类，并按下表策略修复：缺失 using/引用 CS0246、CS0234 → 添加 using、包或项目引用；类型不匹配 CS0029、CS1503 → 检查期望类型，转换或强制转换；API 变更 CS0117、CS7036 → 检查新签名，更新调用点；可空性 CS8600–CS8604 → 添加 null 检查、`?.` 或 `??`；歧义/重复 CS0104、CS0121、CS0111 → 限定命名空间，删除重复项；缺失成员 CS1061 → 检查拼写，验证成员存在；缺失实现 CS0535 → 实现接口/抽象成员；过时 API CS0618 → 替换为推荐替代项。
9. 应用针对性修复，优先处理根因/最高杠杆错误。
10. 再次运行 `dotnet build`，比较错误数。
11. 评估：零错误则运行 `dotnet test` 做健全检查并报告成功；错误减少则继续；错误相同则 STUCK——退出并重新规划；错误增加则回退该轮，报告 REGRESSION。
12. 使用 test-fix 变体：相同循环和守卫，运行器为 `dotnet test --no-build`，最大 5 轮；如果紧跟在 build-fix 轮之后则最多 3 轮。
13. 修复前先诊断：阅读测试，理解断言和 setup。
14. 阅读生产代码，理解实际行为。
15. 判断 bug 位置：期望错误 → 修测试；生产 bug → 修代码；setup 不完整 → 修 setup；契约变更 → 更新测试以匹配。
16. 绝不为了通过测试而弱化断言。反例：`Assert.Equal(expected, actual)` → `Assert.NotNull(actual)`；正确：修生产代码，使原始断言通过。
17. STUCK 守卫：修复后错误/失败相同，或数量震荡（3 → 2 → 3）时立即退出；报告无法修复的内容和人工应检查什么。
18. REGRESSION 守卫：某轮引入的错误多于修复的错误时，回退该轮改动并报告。
19. 级联失败守卫：修复一个错误连续两次各自引发 3+ 个新错误，说明方法错误，停止。
20. 关键错误守卫：SDK 错误、缺少项目文件、解决方案损坏或测试运行器本身失败，需要人工介入，停止。
21. 用户中断守卫：完成当前轮，报告进展，询问如何继续。
22. 同一套纪律（有界迭代、进展检测、故障安全守卫）也约束重构过程：`/de-sloppify` 在每个目标后验证 build + tests，失败则回退。
23. 同一套纪律也约束脚手架过程：`/scaffold` 生成后运行嵌套的 build-fix 和 test-fix 循环。
24. 嵌套循环预算更小：父 5 → 嵌套 3，最大嵌套深度 2，总预算 15。
25. 调用 `instinct-system` skill，将修复模式记录到 MEMORY.md。
26. 咨询 `dotnet-architect` agent，处理架构性错误模式。
27. 使用 MCP 工具 `get_diagnostics` 获取文件或项目范围的编译器错误/警告。
28. 使用 MCP 工具 `find_symbol` 定位被移动或重命名的类型。
29. 使用 MCP 工具 `find_references` 评估破坏性 API 变更的影响范围。
30. 使用 MCP 工具 `get_project_graph` 获取修复引用错误时的依赖顺序。

适用边界 · 注意事项

• 不适用于非 .NET 项目，因为主流程围绕 `dotnet build` 和 `dotnet test`。
• 当没有安装 .NET SDK 或无法运行 `dotnet` CLI 时，不应使用。
• 当问题需要人工判断、架构决策，或已触发关键错误/STUCK 后，不应继续自动循环。