qodo-review-resolver

读取并处理审查发现

描述

使用 Qodo 托管工具读取拉取请求的审查会话，包括其状态、接受审查的提交，以及每条发现及其处理状态；适用于任何 PR（无论是你自己的还是他人的）。在审核引用或调查发现的佐证、位置、驳回情况或审查运行历史时，请请求扩展结果。仅执行读取也是有效用法：读取后即可停止，报告审查进展或指出其中标记的问题（例如，以此判断 PR 在最新提交上是否干净，从而决定是否允许合并）。如需进一步处理，请在代码中解决未处理的发现，并运用自己的判断（审查是有力的第二意见，不是绝对准则）。用户已授权时，应用有依据的修复；否则，提供评估供用户选择。可以运行一次（报告 + 已授权的修复），也可以持续监视（解决问题 → 让 Qodo 重新审查新提交 → 重复，直到审查通过）。获得单独授权后，记录已处理发现的结果——对已修复的发现使用 mark-implemented，对用户同意不改代码直接关闭的发现使用 dismiss。这会清除这些发现造成的合并策略阻止；如果跳过此步骤，审查状态会一直显示为未通过，直到有人在 PR 上手动处理。你仍然绝不会自行向代码托管平台发帖：状态工具会写入 Qodo 的审查数据库，由 Qodo 协调同步 PR 评论。（读取普通的 git／代码托管平台元数据是允许的——git rev-parse HEAD、gh pr view --json headRefOid——而且也是下文新鲜度检查的必要步骤；“不要抓取”规则针对的是 qodo，而不是你的 shell。）

前提条件

• 已连接的 QAR 托管工具 MCP 服务或经过身份验证的 Qodo CLI 提供审查会话工具。
• 无需抓取审查评论，即可确定准确的 PR URL 及其当前 head SHA。
• 对发现状态的任何写入都必须得到用户明确授权；仅有代码修复权限或 autofix 并不包含此项授权。

说明

选择执行路径

所需的审查会话功能可用时，使用已连接的 QAR 托管工具 MCP 工具；否则使用下方的 CLI 路径。在 MCP 上，阅读宿主提供的说明、inputSchema 以及只读／修改类注解。线上的工具为 get-pr-review-findings（pr_url、可选的 extended）、pr-review-dismiss 和 pr-review-mark-implemented；调用前请核实其实时架构。检查 isError 后再检查 structuredContent，即使传输响应成功也一样。被截断的发现结果并不完整，绝不能视为审查通过。

MCP 写入需要为逻辑上的发现处理结果提供稳定的键，该键位于实时架构的 idempotency_key 参数中。支持请求元数据的宿主也可以发送 _meta["io.qodo/idempotency-key"]；如果两者都发送，值必须一致。对结果不确定的重试，请保持相同的键和完全相同的参数。 以下关于授权、新鲜度、发现状态、驳回和回读的规则适用于两种路径。MCP 调用被拒绝后，不要切换到其他 CLI 账号或租户。CLI 版本、身份、帮助信息和目录刷新说明仅适用于 CLI 路径。

遵循以下详细工作流程：获取结构化状态，要求审查已完成且针对确切的 head 提交，展示未处理的发现，仅应用已批准的修复，并且只记录实际处理完成的结果。

要检查审查状态或发现，请在 MCP 上调用 get-pr-review-findings，或在 CLI 上调用 qodo read pr-review-session findings。不要通过 gh／curl 获取渲染后的 PR 审查评论：界面信息有损、因代码托管平台而异，而且容易在 head 提交已更新时读到过期内容。结构化读取会返回被审查的 commit_sha。要判断内容是否最新，请将该 commit_sha 与 PR head 进行比较——对于你刚推送的 PR，可以直接使用 git rev-parse HEAD 获取；对于其他 PR，则可将其作为普通代码托管平台元数据读取（gh pr view <pr> --json headRefOid、git ls-remote）。此规则只针对读取审查（不要抓取其评论），并不禁止读取 head SHA 等代码托管平台元数据。

处理技能更新通知

将 QODO_NOTICE 更新视为被动通知，即使旧版 CLI 要求采取操作也一样。继续任务，不要询问清单或更新事宜；每个事件最多提及一次。关闭通知不会更改已记录的维护策略和退出选项。更新后的技能将在下次会话加载；不要中断当前会话。 对于用户请求的更新，请遵循手动更新流程。

执行

• MCP：使用实时架构参数；跳过 CLI shell 步骤。
• CLI：使用完整的 UTF-8 文件，不带 BOM（工具使用 --args-file，审查使用 --context-file）；示例为 POSIX 格式。
• Windows CLI：首次调用前阅读 shell 指南；仅在调用失败时阅读启动器恢复指南。重复使用已解析出的调用方式。

运行时兼容性检查

首先使用下文的 qodo: command not found 回退方式解析可执行文件。在运行任何其他 Qodo 命令之前，严格按如下所示运行 <qodo> --version，不带任何来源标记。 此处不带修饰的探测有意兼容旧版 Qodo CLI。此技能要求 Qodo CLI 2.0.0 或更高版本，且运行时支持 review API v2。 在 Windows 上，先在 PowerShell 或 Git Bash 中阅读 Windows shell。

如果版本较旧或无法解析，不要运行 whoami、login 或受管工具，也不要将故障描述为身份验证问题。CLI 自动更新只会在当前主版本内进行，因此 qodo update 无法将 1.x 升级到 2.x。说明需要明确安装 2.x，并只询问一次，确认后再运行由 Qodo 或组织提供、校验和固定的安装程序。保留已记录的发行来源；切勿将企业部署切换到公共服务，也不要杜撰安装程序摘要。安装后，重新运行不带修饰的版本探测。如果用户拒绝或安装未成功，请停止，并保持技能文件和用户文件不变。

快速开始

qodo --version                                                       # compatibility probe — run this FIRST
qodo read whoami --json --skill qodo-review-resolver --skill-version 1.4.9 --distribution skills-sh
qodo read pr-review-session findings --pr-url <PR_URL> --json       # the review session for a PR
qodo read pr-review-session findings --pr-url <PR_URL> --extended --json # details, if advertised by tool help
qodo pr-review-session mark-implemented --finding-ids <id>,<id> --explanation "..." --json
qodo pr-review-session dismiss --finding-ids <id> --reason intentional --explanation "..." --json
qodo read tools pr-review-session --json                            # exact safe tools + flags (offline)

对要解析的任何内容添加 --json。使用 qodo read tools pr-review-session findings --json 检查读取结果；使用 qodo tools help pr-review-session <tool> --json 检查写入操作的输入架构。两者都是离线发现操作，不会产生更改。 只读目录有意排除了写入操作；目录中不存在，并不能证明这些操作不可用。

通过身份验证后，如果 dismiss/mark-implemented 提示 unknown command，可能是本地工具目录已过时——按下文所述刷新一次。如果这些命令仍然缺失，说明当前工作区未开放 PR 审查写入操作；应报告此功能限制，而不是反复尝试。

qodo: command not found？ 在 POSIX 上重试 "${QODO_HOME:-$HOME/.qodo}/bin/qodo"； 在 Windows 上遵循链接的指南。保留已解析出的调用方式；报告无法使用的启动器。 如果未安装，请获取 Qodo 或管理员提供、校验和固定的安装程序；切勿杜撰摘要或将脚本通过管道传给 shell。

沙盒身份验证诊断。 凭据缺失可能意味着无法访问密钥链。如果这种情况有可能发生，请先通过宿主的审批流程，请求进行一次精确的只读 qodo read whoami 重试，再建议登录。若被拒绝，则停止；该审批不适用于任何其他命令。在相同的可执行文件／工作区／部署和执行上下文中复用成功的检查；每次所需的宿主审批都应单独请求。网络、TLS、服务和明确的授权失败应分别诊断，不要建议登录，也不要自动绕过沙盒。

预检

1. 身份验证与目录。 除非已有成功检查仍适用于当前执行上下文，否则运行 qodo read whoami。在适用时完成沙箱诊断后，只有明确缺少凭据才需要登录：保留组织的确切登录命令/端点，绝不猜测或将客户部署切换到 Cloud。No tool catalog cached 并不能证明缺少凭据；使用 qodo tools --refresh 刷新一次，然后重试检查。其他失败情况保留其错误并停止此工作流。身份验证成功后，若某个托管命令未知，可以刷新一次目录并重新检查架构。若仍不存在或为 tool_unavailable，报告缺少的能力；不要重复登录或刷新。
2. 确定 PR。 使用用户提供的 PR URL。如果用户没有指定，且你位于 git 仓库中，则推断当前分支的未合并 PR，并在采取操作前向用户确认。绝不猜测 PR URL。
3. 确保编辑针对正确的检出目录。 只读报告可以针对任何 PR。进行任何本地修复前，先从提供商元数据中解析 PR 仓库，并从当前检出目录的 origin 中解析当前检出仓库；将两者都规范化为完整且不区分大小写的 owner/repo 标识。两者必须完全一致。若 origin 缺失或有歧义，或两者不匹配，则停止并请用户打开正确的检出目录——绝不将一个仓库的审查结果应用到另一个工作树。使用该 PR 的分支或隔离工作树，并确保本地 HEAD 与已审查的提交一致（或是由同一修复工作流产生、经过验证的后续提交）。仅仅在仓库中存在该提交并不足够。检查本地差异并保留无关编辑；绝不为了满足此检查而重置或切换有未提交更改的工作树。如果目标 PR 发生变化，请重复这些检查。

获取审查会话

qodo read pr-review-session findings --pr-url <PR_URL> --json 返回：

• review_session — 最新一次审查运行：status、commit_sha（审查中包含的最后一个提交——这些发现所描述的代码）和 started_at。null = 该 PR 尚未经过审查——告知用户并停止（无需处理任何事项）。
• findings[] — 所有当前发现，每项包含：id、title、description、category、 action_level（action_required > remediation_recommended > informational）、 attribution_status、git_sha、location（file_path、start_line、end_line、side）以及 evidence.citations（每条引用的 source_type 和 source）。这与本地审查使用的默认 Finding 对象相同。无法获取的位置或证据为 null。 使用位置信息检查受影响的代码，并使用稳定 ID 记录经授权的处理结果。在两种模式下，都会排除提供商评论 ID、内部审查者决定和修复说明。

只有当审查完整且已完成，并且针对当前 PR HEAD 时，零条发现才支持给出审查通过的结论。

审计和调查的扩展结果

日常状态轮询时，使用精简读取。用户需要佐证或更多细节时，检查 qodo read tools pr-review-session findings --json。只有当架构声明了 extended 布尔值时，才使用 qodo read pr-review-session findings --pr-url <PR_URL> --extended --json。工具/API 输入为 extended: true；省略该参数或设为 false 时，响应保持精简。 这会读取更多已存储的数据；不会重新运行审查或加深审查。

扩展结果会增加 location.code_snippet、驳回原因/说明、review_runs、 evidence.explanation，以及更完整的引用文本/上下文。在审计输出中保留每条 引用的来源类型、来源引用、文本及特定于来源的元数据。将证据与该条发现的 id 和 git_sha 关联起来；当前发现可能来自早于 review_session 的运行。

证据为 null 表示不可用；空的 citations 列表表示没有记录的引用。缺少 evidence 字段 可能表示后端版本较旧：应说明这一限制，不要声称该发现没有佐证。如果目录中没有 extended，请遵循现有的单次刷新恢复流程并再次检查；如果仍然没有，则说明扩展读取 不可用，并继续使用精简读取。目录不支持 --extended 时，绝不要向其传递该参数； 不要杜撰替代标志，也不要用抓取的评论替代。

如果结果中 qar_operation_result_truncated: true，应报告读取不完整，而不是报告为空或 审查结果干净。扩展结果描述的是当前发现和已记录的运行，并非每条发现修订的不可变 历史记录。采取行动前，先应用以下新鲜度检查。

首先读取会话状态（再判断任何发现是否可信）

review_session 会告诉你发现是否已经成立，以及它们覆盖哪些代码——采取行动前先 检查它：

• 审查是否仍在运行？ API 将运行中的审查报告为 started；这是轮询状态。对于仅查询状态的 请求，应报告该状态并返回；只有当等待属于请求任务的一部分时，才进行轮询。 failed、aborted、skipped 和 superseded 是非成功的终态：报告状态并停止循环。 未知状态不代表成功，也不意味着可以无限期轮询。
• 发现描述的是哪个提交？ review_session.commit_sha 是审查纳入的最后一个提交。 如果它落后于 PR 头部，这些发现就是过时的——它们未反映你的最新代码。可能是 审查尚未针对新提交运行（请等待），也可能是你查看的是旧的一次运行。只有当会话状态为 completed，且其 commit_sha 与你关心的提交（监视循环中的头部提交）一致时，才可信任这些发现。

只根据对当前提交已完成的审查采取行动。运行中或过时的审查不能作为解决发现的依据。 在监视模式下，遵守重试延迟；声称审查结果干净前，重新检查代码托管平台上的头部提交； 如果审查没有进展，就停止，不要无限期轮询。

呈现审查状态

使用自然语言：结果 → 对变更和处置的背景说明 → 验证 → 剩余工作。对于仅要求报告的请求，先说明当前审查状态以及剩余问题的影响。只针对 Qodo 审查发现的具体问题致谢一次；最终评估和建议措施由你负责。不要使用品牌化标题、表情横幅、口号、页脚或重复的摘要块。适当时使用简短的问题标题或列表。

针对每项发现，说明可能发生什么、在什么条件下发生，以及这为何会影响用户预期的变更。结合代码以及当前编码会话中已作出的决定和约束进行评估；需要时检索 PR 上下文，绝不捏造缺失的会话。引用证据，并将发现的引用信息和报告中的类别／级别与建议分开保留。自行负责修复、驳回或调查的决定，并说明理由。只有当实现能够强制落实相关假设时，深思熟虑的选择才足以支持驳回。保持协作、客观的语气；不要习惯性地质疑 Qodo 的能力。编辑和处置记录必须遵守现有的范围与审批门槛；技术评估不代表获得了操作授权。

从结构化状态中标明 PR、审查状态和已审查的提交；采取行动前先与代码托管平台上的最新提交进行比较。明确指出审查已过期、正在运行、失败或缺失。区分代码已更改、处置已记录和更新后的代码已审查。测试通过或状态写入成功，并不能证明更新后的提交已通过审查。只有针对当前最新提交完成的审查，才能支持“审查通过”的结论；如实报告剩余问题和缺失的验证。例如：“通过[变更]解决了 Qodo 指出的[风险]，同时保留了[用户决定]。[验证结果]。最新审查覆盖的是[旧 SHA]；[最新 SHA]仍有待审查。”只报告实际结果。在监控模式下，只报告有意义的状态变化，不要在每次轮询或状态写入时重复评估结果。

分类处理

• 未解决还是已完成，以 attribution_status 为准。 对返回值进行分类，包括不同部署支持的各种表示形式：
  • 未解决 — 处理这些问题： pending、partial_implementation、not_implemented、focus_areas_edited。
  • 已关闭 — 不要处理这些问题： implemented、full_implementation、dismissed、detected_after_merge、outdated。遇到不熟悉的值时应报告，不要悄悄将其排除在“审查通过”的结论之外。
  • action_level 表示严重程度，而非未解决或已关闭。已关闭的问题仍可能是 action_required。
• 按 action_level 排序： 首先处理 action_required，然后处理 remediation_recommended；informational 为可选项，应予以说明，但不一定需要修复。
• 按文件归组未解决的问题，以便每个文件只编辑一次。

遵从用户指示（可选范围）

如果用户给出了指示，应将其视为对未解决问题的筛选条件，只处理匹配项，不要扩大范围：

• 按处理级别筛选——“解决需要采取行动的问题” → 仅 action_level == action_required；“处理所有可操作的问题” → action_required + remediation_recommended。
• 按类别筛选——“只处理安全问题” → category == Security（正确性、性能等类别同理）。
• 按具体问题筛选——“修复问题 #3”／“修复 SQL 注入问题” → 按 id 或 title 匹配。
• 仅报告——“审查发现了什么问题？”／“审查是否通过？” → 总结发现及其状态，不更改代码。

没有修复指示或相应的实施授权时，应将未解决的 action_required 和 remediation_recommended 问题提交用户审批，并指出（不要自动修复）informational 问题。若指示含糊，应在采取行动前用一句话说明所选范围，以便用户提出调整。务必报告跳过了哪些问题及原因（超出范围／已驳回／仅供参考），绝不要悄悄略过。

两种模式

每轮都遵循处理一项发现：评估并仅应用现有用户授权（autofix 或明确的修复请求）涵盖的修复；否则展示并询问。推送授权是独立的。

仅执行一次（默认）。 获取 → 评估每项未关闭的发现（分类——全部四种 OPEN 状态，而不只是 pending）→ 缺少授权时展示并询问 → 在代码中应用已授权的修复 → 仅在用户授权范围内提交／推送 → 总结修复内容和剩余发现。 对于仅在本地完成的修复，报告“等待推送”，并保持发现状态不变。验证推送成功后，优先通过下一次审查自动重新归因；手动写入状态还需要明确授权，并满足记录结果中的检查要求。停止。除非用户要求，否则不要循环。分类涵盖 所有未关闭的发现，但选择器仅提供可操作的类别集合—— action_required，然后是 remediation_recommended——并单独列出 informational，这与上述默认范围一致；只有用户提出要求时，才将 informational 放入选择器中。 （提供选项不等于选中：所有复选框初始均未勾选。）

持续监控直至清理完毕（当用户说“盯着点”／“继续处理，直到干净为止”）。在授权范围内重复使用明确的修复授权；仅监控并不授权修改。解决发现并推送修复提交后，Qodo 会重新审查新提交，因此：

1. 记下 PR 当前的 head SHA——刚刚推送的提交（git rev-parse HEAD）；如果 PR 不是由你推送的，则从 forge 元数据中读取（gh pr view <pr> --json headRefOid）。这是读取元数据，而非抓取审查评论——可以这样做。
2. 每次读取时，先遵循先读取会话状态：仅在有界监控期间轮询 started；报告非成功的终止状态或未知状态，然后停止。较早完成的运行已过时：允许有界等待新 head 的审查出现。只有审查状态为 completed 且其 commit_sha 与该 head SHA 相同时才采取行动。
3. 有新审查时：如果仍有任何未关闭的发现（全部四种状态——partial_implementation 仍视为未关闭），则解决这些发现并重复；如果没有剩余发现，则报告审查已通过并停止。
4. 限定循环范围：连续几轮没有进展后停止，并交还用户处理，不要无限循环。

处理一项发现

根据代码、PR 意图和可用的会话上下文评估 Qodo 的发现。你负责给出最终技术建议及其理由，同时遵循用户指定的范围和授权。

逐项评估发现，结合实际代码和 PR 意图提出建议：

• 合理且在范围内 → 应当修复；说明你会如何修改（阅读 title 和 description，定位代码 — 如果代码不在本地，qodo-codebase-wisdom 技能中的读取工具会有所帮助）。
• 缺乏依据或已处理 → 提供代码证据并建议驳回。只有当实现能够确保其假设成立时，出于有意为之的选择才足以支持驳回。
• 不确定 → 指出作出决定前需要哪些证据或检查。

仅报告。 返回评估结果后停止；如果用户明确要求只审查、不做修改，不要征求编辑许可。

仅在缺少编辑权限时展示选项并询问。 如果 autofix、明确的修复请求或涵盖该实现的授权已经生效，则跳过此选择提示，并遵循下文的已授权修复。否则，对每项待处理且在范围内的发现使用上述评估，同时保留其 action_level/category 并给出你的建议，然后在同一条提示中询问要处理哪些发现。使用宿主提供的方式：如果有多选功能，就使用多选功能（例如 Claude Code 的 AskUserQuestion）；否则使用编号列表，并提示“回复要处理的编号”。无论哪种方式都只提问一次，不要逐项询问。默认不预选任何项。 标明你建议处理哪些项，但用户必须主动选择：这条提示是发现进入编辑前的最后一道关卡，因此只按 Enter 不得触发任何处理。只处理用户选中的项（按常规编辑方式进行，并与周边代码保持一致）；对于其余项，说明跳过及原因。在此缺少授权的流程中，用户选择之前不得编辑。

已授权修复。 autofix 或“修复需要采取行动的发现”等明确请求，即授权在相应范围内修复有依据的问题；无需特殊令牌或再次确认。现有实现权限也可能涵盖此类修改。应用修复前先说明评估结果。仅请求状态更新不授予编辑权限；如果范围不明确，只询问一次。修复权限和监控均不授权写入发现状态（dismiss 或 mark-implemented），也不授权推送。

按用户的工作流程提交/推送 — 除非用户已明确要求，否则推送前先询问。

attribution_status 是预期的信号 — 修复后的发现会在下一次审查时自动重新归因为 implemented 或 full_implementation，因此推送后应重新获取数据，只处理仍未解决的事项。但这是工具链，可能出现异常：如果你确信修复已完成，但发现仍处于未解决状态，或其状态明显与代码相矛盾，不要反复修复 — 向用户指出差异，然后继续。处理过程会逐轮收敛；修复也可能引出真正的新发现，这些会由监控循环捕获。

记录处理结果

对具体的状态写入操作，必须获得明确授权；获准修复代码或推送代码，并不代表有权关闭发现项。修复推送后，优先让系统自动重新归因。

关闭发现项是一项写入操作——它会更新 Qodo 的审查数据库、重新设置发现项 PR 评论的样式、重新生成审查摘要，并解除该发现项施加的合并策略阻止。两个命令，其区别正是关键所在：一个表示代码已更改，另一个表示代码未更改，原因如下。绝不能混淆使用。

qodo pr-review-session mark-implemented --finding-ids <id>,<id> --explanation "what you changed" --json
qodo pr-review-session dismiss --finding-ids <id>,<id> --reason <reason> --explanation "why" --json

• 每个 PR 批量处理，一次调用。 每次调用只会执行一次协调，而非针对每个发现项分别执行——因此，所有已实现的发现项都应放在一次 mark-implemented 调用中，所有具有相同忽略理由的发现项都应放在一次 dismiss 调用中。最多 100 个 ID。
• 仅在获得明确授权，且确实更改并推送了代码时，才使用 mark-implemented。 它会在审查尚未验证修复的情况下解除合并门禁，因此错误声明会导致未修复的发现项被当作已修复项合入。如果无论如何还会进行下一轮审查，优先让审查自动重新归因修复；只有在合并前不会再进行审查，或必须立即解除门禁时，才使用此命令。
• 每次使用 dismiss 都必须针对每个发现项获得用户明确同意——autofix 不包含此授权。 autofix 表示同意编辑代码，之后的审查会重新检查代码；而忽略操作会关闭审查仍认定有效的发现项，团队可以看到此操作，且不会有任何机制重新打开该项。说明你提议忽略哪些发现项以及理由，并且只忽略用户明确指出的项。
• --reason（必填）：false_positive（发现项有误）· intentional（代码是有意编写且正确的）· deferred（问题确实存在，但不在此 PR 的范围内）· rejected（已了解问题但决定不处理）。始终补充 --explanation——审查者之后阅读时不会有你的上下文。
• 逐项读取 results，不要假设整次调用都成功。 即使部分 ID 失败，响应仍为 200：not_found（ID 错误或工作区错误）和 conflict（已关闭或未关联到 PR）都是终态——不要重试。reconciled: false 表示数据库更改已生效，但 PR 侧更新未成功；可以安全且幂等地重新运行相同命令，无论如何，PR 都会在下一次审查时自行修复。already_dismissed / already_implemented 会报告已存储的理由——重放不会覆盖原有记录。

示例

用户：“处理 https://github.com/acme/api/pull/318 上需要采取行动的发现项”

1. qodo read whoami → 已登录。
2. qodo read pr-review-session findings --pr-url https://github.com/acme/api/pull/318 --json → review_session：status: completed，commit_sha: a1b2c3d（即 PR 的头部提交，因此发现项是最新的）； findings：3 个未关闭项（2 个 pending，1 个 partial_implementation）——其中 2 个为 action_required，1 个为 informational。
3. 指令仅针对 action_required → 处理这 2 项；informational 项不在范围内（报告即可，不要修复）。
4. 逐项评估：“通过字符串插值构造 SQL” → 确实存在问题 → 建议在 db/orders.py 中改用参数化查询。“出站调用缺少超时设置” → 客户端已在上游设置默认超时 → 问题已解决 → 建议说明此理由并跳过。
5. 明确请求涵盖受支持的 action_required 修复：将 SQL 查询改为参数化查询并进行验证。报告超时问题已解决，并说明 informational 发现项不在范围内；不得自动忽略这两项。分别报告本地修复情况和 PR 的审查状态。只有在另行获得相应授权后才能推送，然后检查新头部提交对应的审查。

配置

使用 --json，将 review_session.commit_sha 与 forge 头部元数据进行比较，并在未附加参数的版本探测后，首次经过身份验证的 Qodo 调用中标记确切的技能/版本/分发来源。读写能力通过已安装的 CLI 目录发现；渲染后的 forge 评论绝不是数据来源。

错误处理

将空会话、正在运行的审查（started）、过期提交、缺少写入能力、速率限制和工具循环错误视为明确状态。在报告中保留这些状态，绝不要仅仅为了让审查看起来没有问题而关闭某条发现。

护栏

• 新鲜度 = 对受审查提交已完成的审查，而非时间戳。 发现描述的是 review_session.commit_sha，且只有在 status 为 completed 时才算最终结果。任何推送后，都将这些发现视为过期，直到某次 completed 审查的 commit_sha 与 PR 头部提交一致——否则你可能会基于尚在进行中的审查采取行动，或“修复”发现所描述之外的提交。
• 绝不要自行向 forge 发帖。 你唯一可以执行的写入操作是 dismiss / mark-implemented，这些操作通过 Qodo 执行，并由 Qodo 协调 PR。不要调用任何 forge 写入工具（评论、批准、标签、描述）来“解决”某条发现——应在代码中解决，然后记录结果。
• 你可以拒绝自己认为有误的发现（并给出明确理由）。现在可以在系统中将其驳回，但这是用户的决定，不是你的——应提出建议、说明理由，并且只有在用户明确同意后才采取行动。若存在真实分歧，由用户裁定。
• 不要关闭尚未处理妥当的事项。 因范围原因跳过的发现应保持打开状态——将其报告为已跳过，而不是标记为 deferred 来让列表看起来干净。
• 不要猜测 PR URL——应先解析；null 会话表示尚无审查。
• MT-TOOL-LOOP 或 MT-RATE-LIMITED 错误意味着停止/退避并更换方法，而不是重试。

获得授权并完成更改后，报告有哪些改进、每项决策为何作出、验证了哪些内容，以及仍需关注哪些事项。明确区分本地编辑、已记录的处置结果和审查状态。