sol-loop

sol-loop

这是一套工作流，用于在提交拉取请求之前（有时也在之后）让代码修改更加正确。简而言之：循环使用 OpenAI 的 GPT Sol 审查代码。

尽可能少地修改代码，以满足 Sol 审查者的要求。谨防范围蔓延，也不要害怕提出异议。

预算

• 默认：总共 3 轮。第 1 轮进行完整审查。之后的轮次只检查已更改的代码和未解决的问题。
• 仅在安全、权限、身份验证、数据丢失或状态／并发方面存在问题，且有证据表明 blocker 或 should 级别问题仍未解决时，才延长至 5 轮。或者用户提出要求时也可延长。
• 如果某轮只返回细枝末节的问题，则提前停止。对细枝末节问题的异议，以及仅涉及注释、文档或格式的修复，都无需新一轮审查。
• 只使用一位审查者。Sol 不得启动子 Agent 或其他审查者。
• 保留一份记录：id、严重性、处理结果，以及返回的用量数据。切勿猜测。

1. 范围

运行 git status --short。不要暂存、丢弃或包含无关修改。如果修改路径可以明确分开，就仅审查变更路径；否则停止并询问。

运行 git fetch origin 后查找基准：

• PR：运行 gh pr view <n> --json baseRefName,headRefOid。仅在工作区干净时切换分支。确认 HEAD 是 PR 的 head，或仅领先于它且领先的内容就是本次修改。基准：git merge-base HEAD origin/<baseRefName>。
• 本地：git merge-base HEAD origin/<default-branch>。没有远程时，使用用户指定的基准；如果只审查未提交的修改，则使用 HEAD。

在这些路径中，本次变更指从基准到工作树的差异，包括未跟踪文件。所有轮次都使用同一个 diff 命令。用 1-2 句话说明修改意图和范围之外的内容。运行覆盖相关代码的检查。不要提交会导致本次修改失效的代码。在简报中注明缺失的检查或之前就已失败的检查。

2. 启动 Sol

在 T3 中调用 orchestrator_capabilities。除非用户指定版本，否则选择最新的 Sol。不要硬编码 ID。仅在可获取时记录 provider、model 和 effort。每轮都使用 delegate_task（role: "review"、mode: "async"）。保存 taskId。每轮都使用新的 clientRequestId。 childThreadId 是存储位置，不是下一轮的目标。不要使用 t3_thread_send、create_threads 或 t3_thread_launch 进行审查。

如果未列出 T3 工具，尝试直接调用一次 capability。如果不在 T3 中，则使用原生 Sol 子 Agent 并保留其 ID。在 Claude Code 中，只有在自定义子 Agent 已配置为运行 Sol 时才使用它。如果没有可运行 Sol 的途径，则报告阻碍因素。不要替换为其他模型。

审查进行期间，不要编辑范围内的文件。等待通知。不要轮询或启动第二位审查者。超时、错误或没有回复都不代表通过。如果失败，则取消并确认已停止，然后连同记录重新启动。

第 1 轮简报（T3 子线程不会收到历史记录）：

Review only. Do not edit, commit, push, comment on PRs, or start subagents.
Repo: <abs path> Base: <sha> Intent: <intent> Out of scope: <scope> Checks: <results>
See: git diff <base> [-- <paths>]; git status --short (read untracked).
Read surrounding code. Find bugs, broken callers, mismatch with intent.
Skip style unless it hides a bug. Hold to the smallest change. Flag code,
tests, or guards the intent does not need. Other paths, rare cases, small
perf, extra compat: nits.
blocker = intended case wrong. should = real bug callers will hit, in intent. nit = rest.
Reply:
VERDICT: APPROVE or CHANGES
S1 [blocker|should|nit] <file>:<line> <claim>. Fix: <suggestion> (stable ids)

3. 回复问题

自行核实每个问题及其严重性。其他路径、罕见情况或成本较小的问题，无论附带什么标签，都属于细枝末节。

• 同意：进行最小幅度的修复。优先删除或缩小范围，而不是新增锁、缓存、辅助函数或选项。修复实际发生问题的情况。如果需要明确意图，则添加一个没有该修复就会失败的针对性测试。
• 不同意：提供理由和证据（文件:行号、测试、输出）。
• 超出范围或属于细枝末节：用一行说明不予处理。列为后续事项。

更新记录。重新运行检查，并运行 git diff --shortstat <base>。如果审查导致差异扩大，先精简。不要为了结束循环而同意。

4. 下一轮

仅当预算尚有余量，且存在未解决的 blocker 或 should 级别问题、行为代码已更改，或审查通过意见未覆盖当前行为差异时，才启动下一轮。在 T3 中使用新的 delegate_task，或跟进已保存的原生 ID。发送第 1 轮简报、记录（fixed: / disagree: / declined: + 证据）、相同的基准差异，以及自上轮以来的变更。告知 Sol：只检查未解决的 id 和已更改的代码。将每个旧 id 标记为 resolved 或 still open: <reason>。

5. 停止并交付

意见一致：对当前行为差异表示 APPROVE，没有阻塞项或应当提出的问题，也没有你自己的顾虑。若某项在两轮回复后仍有争议，或预算耗尽，则停止。用 2-3 行分别展示双方的意见，由用户决定。预算耗尽不代表批准。

循环期间不要推送。只有用户要求推送、交付或更新 PR 后，意见一致时才推送。如果你推送到 PR，请在模型简介上方添加：

Reviewed with sol-loop: <N> rounds with <model>. Sol verdict: approved

只有在已验证的情况下才添加 on <effort>。

汇报：轮数、模型、Sol 做了哪些更改、前后差异大小、已修复和未采纳的问题及原因、用量（若可见；否则说明不可见），以及是否已推送。