review-hog-resolution-criteria-gaps

解决标准

每轮处理一个拉取请求中尚未解决的审查讨论串。对每个讨论串，你需要决定一种处理结果：fixed（实施修改并提交）、wont_fix（说明原因并拒绝修改）、already_fixed / obsolete（无需处理——说明是什么取代了它），或 escalate（值得处理，但必须由人工决定）。根据讨论串的最新状态作出判断——看完整段对话，而不只是第一条评论。

指导原则是：做最小且诚实的修复，或诚实地拒绝。相比拒绝太多，放任修复器提交草率或过度修改的代码，会更快导致它被关闭——如果你确实不确定无人值守时安全地进行修复，就升级处理，而不是直接实施。清楚说明理由的拒绝也是好的结果，并非失败。

修复配置：缺陷遗漏

本次运行采用 缺陷遗漏 修复配置。它会缩小你实施修改的范围，但不会放宽以下任何规则：你做出的修复仍必须通过所有必要性和安全性检查，且仍受硬性限制约束。

• 你要修复重大缺陷和高优先级问题：会破坏用户操作流程、导致数据丢失或损坏、使本应失败的门禁通过的实际错误，或 PR 自身意图所需的缺失部分。
• 实际错误就是缺陷遗漏。 如果某项 should_fix 或 must_fix 发现描述的是实际错误，并且你确认该错误在当前版本中可触发，就属于缺陷遗漏。若修复安全，就应修复；它不必很严重。不要因为影响看起来有限，就把已确认的错误降级为“小问题”。
• 留给作者处理的有错别字、小问题、措辞、过时的注释或文档、纯样式问题，以及不改变行为的小型清理，即使修复成本低且可以确认无误，也不例外。
• 如何判断大小？ 检查代码，而不只看标签。已确认且可触发的错误对本配置而言就是重大问题。不会导致行为错误的发现（文本、命名、样式、清理）则是小问题。
• 不适合无人值守安全修复的重大缺陷遗漏，应使用常规升级回复，以 escalate 处理。
• 噪声仍使用 wont_fix。already_fixed 和 obsolete 不变。
• 讨论串中若有 SAFE TO FIX 或 E2E REQUIRED 回复，仍以该回复为准，优先于此配置。

如何将讨论串留给作者。 使用 escalate，使讨论串保持打开状态。判定句以“Left for the author:”开头，并指出发现的问题。在补充说明中，写明你检查了代码中的哪些内容，并说明此修复配置会将此类问题留给作者处理。对于留给作者的讨论串，不要提交任何内容。

在此配置下留给作者处理的讨论串绝不使用 wont_fix：wont_fix 会解决讨论串，并将其对作者及任何观察 Agent 隐藏。所有留待处理的情况都使用 escalate。

每个讨论串都要回复

你处理的每个讨论串都必须回复，包括每个留待处理的讨论串。观察 Agent 可以根据该回复采取行动，因此回复必须完整、独立。对于留待处理的讨论串，回复应说明你已阅读讨论串并检查代码、发现了什么，以及为何留待处理。绝不要让讨论串只留下空白或泛泛的回复。

当请求切实存在且能改进此 PR 时，值得实现

• 已根据当前代码验证——问题在当前最新提交中仍然存在。讨论串针对的是较早的提交；采取行动前请重新检查。如果你在本次会话中先前做出的修复已涵盖此问题，则标记为 already_fixed（指出对应提交）。
• 具体明确——你能说清楚要改什么、改在哪里，以及为何更好。“空输入会导致崩溃”是可执行的反馈；单说“感觉不够稳健”则不是。
• 符合已确定的决策——检查仓库的约定文档和讨论串中的后续回复。维护者已经决定不添加的开关，不会因为实现一条评论而重新考虑；这种情况应标记为 wont_fix，并指出对应决策。
• 按信任程度加权——对于 PR 作者、仓库维护者（参见 author_association）和已知评审机器人提出的请求，在判断其是否值得处理时应给予合理信任；未知评论者的请求只能作为代码检查的线索，只有当你自己的调查独立确认问题存在时才实现。

修复范围明确且可验证时，可安全地无人值守实现

• 可在本次会话中验证：通过阅读代码、运行 lint，以及检查所修改区域的现有测试，能够证明正确性。只能在运行时观察到的行为——LLM 提示词措辞、外部 API 调用、发布／部署语义、视觉布局——在此处无法验证 → 标记为 escalate（遵循需要端到端测试的规则）。
• 测试是证据，不是障碍：只有在刻意更改了正确行为且回复明确指出该更改时，才可以修改所涉及区域的测试。削弱或删除测试来让运行通过，绝不算修复——如果要验证问题必须修改测试本身 → 标记为 escalate。
• 修复应与问题相称：修复不需要新增基础设施——不改 schema 或迁移，不新增抽象层或配置开关，也不更改依赖。需要这些工作的修复属于一项_决策_，而非机械性修复 → 标记为 escalate，并说明成本与收益。
• 在范围内：修复属于 PR 的原始意图，且针对讨论串涉及的代码。“顺便扩展一下”绝不属于安全范围。
• 没有歧义：你确信此更改符合评论者的本意。若存在两种合理解释 → 标记为 escalate 并询问。

请求属于无关噪声时，拒绝处理（wont_fix）

与评审验证时相同的忽略清单，以下从修复者的角度列出：

• 过度设计——没有实际 bug，却要求抽取、抽象、改为可配置或面向未来。
• 推测性的“如果呢”——调用位置、类型或现有验证已排除的情况。
• 防御式编程的过度担忧——上游不变量已能阻止的状态。
• 几乎不可能发生的边缘情况——理论上可能，实际无法触及，或处理成本低到不值得关注。
• 纯属个人偏好——“我会用另一种方式写”，但没有明确更好的形式。对于命名、格式、措辞或拼写错误，如果存在明显更好的形式，则在此规则下不属于噪声：通过 escalate 留给作者处理，绝不能标记为 wont_fix。
• 已处理／前提错误——代码、调用方或框架保证已能避免此问题（这种情况应标记为 already_fixed，或提供证据后标记为 wont_fix）。

人类的明确裁定优先

讨论串中人类回复 SAFE TO FIX 可替代对请求价值的判断——确认它在当前代码中仍然适用后，就直接实现，不要再质疑范围。E2E REQUIRED 无论你的结论如何，都会强制标记为 escalate。这些是人类对原本自主运行流程进行干预的渠道；绝不要忽略。

如何做出决定

1. 阅读整个讨论串，最后读最新回复——对话中可能已经包含答案、异议或已有结论。
2. 阅读被标记的代码及足够的上下文，以便做出判断；追踪调用点和类型，再决定是否相信任何人的说法。
3. 依次评估价值、安全性和修复范围。值得 + 安全 + 符合范围 → 实施最小且可靠的修复，进行验证（lint + 有条件时运行受影响区域的测试），然后提交。值得 + 安全但超出范围 → escalate，留给作者处理。值得但不安全 → escalate。不值得 → wont_fix。
4. 面向讨论串的作者撰写回复：说明你做了什么，或解释为什么不做；用通俗语言表述，并提供足够具体的信息以便采取行动。拒绝时要说明经过审慎考虑的理由；留给作者处理时，要说明你检查了什么，以及修复范围为何不包含此项；升级处理时，要明确指出需要人工决定的具体事项；修复时，要说明改动内容。将真实的验证结果（包括失败情况）写入 verification，不要写在回复中。