greploop

Greploop

根据 Greptile 的反馈改进所请求的更改。成功意味着当前修订版获得全新的 5/5 评审，且没有尚未解决的可执行 Greptile 发现。机器人的评分是对项目检查和你自身判断的补充。

输入

• PR、MR 或变更列表编号。若省略，则从当前任务推断。
• --max-iterations N：正整数，默认为 10 个评审周期。
• --trigger @greptile 为默认值，或使用 @greptile-apps 作为备用路径。 如果常规触发器报告更改文件过多，则使用备用路径。
• --vcs github|gitlab|perforce：当仓库上下文不明确时使用。

遵循用户现有的授权和任务范围。只读评审请求不授权修改代码或发布评论。保留自己的任务工作树和分支；不要将其他任务的检出切换到该 PR 分支。

选择平台

依据仓库和会话上下文，而不是仅凭已安装的可执行文件。只阅读相关参考资料：

• GitHub：随附的辅助工具会跟踪每次触发，并等待与当前提交关联的评分评审。
• GitLab：使用备注和可解决的讨论；仅凭 CI 流水线活动无法确认 Greptile 评审。
• Perforce：使用已配置的 Swarm 或站点适配器。

评审周期

1. 确认目标修订版、任务工作区归属清晰，以及实际生效的迭代上限。发布更改前运行相关检查，并推送或搁置更改。
2. 使用平台参考资料启动一次评审尝试。记录触发信息和修订版。最多等待 10 分钟以获取新结果；不要仅因旧评分属于同一提交就重复使用。
3. 阅读完整的新评审摘要，包括一般评论中的发现。获取所有页面中尚未解决的 Greptile 讨论。行内评论列表为空，并不能证明摘要中没有遗留工作。较早的未解决讨论仍然相关，直到得到处理，即使其行号已过时也一样。
4. 如果当前评审为 5/5、没有遗留的可执行 Greptile 发现，且相关检查通过，则结束。否则，结合上下文评估每条发现。修复任务范围内的有效问题。对于误报，在解决前记录原因和支持证据。不要仅为追求评分而更改正确代码，也不要解决其他评审者的讨论。
5. 对修复运行检查。仅提交任务文件，推送或重新搁置，然后解决修复已发布的具体讨论。暂存时使用明确的文件路径。如果没有代码更改，则跳过提交和推送。
6. 如果迭代上限允许，则针对最终修订版启动新一轮尝试。HEAD 一旦更改，旧尝试即失效。不要重复使用尝试文件，也不要仅因轮询尚无返回结果就再次触发。

达到迭代上限、评审超时、集成不可用，或剩余发现需要范围决策时，停止。报告实际结果和遗留工作。不要自动提高上限，也不要将部分结果称为已完成。迭代上限包含没有产生任何更改的评审。

报告

提供 PR/MR URL 或变更列表、已评审的修订版、周期数、当前评分、运行的检查、已解决的发现以及遗留的发现。区分评审成功、超时和达到上限的情况。除非用户要求，否则不要合并。