需要持续跟进已授权的 PR/MR 并分诊评审反馈、CI…

适用于对已授权的 PR/MR 进行持续监控、分诊评审反馈与 CI 失败并推进合并的场景。

适用场景

解决思路

1. 保持已授权的 PR 或 MR 以证据而非噪音推进：轮询、对新可执行项采取行动、把每个目标的本地修复批量成一次推送，然后解决已处理的线程。
2. 在代码相关 CI 失败后，用完整本地验证作为修复循环，CI 仅作确认。
3. 未经明确授权绝不合并。
4. 用 `git remote get-url origin` 检测平台：GitHub 使用 `gh`，GitLab 使用 `glab`；如果模糊或不可用，停止并询问。
5. 建立目标和已处理 ID 快照；任何不在该快照中的外部评论、审查或线程都是新的，包括会话前反馈。
6. 每次轮询后记录反馈 ID、CI 状态和此控制器的评论。
7. 在重复轮询前，如果有可用，使用一个最低成本的只读证据助手。
8. 给该只读证据助手目标和快照；要求返回新反馈 ID、正文、位置、审查状态、非手动 CI 状态、失败作业和日志引用。
9. 该只读证据助手绝不修改；将分类、修复、回复、推送、解决、重试和合并保留给授权的控制器。
10. 使用平台 CLI 按 `references/provider-commands.md` 轮询，然后将完整的审查、评论和 CI 状态与快照比较。
11. 仅在需要时检查失败日志。
12. 不要重新处理旧反馈或发布仅状态更新。
13. 在远程变更前对新证据进行分类。
14. 修复明确的请求和范围窄的格式化、lint、编译或测试失败；在线程中回答明确的问题。
15. 升级架构或矛盾反馈、不熟悉的失败、不明显的修复和范围外冲突。
16. GitLab 手动作业是非阻塞的，除非另有指示。
17. 在各自的目标 head 检出中处理每个目标，并批量处理每个已知可执行项。
18. 在代码相关 CI 失败前，按比例验证。
19. 在发生一次代码相关 CI 失败后，检查其证据，运行每个本地可用的 CI 等效检查，修复所有失败，并在一次修复推送前重新运行完整本地套件。
20. 报告本地不可用的确切检查，而不是使用 CI 作为迭代测试运行器。
21. 在已处理的更改或回答后回复；仅当回复和所需推送成功后，才解决其线程。
22. 不要合并 heads，不要每条评论后推送，不要解决仅本地修复，不要在没有任何更改时评论。
23. 在验证修复推送后重新检查 CI；如果再次出现代码相关失败，返回步骤 6。
24. 对疑似不稳定的 GitLab 作业重试一次，不更改代码；报告第二次失败。
25. 每 2–5 分钟轮询待处理的检查，活动修复每 30–60 秒，在三个或更多未变化周期后每 10+ 分钟；两个未变化周期保持正常的 2–5 分钟节奏。
26. 仅当需求和 CI 通过、无冲突，且用户授予明确或长期合并权限时，才合并。
27. 不要从批准中推断合并权限。
28. 继续，直到用户停止监控、每个目标已合并或关闭，或需要升级。
29. 报告目标、当前 CI/审查状态、已采取的行动以及下一个需要人工决策的事项。
30. 对于模糊的平台/目标选择、未解决的冲突、实质性人工判断、冲突的审查者指示，或经过三个修复周期后仍存在的失败，立即升级。

适用边界 · 注意事项

• 一次性检查、没有开放目标，或操作需要人工判断时，不要启动持久轮询；报告状态并停止。
• 平台或目标选择模糊、存在未解决冲突、矛盾评审意见、实质性人工判断，或失败在三个修复周期后仍存在时，不适用继续自动推进，应升级。
• 未经用户明确或长期合并授权时，不适用合并。