resolve-review

解决代码审查意见

为每条审查意见给出有证据支持的处理结论并确认回复；如果无法做到，则说明原因。结合代码和预期变更评估问题。审查者可能发现了有效问题，却提出了错误的修复方案。选择适合这项工作的调查、实现和验证方法；以下要求规定了发布前必须确认的事项。

调用即授权在拉取请求现有的源分支上提交和推送、回复、操作讨论串、必要时编辑标题和描述、发布一份处理情况摘要，以及请求重新审查。遵循仓库惯例，并以问题处理者的已认证身份操作。始终在现有拉取请求中完成这项工作。合并、驳回审查，以及以审查应用的身份操作，都需要单独授权。

如果存在 docs/agents/issue-tracker.md，请阅读。使用处理协议，了解反馈身份、回复格式、处理结论和判定用语、讨论串状态、检查证据、摘要以及代码托管平台操作。阅读当前操作所需的章节，包括其输入和失败约定。使用目标检出版本中为各操作记录的调用方式。收集、读取检查运行结果和写入讨论串的启动命令使用绝对安装路径；无需将其可执行内容加载到模型上下文。新近条目检查命令有单独的调用方式。非零结果必须按文档规定处理失败，绝不可假定操作成功。

1. 清点

编辑前先确定目标拉取请求；如果目标不明确，请先询问。使用协议中的收集部分，收集其元数据以及所有分页的审查、行内评论、一般评论和讨论串状态。记录初始源分支提交、分支、收集目录，以及每条反馈的稳定 ID 或评论 ID。包含人工反馈，以及提出了讨论串之外新内容的审查正文反馈。跳过仅包含状态信息的自动化消息。

在每条反馈的稳定身份下，记录其问题、先前讨论、处理结论和回复，避免遗漏或重复回答。应用协议中的阻塞和可选分类。报告未完成的收集范围，并且只处理已获取的反馈。未获取的反馈既不能获得处理结论，也不能计为已处理。

2. 处理

根据证据进行必要变更，并按协议规定的格式为每条反馈准备一条回复。遵循用户指定的实现技能；否则自行选择实现方法。依据协议“问题”部分中的可选发现默认规则权衡可选建议。回答问题、解释不同意见；如果工作无法解决问题，则使用 needs-info 或 blocked。现有证据无法解答问题时，在调用方允许的渠道中提出有针对性的问题，可以通过会话或拉取请求提出。

如果先前拒绝的一项建议被原审查者判定为 not-fixed，则该意见存在争议。回应审查者的反驳；如果双方都不改变立场，应按照协议规定的两轮上限说明需要人工裁决。

提交修复，并依据协议的“检查证据”部分进行验证。为已变更的行为及其依赖项选择检查。复用有效证据，避免重复检查；记录其命令或 CI 标识、源分支提交、输入状态、结果和覆盖范围。后续变更后应用协议中的失效规则。较早源分支提交上的证据仍归属于该提交，不能满足针对不同提交明确规定的检查要求。

在下述独立审查完成之前，不要推送、回复处理结论或解决讨论串。为解除工作阻塞而提出的问题可以提前提出。

3. 发布前审查

使用隔离的只读审查者。向其提供原始意见、初始和最终提交的提交头、相关规范和仓库说明，以及检查证据，但不提供实现对话。遵守调用方指定的审查者级别和仓库的模型选择规则。

审查者应先记录有证据支持的独立评估，再查看拟定的回复和处理意见，然后核查其中的说法。即使没有代码变更，也须遵循这一顺序。保留评估和任何覆盖缺口。批准仅适用于实际检查过的提交头和草稿。

使用受支持的宿主操作等待审查完成。如果不存在此类操作，则在派发前停止，并报告 review-wait-unavailable，指出缺少的操作和任何待处理工作。待处理中的审查者或不完整的评估都不满足此门槛。只有已完成的阶段才能由新的审查者替代；待处理工作不得由其他审查者并行替代，阶段失败或不完整都必须停止发布。如果无法隔离审查者、存在重大覆盖缺失，或修复后仍有阻塞性缺陷，则在推送或发布处理意见之前停止并说明原因。

评估首轮评估中的发现，并提交必要的修复。更正缺乏依据的说法，并确保最终提交头和草稿都经过审查。根据变更情况和可用的宿主操作，选择继续、重新评估、增量评估或全面评估；保留先评估后看草稿的顺序，并保留先前的覆盖范围。从首次重新验证开始，本轮后续提交仅用于修复由修复引入的阻塞性缺陷，或纠正缺乏依据的回复说法。报告已接受的可选后续事项，不要因此延长本轮。

此审查不会代替原审查者解决分歧，也不会取代重新审查请求。

4. 发布回复

将任何提交推送到现有的头部分支。发布处理意见前，确认当前头部与已审查的提交头一致。如果头部已变动，先协调变更并确保最终头部经过审查。

通过协议的 writes.jsonl 写入循环发布已审查的讨论串回复和操作。严格保留回复正文、已确认写入的协调方式和重试限制。只有在所需回复和工作均已确认后才解决问题；将 declined、needs-info 和 blocked 项目保持为未解决状态。若某个讨论串被过早标记为已解决，则重新打开并说明原因。遵循协议中针对没有讨论串的反馈以及整个变更相关问题的处理路径。报告每项未解决的写入，以及任何阻止讨论串操作的权限问题。

5. 收尾

根据最终变更协调标题和说明，同时保留问题链接和有效上下文。按照协议规定的格式发布或更新一条处理情况摘要，其中须包含已推送提交头上的 `` trailer，且该提交头与本地头部一致。重跑时，更新现有的同一头部摘要。列出各项内容，并为每项检查注明其所依据的提交头和输入状态；还要说明仍需他人处理的事项。对于指定的文件位置，使用不可变链接。

向提供了相关反馈的身份请求重新审查。针对用户、拉取请求作者或应用审查者，遵循协议的路由规则。不得向应用审查者发送请求或提及其身份。

6. 对账并汇报

再次收集审查活动，并使用协议中的“自清单以来的新内容”命令与清单进行比较，排除本轮已确认的写入 ID 及其生成的空审查。将新的反馈报告为未处理，并更新摘要。读取不完整时，不得声称已完成完整对账。对于在线程循环之外的写入，如果结果不明确，应先与目标核对，再至多重试一次。

最后汇报已处理的提交头、摘要链接、处置数量、变更和检查、独立审查结果、线程操作、重新审查路径，以及剩余工作或失败项的链接。说明用于等待审查的受支持主机操作。等待信息或受阻工作的轮次属于等待状态，而非已完成。应要求且有可用数据时，报告成本指标，并区分实测运行、复用的证据和不可用的指标。