技能 (Skill)：运行修复循环（回顾+测试+修复）

目的 (Purpose)

通过运行 多次迭代循环 将代码库收敛或更改设置为“干净”：

回顾（及早发现问题并防止倒退），
测试（获取可执行信号），
修复（应用最小的正确补丁），
重复直到不再存在阻塞问题或达到停止条件。

核心目标（Core Objective）

首要目标：使用有界的、证据驱动的审查-测试-修复循环，将存储库收敛到“干净”状态——所有测试都通过并且没有“关键”/“主要”审查结果。

成功标准（必须满足所有要求）：

✅ 完成解析的定义：在循环开始之前确认飞行前选择（范围、测试模式、最大迭代、允许的操作）
✅ 每次迭代证据优先：每次迭代至少产生以下之一：新的测试结果、新的审查信号或具体的代码更改
✅ 修复后重新运行测试：失败的测试命令（或目标子集）始终在同一迭代中应用修复后重新运行
✅ 有界循环：循环由于收敛或显式停止条件而终止 - 没有无限重试
✅ 结构化最终报告：输出包括修复循环报告（附录：输出合约），其中包含命令运行、故障、补丁和剩余风险

验收测试：最终报告是否显示（a）测试通过且没有阻止审查结果，或（b）明确的停止条件，并为用户提供明确的剩余问题和选项？

范围边界 (Scope Boundaries)

本技能负责：

多次迭代审查→测试→修复循环
使用“review-diff”和“review-code”进行差异范围和代码库范围的审查
通过“run-automated-tests”执行测试（快速/ci/完整模式）
保留 API 合约的最少目标补丁
停止条件检测（无进展、环境阻碍、片状测试、迭代限制）
结构化修复循环报告输出

本技能不负责：

在没有明确用户确认的情况下安装依赖项
无需用户确认即可使用网络或启动 Docker/服务
未经用户明确批准的大型重构
修改不相关的同级存储库
在未经用户明确批准的情况下禁用测试、削弱断言或删除覆盖范围

转交点：当环路收敛或达到停止条件时，向用户呈现修复环路报告。对于有风险的更改（架构迁移、身份验证更改、广泛重构），请在申请之前暂停并请求明确批准。

使用场景（用例）

“继续修复直到测试通过。”
“进行审查-测试-修复循环并使存储库变得绿色。”
“通过迭代测试和有针对性的修复来稳定此 PR/变更集。”
“运行类似 CI 的测试，修复故障，重复直到稳定。”

行为（行为）

1. 飞行前（必须解决一次）

若存在 CLAUDE.md 或 .ai-cortex/config.yaml，优先读取其中的 test_command 等；否则按发现逻辑获取。参见 docs/guides/project-config.md。

确认或默认以下内容：

目标：存储库路径（默认“.”）和范围：
- diff（默认）：关注当前更改，优先考虑review-diff。
- codebase：审查指定的路径集，通过review-code优先考虑review-codebase/语言技能。
完成的定义：
- 测试：所选测试计划通过（快速/ci/完整）。
- 审查：没有保留“关键”/“主要”审查结果。
- 如果仅剩下“次要”/“建议”发现，请将其列出并询问是否解决它们。
循环边界：
- max_iterations 默认值：5。
- time_budget 默认值：“尽力而为”；如果用户提供了时间限制，请严格遵守。
允许的操作（不清楚时询问；默认为更安全的选择）：
- 修改存储库文件：是（此技能用于修复），但保持最小程度的更改。
- 安装依赖项：否，无需确认。
- 网络访问：否，无需确认。
- Docker/服务（DB/Redis/等）：否，无需确认。
- 大型重构：否，未经确认。

2.迭代循环

对于“i = 1..max_iterations”：

收集当前信号（证据优先）
- 如果范围 = diff：对当前 diff/未跟踪的添加运行/执行 review-diff 传递。
- 如果范围=“代码库”或用户想要更深入的审查：运行“审查代码”（或相关的原子审查技能）。
- 如果之前的迭代出现测试失败，请优先考虑首先解决这些失败。
运行测试
- 使用“run-automated-tests”在所选模式下发现并运行最匹配的测试命令：
  - fast（默认）：仅进行单元测试，最少的设置。
  - ci：尽可能接近地镜像 CI 步骤。
  - full：包括集成/e2e（仅对依赖项/服务进行明确确认）。
- 捕获：
  - 第一个失败的命令+退出代码
  - 最相关的错误摘录（除非要求，否则不要转储大量日志）
综合修复计划（最小正确补丁）
- 选择首先要解决的一个主要问题：
  - 第一个失败的测试/命令通常获胜（最高信号）。
  - 如果审查发现“关键”安全/正确性问题，请在测试之前或同时修复该问题。
- 更喜欢修复：
  - 改变最小表面积
  - 保留 API/合同，除非明确批准
  - 修复错误时添加或调整测试（如果可行）
应用修复
- 实施补丁。
- 避免不相关的格式或流失。
- 如果修复需要进行有风险的更改（架构迁移、身份验证更改、广泛重构），请暂停并询问。
重新运行最小验证
- 如果框架支持，重新运行最相关的失败测试子集；否则重新运行相同的测试命令。
- If fixed, proceed to the next remaining failure/finding within the same iteration only if it is trivial;否则进入下一个循环迭代。
汇合时尽早停车
- 如果测试通过并且没有“关键”/“主要”审查结果，则停止。

3.停止条件（不得永远循环）

如果发生任何情况，请停止并向用户询问方向：

没有进展：同样的失败重复了 2 次迭代，没有新信息。
环境拦截器：缺少工具链、缺少机密或不可用的依赖项（DB/Docker）并且用户尚未批准所需的设置。
片状测试：怀疑不确定性故障（例如，在没有更改的情况下重试）。
达到迭代限制：max_iterations 已耗尽，剩余失败。

停止时，提供最短路径选项：

运行不同的测试模式（fast -> ci -> full）
允许安装/网络/Docker
范围狭窄（仅修复第一个失败的测试）
增加迭代限制

报告持久性

默认情况下不要编写独立的报告文件。如果用户明确要求保留，请写入从项目规范解析的路径，或默认为“docs/calibration/repair-loop.md”并覆盖规范文件，除非明确请求快照。

输入与输出 (Input & Output)

输入（输入）

目标路径（默认.）
范围：“diff”（默认）或“codebase”（+ 路径）
测试模式：fast（默认）、ci、full
约束：允许安装/网络/Docker/服务（是/否）
max_iterations（默认为5）
可选：时间预算

输出（输出）

修复循环报告：
- 完成使用的定义
- 证据来源（哪些文件/CI 配置告知测试计划）
- 对于每次迭代：
  - 测试命令运行和结果
  - 第一次失败摘录（如果有）
  - 所做的更改（触及的文件+意图）
  - 剩余的失败/发现
- 最终状态：
  - 测试通过（哪个命令）
  - 剩余的审查项目（如果有）以及它们是否被阻止

限制（限制）

硬边界（Hard Boundaries）

未经明确确认，请勿安装依赖项、使用网络、启动 Docker/服务或运行破坏性命令。
不要要求用户将秘密粘贴到聊天中。更喜欢本地环境文件或文档化的开发流程。
不要通过禁用测试、削弱断言或删除覆盖范围来“修复”，除非用户明确批准并且权衡已记录在案。
避免默认进行大型重构；优先考虑能够解锁正确性的最小补丁。
将更改范围保持在目标存储库范围内；不要修改不相关的同级存储库。

技能边界 (Skill Boundaries)（避免重叠）

不要做这些（其他技能可以处理它们）：

仅测试执行（无审查或修复循环）：使用“run-automated-tests”
测试质量评估（覆盖范围、结构、边缘情况充分性）：使用“审查测试”
全面的代码审查（无测试修复迭代）：使用“review-code”
仅差异审查（没有测试执行或修复迭代）：使用 review-diff
从头开始编写新测试（不修复现有故障）：使用开发技能

何时停止并交接：

环路收敛（测试通过，没有阻塞发现）→ 当前修复环路报告并停止
遇到停止条件（无进展、环境阻碍、片状测试、迭代限制）→ 显示选项并等待用户指示
用户请求一次性代码审查而不修复 → 移交给“review-code”或“review-diff”
用户要求仅运行测试而不修复 → 移交给“run-automated-tests”

自检（Self-Check）

核心成功标准

完成解析的定义：在循环开始之前确认飞行前选择（范围、测试模式、最大迭代次数、允许的操作）
每次迭代证据优先：每次迭代至少产生以下之一：新的测试结果、新的审查信号或具体的代码更改
修复后重新运行测试：在同一迭代中应用修复后，失败的测试命令（或目标子集）始终重新运行
有界循环：循环由于收敛或显式停止条件而终止 - 没有无限重试
结构化最终报告：输出包括修复循环报告（附录：输出合约），其中包含命令运行、故障、补丁和剩余风险

流程质量检查

最小补丁表面：每个修复仅涉及解决已识别问题所需的文件 - 没有不相关的格式或改动。
不稳定的测试意识：检测到非确定性故障（例如，在不更改代码的情况下传递重试）并进行标记，而不是盲目地“修复”。
应用了风险更改暂停：架构迁移、身份验证更改或广泛的重构在继续之前触发了明确的用户确认。
每次迭代跟踪的进度：每个迭代日志都显示一个清晰的增量（新信号或新修复） - 没有空洞的迭代。

验收测试

最终报告是否显示（a）测试通过且没有阻止审查结果，或（b）明确的停止条件，并为用户提供明确的剩余问题和选项？

示例（示例）

示例 1：修复 Node 存储库中失败的单元测试

用户：“让测试通过。继续修复直到绿色。”

代理：

飞行前：scope=diff，测试模式=fast，max_iterations=5；确认允许安装（npm ci）并且允许网络。
迭代 1：运行 npm test，修复第一个失败的测试，重新运行 npm test。
迭代 2：运行 review-diff 以捕获修复引入的边缘情况；重新运行npm test。
当“npm test”通过并且没有重大审查结果时停止。

示例 2（边缘情况）：集成测试需要 Docker 和密钥

用户：“镜像 CI 并修复故障。”

代理：

预检：建议测试模式=ci，但检测 CI 使用 docker compose 和 env 密钥。
触发停止条件：环境拦截器（Docker + 机密未批准/不可用）。
要求用户选择：
- 仅在本地运行“快速”单元测试，或者
- 允许 Docker 并提供非聊天秘密工作流，或者
- 仅运行不需要机密的失败 CI 作业步骤。

附录：输出合约

每次技能执行必须以下列 Markdown 格式输出修复循环报告。

修复循环报告

完成标准：测试通过 · 无关键/主要审查结果范围：diff · 测试模式：fast · 最大迭代：5

第 N 轮

审查（<使用的审查技能>）：关键 0 / 主要 1 / 次要 2 阻塞项：<问题描述，无则省略本行>

测试：<command> → ✅ 通过 / ❌ 失败首次失败：<摘录，通过时省略本行>

修复：<file1>, <file2> — <意图一句话>

重新验证：<command> → ✅ 通过 / ❌ 失败

最终结果

测试：✅ 通过（<command>）/ ❌ 仍有失败
剩余阻塞项：<列表或"无">
次要建议：<列表或"无">
结束原因：已收敛 / 达到迭代上限 / 环境阻碍 / 无进展

automate-repair