DistDebug-Bench 附录 A–D：标注、提示与覆盖率敏感性

DistDebug-Bench 附录 A–D

这是《DistDebug-Bench：大语言模型智能体能诊断分布式系统中的缺陷吗？》的附录前半，不是另一篇来源。原文：https://arxiv.org/abs/2611.03523

附录概览

附录提供基准构建、评测协议和轨迹分析的支撑材料。

• 附录 A 描述已发布的基准产物、示例条目、策展流程、分类标签、根因标签格式、标注一致性，以及对效度的威胁。
• 附录 B 总结对照人类标签对自动化收集流水线所做的评测。
• 附录 C 给出用于生成诊断的提示词。
• 附录 D 报告指标敏感性检验、自助法置信区间，以及留一系统结果。
• 附录 E 给出失效模式讨论背后的轨迹级细节。
• 附录 F 报告针对更多模型族的探索性子集实验。
• 附录 G 报告评测器效度审计、诊断辅助修复试点，以及污染分析。

附录 A 基准详情

A.1 产物布局

每个基准实例都以 benchmark/bugs/<system>/<bug-id>/ 下的一个小目录存储。发布版本把问题报告侧证据与黄金标签分开，以便评测者在不查看修复补丁的情况下实例化该任务。

benchmark/bugs/<system>/<bug-id>/ report.json # 标题、描述、元数据、链接、产物指针 blocks.json # 修复前的黄金根因代码块 artifact_dir/ # 可选的日志、截图、复现文件、轨迹

report.json 文件包含原始问题标题和描述、项目元数据，以及该报告是否包含日志、堆栈跟踪、已有分析或所附产物等标志。blocks.json 文件是评分目标。每个代码块使用修复前快照中的仓库本地坐标：

{ "file": "src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java", "function": "ZooKeeperServer.shutdown", "start_line": 555, "end_line": 558 }

这些坐标在修复前的检出中解释。标签有意排除测试、附带重构、防御性加固和清理，除非这些编辑对于解释原始失效机制是必要的。

A.2 ZooKeeper-2845 示例

ZooKeeper-2845 是本文使用的贯穿示例。该报告描述了一种数据不一致场景：在领导者选举期间，一笔事务可以出现在磁盘日志中，却不出现在快照中。报告反复提及法定人数（quorum）行为和领导者选举，而黄金标签位于服务器生命周期路径中：

标题：因在领导者选举中保留数据库而导致的数据不一致问题 关键症状：事务（txn）领先于快照；一台重启后的服务器重放 T1，并与新的法定人数产生分歧。黄金文件：src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java 黄金函数：ZooKeeperServer.shutdown

译注：原文标题为 “Data inconsistency issue due to retain database in leader election”，英文不完整（due to retain），按「因在领导者选举中保留数据库而导致的数据不一致」理解。

这个示例之所以有用，是因为问题报告侧的叙述强烈指向 /server/quorum，但最小因果代码块却在 ZooKeeperServer.shutdown 中。因此，它检验的正是我们所关心的基准行为：智能体必须从一个看似合理的症状级子系统，转移到跨重启仍保留不一致状态的代码。

图 4 把这一距离可视化。观察到的症状是重启后的法定人数分歧：节点 A 和 B 在状态 T0 上一致，而节点 C 随后从其本地日志重放事务 T1。问题报告给出了有用的证据，包括被保留的 ZKDatabase 状态、领导者选举、快照/日志偏移、空的 DIFF 同步，以及事务日志重放。这些线索自然使领导者选举、法定人数对等节点协调、learner 同步、快照处理和事务日志重放成为看似合理的第一批检查目标。黄金根因则不同：ZooKeeperServer.shutdown 跨重启保留了内存数据库，使陈旧状态得以存活到后来的法定人数形成之中。因此，该示例表明 DistDebug-Bench 度量的不只是组件发现。一项诊断必须跟随一次非局部的因果跳转，从现实的症状侧搜索空间走到保留坏状态的生命周期代码。

图 4：ZooKeeper-2845 中的因果距离。问题证据指向领导者选举、learner 同步、快照和事务日志重放，但标注的根因是 ZooKeeperServer.shutdown 中的生命周期代码块，它跨重启保留了陈旧的 ZKDatabase 状态。

（a）问题报告侧证据

（b）黄金标签

A.3 策展流程

DistDebug-Bench 通过分阶段流程策展。目标是保留那些作为现实调试任务、可依据问题报告侧证据进行诊断，并且精确到足以支持源码级标签的缺陷。

#### 候选发现。

对每个项目，我们收集历史上的公开问题，并对具体的已修复缺陷施加自动过滤器。过滤器要求问题状态为已关闭或已解决、存在相关联的修复变更、问题类型或解决结果类似缺陷，以及报告内容足以提供信息。当项目元数据可用时，我们优先选择高影响、面向用户的问题，例如稳定版本上的 Major、Critical 或 Blocker 缺陷。我们排除功能请求、仅涉及文档的问题、仅涉及测试的问题，以及描述过于稀疏、不足以支持诊断的报告。

#### 修复级过滤。

修复变更只用于策展和标注，不作为智能体输入。我们去除大范围重构、仅格式变更、依赖更新，以及由无关清理占主导的补丁。作为一项实用过滤器，我们排除已更改源代码超过 100 行的修复，除非因果跨度可以与辅助性编辑明确分离。

表 2：ZooKeeper 策展切片中的示例流失。

#### 人工审核。

标注者检查某个问题是否仅凭问题报告侧上下文即可诊断。问题报告和所附产物用作诊断上下文，而修复提交只用于人类标注。后来在问题讨论串中揭示根因或补丁策略的评论会被移除或忽略。这使得该任务聚焦于依据事件证据进行诊断，而不是从修复后讨论中检索最终答案。

#### 根因调和。

每个被接受的问题由三名标注者独立检查。标注者根据修复变更及周围代码上下文推导候选的修复前根因代码块，排除测试和附带清理，并把分歧调和为一组最终代码块。经调和的标签是用于基准评分的唯一标签。

基准还为每个被接受的问题记录刻画元数据。这些元数据字段不是评分目标，也不作为提示提供给智能体。它们通过让我们按文本代码锚点、崩溃点到修复点的距离、问题报告侧证据和根因结构来分解结果，从而支持文中的分析。

A.4 分类轴

基准刻画使用两个基于黄金标签的轴。这些分类只用于分析和图的分解；在评测时不提供给智能体。

表 3：评测分解中使用的文本代码引用类别。

表 4：评测分解中使用的崩溃点到修复点类别。

在主类别图中，我们把同处与邻近合并为一行局部/邻近，因为邻近单元格很小。由此得到的 3 乘 3 表包含 42 个无堆栈且不透明的缺陷、16 个无堆栈且点名方法的缺陷、17 个无堆栈且点名文件/类的缺陷、7 个跨组件且不透明的缺陷、13 个跨组件且点名方法的缺陷、7 个跨组件且点名文件/类的缺陷、1 个局部/邻近且不透明的缺陷、8 个局部/邻近且点名方法的缺陷，以及 9 个局部/邻近且点名文件/类的缺陷。

表 5：为基准刻画而抽取的问题报告侧信号字段。

我们还为每个事件指定一种粗粒度根因类型，用于基准刻画。这些类型是描述性的，既不被评测器使用，也不向智能体暴露。它们提供的是高层视图，而不是穷尽的失效分类体系；状态管理、协议交互、恢复、配置和多组件协调等更细的区分需要另行标注。

表 6：全部 120 个事件的基准中的粗粒度根因类别。

A.5 标签结构

DistDebug-Bench 在 120 个事件中包含 218 个黄金缺陷代码块。多代码块标签很常见：54 个事件（45.0%）需要不止一个代码块，28 个事件（23.3%）跨越多个文件。带标签代码块长度的中位数为五行。这就是为什么本文报告文件/函数/行指标，但把代码块覆盖率用作主要诊断指标：有用的诊断必须到达正确区域，又不能对精确的行边界选择过度敏感。

#### 标注一致性。

全部 120 个事件都遵循相同的三标注者标注与调和流程。对于 51 个事件，我们保留了裁定前各自的标注表，从而能够度量独立标签之间的一致性。对于其余 69 个事件，分歧通过讨论解决，但没有保留各自的裁定前标注表。因此，下面的一致性统计描述的是这 51 个被保留的案例。

我们在文件、规范化函数和代码块粒度上评估一致性。表 7 在前两个层级报告 Krippendorff 的 $\alpha$ 和成对 Jaccard 相似度，并在基准的五行容差代码块准则下报告代码块覆盖率与 F1。标注者在因果文件和函数上高度一致。精确行区间边界上的差异，以及标注者如何把一个因果区域拆成代码块的差异，降低了精确区间上的一致性，而在代码块准则下的一致性仍然很高。

表 7：在保留了各人标注表的 51 个事件上、裁定前的标注一致性。

A.6 对效度的威胁

#### 内部效度。

主要的内部风险是：基准标签或评测器可能无法忠实地度量我们打算研究的诊断行为。

标签效度。 分布式系统的修复可能包含上游状态转移、下游防护、不变量检查、测试和辅助清理。我们通过以下方式缓解这一点：根据历史修复变更及周围代码上下文推导标签，让三名标注者独立检查每个问题，把分歧调和为一组最终代码块，并且只标注体现了失效机制的最小修复前代码。测试、辅助重构、防御性加固和附带清理均被排除，除非它们对因果解释是必要的。在保留了独立标注表的 51 个事件上，文件级和函数级的一致性很高（A.5 节）。

评测敏感性。 一次分布式系统失效可能在若干位置得到缓解或修复，但产生它的因果链是特定的。例如在 ZooKeeper-2845 中，人们可以在同步或恢复路径的后续位置增加防御性处理。这样的变更也许能减轻所观察到的不一致，但并不能识别底层缺陷：被保留的数据库以及关闭/重启行为，使同步期间使用的状态与事务日志发生分歧。因此，DistDebug-Bench 标注的是通过问题解决和专家标注所确定的因果代码，而不是症状可被检测、掩盖或修复的每一处位置；它并不声称历史补丁是唯一有效的修复。把责任归于另一个看似合理的干预点的诊断，仍然可能得到很低的代码块覆盖率。因此，本文同时报告文件、函数、行和代码块指标，以及提及覆盖率；后者记录的是：即使所选代码块不同，因果解释是否仍然提到了被标注的函数。G.1 节表明，此类替代解释只能说明少数零覆盖诊断，并且覆盖率更高的诊断能更有效地指导修复。未来的评测器可以把多参考标注与基于语义和程序分析的验证结合起来，以更好地捕捉等价的因果解释。

基准泄漏。 DistDebug-Bench 由用户公开报告的失效构建而成。这使基准现实且可复现，但也意味着无法完全排除模型预训练时的接触。如果智能体检索公开的基准标识符和未来的修复信息，而不是依据允许的证据进行诊断，评测就可能被污染。我们在基准构建期间通过以下方式缓解直接的答案泄漏：移除揭示根因或补丁策略的问题讨论串、匿名化工作区名称，并移除任务快照之后的提交。泄漏防护即图 1，它扫描可见的推理过程以及工具输入/输出，查找未向智能体提供的原始问题标识符。这项检查针对的是对历史答案的直接检索，包括搜索未来的修复提交。被标记的尝试会被丢弃并重新运行，团队会调查预备环境中残留的标识符或可访问的修复信息。因为检测依赖于显式的标识符匹配，隐式回忆需要单独评测。G.2 节报告防护命中次数、闭卷探测，以及与公开暴露代理变量的相关性。

译注：原文 “The leakage guard Figure 1 scans” 缺少连接成分，按同位语理解为「泄漏防护即图 1，它扫描……」。

#### 外部效度。

主要的外部风险是：从 DistDebug-Bench 得出的结论能否推广到这一基准样本之外。

选择偏差。 DistDebug-Bench 有意聚焦于生产分布式系统中已关闭、高影响、且其修复支持精确源码级标注的失效。这一选择使任务现实且可评分，但排除了那些修复由大范围重构、配置变更、仅测试变更或含糊清理占主导的失效。因此，该基准应被解释为覆盖可标注的分布式系统缺陷的代码级诊断，而不是全部事件响应工作。

我们用一套有原则的分阶段选择流程来缓解这一风险。对每个项目，我们首先收集历史上的公开问题，并对具体的已修复缺陷施加自动过滤器：已关闭或已解决的状态、相关联的修复变更、在优先级可用时的高优先级或面向用户的失效、信息量足够的报告，以及非测试、非文档组件。然后我们按修复变更本身过滤，排除大范围重构和由无关清理占主导的补丁，并使用 100 行已更改源代码这一实用截止阈值，除非因果跨度可以与辅助性编辑明确分离。表 2 中的 ZooKeeper 流失示例说明了这一过滤过程的规模。最后，标注者对留存项进行人工审核，以确认：不借助报告之后的讨论，问题报告侧上下文即可诊断；报告没有揭示根因或补丁策略；并且修复变更可以映射到精确的修复前根因代码块。每个被接受的问题随后由三名标注者独立标注，并调和为最终标签集。这一流程并不能消除选择偏差，但它使基准总体成为一致过滤器与显式审核的结果，而不是便利抽样的结果。

附录 B LLM 辅助的收集流水线

基准策展需要人类审核，原因有二：识别真正的缺陷报告并排除功能请求，以及识别编码每个根因的源代码块。我们针对第二个瓶颈开发了一条 LLM 辅助流水线。该流水线从一次缺陷修复提交出发，自动获取差异，并提示 LLM 只输出相关的根因代码块。初步检查表明，LLM 生成的标签与人类标签之间存在不可忽略的差距，但我们仍然看到 LLM 辅助自动化流水线的潜力。下面，我们报告这条 LLM 辅助流水线、一条非 LLM 抽取流水线与最终人类标签之间的一个小子集比较。第一个瓶颈同样重要，但判断一个缺陷是否可根据可用信息来诊断，本质上就是在要求 LLM 智能体自己诊断该缺陷，而这正是我们首先要测试的任务。我们将探索在保持基准质量的同时完全自动化 DistDebug-Bench 的策展流程，并根据信息可用性做更细粒度的缺陷分类。

我们对照 DistDebug-Bench 所使用的人类标签，评测两种基准构建变体。LLM 辅助变体从缺陷修复差异出发，提示 LLM 选出与根因对应的源代码块，并排除测试、辅助重构和其他辅助性编辑。非 LLM 变体是一条确定性抽取流水线，它使用源码级解析与过滤，从修复变更推导候选标签，而不要求 LLM 判断语义相关性。两种变体针对的都是第 3 节中的第二个策展瓶颈：在一次已知的修复变更中，把根因代码块与其他编辑分开。

LLM 辅助变体只在一个小子集上可用，因此下表在 LLM 辅助流水线所完成的同一批 12 个缺陷上报告两种变体。非 LLM 流水线还覆盖了更多缺陷，但为保持子集固定，这些缺陷未纳入本比较。

表 8：在 12 个缺陷的共享子集上，收集流水线的命中率比较。分数比较的是生成标签与人类标签。

表 8 显示出覆盖率与精确率之间的权衡。在共享子集上，非 LLM 流水线找回了更多人类标注的代码块，但它是通过发出多得多的候选标签来做到这一点的。LLM 辅助流水线更为保守：它预测 15 个代码块，而非 LLM 流水线预测 52 个，从而精确率更高、召回率更低。这表明，LLM 辅助的标签抽取是扩展基准构建的一个有前景的方向，但仍然存在的召回率差距说明，它还不能替代人类的标签审核，并促使未来研究更可靠的自动化策展。

附录 C 评测提示词与输出契约

译注：模型实际收到的是英文提示，下文是全文翻译。

所有被评测的评测框架（harness）都接收相同的诊断任务：检查修复前的仓库和问题报告侧证据，找出编码根因的修复前代码块，并发出一份结构化诊断。具体的交互语法因评测框架而异，但任务级约束是共享的：

• 智能体应当诊断该缺陷，而不是为其打补丁；
• 智能体不应当修改仓库源文件；
• 优先使用轻量静态分析，而不是长时间运行的集成测试或联网服务；
• 最终答案必须是所要求模式中的有效 JSON；并且
• 每一对已完成的缺陷/配置贡献三份有效诊断。

C.1 Mini-SWE-Agent 提示词摘录

Mini-SWE-Agent 实验使用一条仅诊断的系统提示，以及一条指示模型写出 diagnosis.json 的实例提示。下面的摘录展示任务级内容，略去了特定于评测框架的 shell 动作格式示例。

你是一个可以通过 bash 工具调用与计算机交互的得力助手。你的工作仅限于诊断。不要修改代码库，也不要试图给出修复。请调试这一分布式系统问题的根因：{{ issue_title_and_description }} 给出该缺陷的代码级诊断。你的最终输出是一个名为 diagnosis.json 的 JSON 文件。不要在该文件中包含 Markdown。要求：- 不要修改仓库源文件。- 使用仓库、问题文本、堆栈跟踪和所附产物来推理根因。- 你可以检查代码并运行轻量的本地命令。- 避免长时间运行的集成测试或联网服务。- 使 diagnosis.json 保持为纯 JSON，且严格符合下面的模式。- 在结束之前，用所提供的校验器验证 diagnosis.json。

C.2 Codex CLI 与 OpenCode 提示词摘录

对于 Codex CLI 和 OpenCode，提示词以该评测框架原生的任务格式表达，但保留相同的仅诊断契约。下面的摘录代表任务消息：

你正在审计一份分布式系统的历史缺陷报告。你的任务是检查仓库、理解失效场景，并找出负有责任的确切代码块。说明：- 只在当前 Git 仓库内工作，该仓库已检出到目标修复前提交。- 使用轻量静态分析，例如搜索、grep 和阅读代码。- 除非必要，避免运行集成测试。- 当你得出结论时，提供一个遵循所给模式的 JSON 对象。不要嵌入 Markdown 或额外评述。- 每个有缺陷的代码块必须具有准确的 file、function、start_line 和 end_line。- 包含一段简明的 bug_cause_description，把各部分联系起来。

C.3 诊断模式

所要求的输出模式有意保持很小。评测器在评分时忽略可选的叙述字段，并在文件、函数、行和代码块粒度上，把预测的代码块坐标与黄金标签进行比较。

{ "buggy_blocks": [ { "file": "relative/path/to/file", "function": "fully.qualified.FunctionName", "start_line": 123, "end_line": 130, "bug_contribution": "本代码块如何促成该缺陷。", "patch": "可选的最小补丁草图或说明。" } ], "bug_cause_description": "总体根因解释。" }

patch 字段的存在是为了与部分评测框架的输出兼容，但本版本不对补丁质量评分。评分流水线只使用预测的源码坐标；对于提及覆盖率，则使用 bug_cause_description 中自然语言的函数引用。

附录 D 覆盖率指标敏感性

正文把代码块覆盖率用作主要的定位指标，因为它询问智能体是否到达了每一个被标注的因果区域，同时又对精确的行边界选择不那么敏感。行覆盖率更严格：一项诊断可以到达正确的代码块，但如果预测区间相对于人类标签发生了偏移、更短或更长，就会得到更低的行覆盖率。因此，我们把行覆盖率当作敏感性检验，而不是主要叙述。

图 6：按事件证据划分的行覆盖率。列按问题文本是否包含精确的黄金方法、仅包含黄金文件/类锚点，或不包含直接文本锚点来划分缺陷。行按第一个崩溃堆栈帧是位于修复的局部或邻近位置、位于另一个组件，还是缺失来划分缺陷。行覆盖率比代码块覆盖率更严格，度量的是与被标注因果行的重叠。面板计数给出每个单元格的缺陷数；须线表示 95% 的缺陷级自助法置信区间（单个缺陷的单元格没有须线）。

图 6 表明，主代码块覆盖率图中的定性模式在这一更严格的指标下仍然可见：不透明缺陷和无堆栈缺陷仍然比点名方法的缺陷难得多。绝对值更低，是因为行重叠会对区间边界不匹配施加惩罚。

图 7：按证据类别划分的、Mini-SWE GPT-5.2-Codex 与 Mini-SWE GPT-5.4 之间的配对行覆盖率差值。每个单元格报告 GPT-5.2$\rightarrow$GPT-5.4 的绝对行覆盖率、以百分点计的配对差值，以及缺陷数量。

图 7 提供了 GPT-5.4 相对 GPT-5.2 的配对敏感性视图。行指标表现出与代码块指标相同的谨慎：更新的模型改善了若干弱证据单元格，但变化在各类别间并不均匀。

D.1 聚合与统计不确定性

对于缺陷 $i$、尝试 $r$ 上的指标分数 $s_{ir}$，我们先计算 $\bar{s}_{i}=R_{i}^{-1}\sum_{r=1}^{R_{i}}s_{ir}$，然后报告 $\hat{\mu}=n^{-1}\sum_{i=1}^{n}\bar{s}_{i}$。每个被纳入的缺陷有 $R_{i}=3$ 次选定尝试，并且各缺陷等权。每一次自助法重复有放回地抽取 $n$ 个缺陷 ID，并对其 $\bar{s}_{i}$ 值取平均。10,000 次重复均值的第 2.5 与第 97.5 百分位数构成所报告的 95% 区间。我们使用排序后的缺陷 ID、种子为 2026 的 NumPy 的 PCG64 生成器，以及分位数的线性插值。类别区间在每个类别内使用同一过程。缺陷数少于两个的单元格没有置信区间。

这些区间把缺陷视为从该基准所代表的事件中独立抽取的样本。它们捕捉的是对抽到哪些缺陷的敏感性，而不是固定缺陷上的重跑变异；后者我们另行报告为缺陷内标准差和不稳定缺陷计数。因为来自同一系统的缺陷可能相关，D.2 节还报告按系统以及留一系统的结果。

#### 配对差分。

对于配置 $A$ 和 $B$，我们为每个缺陷计算一个差值 $d_{i}=\bar{s}_{i,A}-\bar{s}_{i,B}$，并估计 $\hat{\Delta}=n^{-1}\sum_{i}d_{i}$。每一次重复都为两种配置抽取相同的 $n$ 个缺陷 ID，等价于对 $d_{i}$ 值重抽样。我们使用与上文相同的 10,000 次重复百分位过程、种子和分位数约定。配对按缺陷 ID 进行，而不是按尝试序号；三次选定尝试在重抽样之前先在每个缺陷内取平均。

表 10 报告了其余十二种 Mini-SWE 配置相对 GPT-5.2-Codex、GPT-5.5 相对 GPT-5.4，以及四种模型匹配的 Mini-SWE 相对 Codex CLI/OpenCode 比较的代码块覆盖率差值。这些区间未针对多重比较进行校正。配对使模型比较比比较各自的区间更敏感：Mini-SWE GPT-5.5 与 GPT-5.2-Codex 各自的置信区间有重叠，但 GPT-5.5 提高的 8.71 个点具有配对置信区间 $[4.96,12.91]$。 配对是按缺陷标识而不是按尝试序号进行的；表 9 紧接其后，配置名保持英文，分数单位是百分比。

表 9：在 120 个共同缺陷上的平均分数及 95% 缺陷级自助法置信区间，单位为百分比。

表 10：在 120 个共同缺陷上的配对代码块覆盖率差值，单位为百分点（候选减去参照）。区间是未校正的成对 95% 缺陷级自助法置信区间；它们不是同时的排行榜界限。

D.2 系统构成与留一系统敏感性

我们使用带 GPT-5.4 的 Mini-SWE-Agent，检查聚合结果是否由某一个系统主导。表 11 报告全部 11 个系统的代码块覆盖率及 95% 置信区间。每个缺陷贡献其三次选定尝试的均值；特定于系统的区间使用 D.1 节中的过程，在该系统内对缺陷重抽样。

对每一次留一系统比较，我们去掉某一个系统的全部缺陷，并在剩余缺陷上重新计算文件覆盖率与代码块覆盖率的均值。我们保持每个缺陷等权，并对每个区间的剩余缺陷做自助法；我们不对系统级均值再取平均。表 12 给出全部 11 次排除以及全队列参照。去掉一个系统最多使代码块覆盖率变化 2.7 个百分点，全队列均值为 63.1%。在每一次排除下，文件覆盖率到代码块覆盖率的差距都保持在 15.1 到 17.8 个点之间。因此，精确因果代码定位的难度在缺少任意单一系统时仍然存在。

表 11：按系统划分的 MiniSWE GPT-5.4 代码块覆盖率。分数和 95% 缺陷级自助法置信区间均为百分比；每个缺陷有三次选定尝试。

表 12：MiniSWE GPT-5.4 的留一系统结果。覆盖率与置信区间均为百分比。$\Delta$ 是代码块覆盖率减去全队列均值；文件—代码块差距与 $\Delta$ 的单位为百分点。每个剩余缺陷保持等权。

D.3 尝试选择与共同评测队列

对每一对缺陷/配置，我们按数值型运行 ID 对尝试排序，并保留前三个具有符合模式的 diagnosis.json 以及已完成且相互匹配的分数的尝试。缺少这些产物的尝试不占名额；后来完成的尝试可以替换它们。选择不依赖于分数：已完成的不正确诊断，包括符合模式的空预测，仍留在评测中。前三个之后的额外有效尝试不予使用。

主要比较使用全部 120 个基准事件、跨越 17 种配置：13 种 Mini-SWE 模型配置，以及 Codex CLI 和 OpenCode 上各两种模型。三次尝试协议给出 $120\times 17\times 3=6{,}120$ 次选定尝试。同一缺陷队列和尝试选择适用于准确率、成本、变异性、分层结果，以及两类置信区间。

全部主要指标都在聚合之前根据这些选定尝试重新计算。已发布的选择清单记录选定的运行 ID、被跳过的尝试、额外未使用的有效尝试、固定的缺陷队列，以及源哈希。可移植的分数快照保留选定的逐次尝试分数和共同的缺陷 ID，从而无需访问完整轨迹即可重新计算两类置信区间。探索性子集分析和单独的轨迹分析各自声明自己的队列。