benchmark-fp-fn-audit

React Doctor 基准的 FP/FN 审计

针对基准语料中的 React Doctor 诊断开展有证据支持的审计。阅读完整的规则文档，量化故障分布，检查每个相关试验产物，并独立进行第二轮审查，以发现其他误报和漏报。

语料和必需资源

对于此基准，请使用：

/home/aidenybai/Developer/react-bench-internal/jobs/ReactBench-v1.1-beta-rd-0.9.3-consolidated-final-20260801

从以下位置阅读完整的 React Doctor 规则文档：

https://www.react.doctor/docs/rules

如果存在，请阅读以下仓库审查材料：

/home/aidenybai/Developer/react-bench-internal/docs/aiden-review

不要将先前的审查或报告视为事实依据。可以把它们作为线索，但必须针对当前基准版本重新核验每项主张。

对于每个检查过的试验，请找到并阅读：

• verifier/model.patch
• verifier/rd-before.json
• verifier/rd-after.json
• verifier/rd.log
• result.json
• 使用 rg --files 查找奖励和测试日志
• 任务 README、提示词或审查材料
• 补丁所引用的基础版和补丁版源文件

检查所有试验目录，包括主要变体和已验证变体。计算任务级统计数据之前，先规范化重复的任务名称和重复的补丁哈希。

证据规则

谨慎地对发现进行分类：

• 已确认 FP：诊断由改动后的代码引起，相关行为是有意的或必需的，且规则约定并不适用，或者其建议的修复会导致行为回退。
• 已确认 FN：基础版或最终版代码中存在真实缺陷，没有发出适用的诊断，且现有文档中的规则应当涵盖该缺陷。
• 分类空缺：存在真实缺陷，但没有任何现有规则约定可合理地声称涵盖该问题。
• 测试框架产物：结果由输出格式错误、基线数据过期、验证器行为、生成文件或未改动文件上的诊断导致。
• 候选项：问题看似成立，但缺少足够证据，无法确认。

不要将目标任务未通过称为漏报。不要仅因模型未通过测试，就将某项诊断称为误报。react_doctor=1 是门禁结果，并不能证明代码正确。

每项已确认的发现都必须注明确切的试验、文件、行号或代码片段、规则文档、诊断变化、任务行为和测试结果。严格遵守规则定义的漏报与规则分类之外的问题应分开报告。

工作流程

1. 盘点语料

使用 rg --files 枚举试验产物。记录基准版本、试验数量、缺失的产物、重复变体、格式错误的报告以及可用的任务审查材料。不要悄悄跳过不完整的试验。

2. 构建诊断分布

根据原始 rd.log、rd-before.json 和 rd-after.json 数据重新计算分布。先按试验覆盖率排序，再按原始出现次数排序。报告：

• 试验总数和产物完整度；
• 奖励、测试和 React Doctor 门禁结果的组合计数；
• 直接的 NEW 或引入诊断故障；
• 健康模式下的 NEW 差异；
• 健康模式下的 STILL 目标遗漏；
• 基线版与当前版之间的规则计数差异；
• 规则、类别、严重程度、任务、仓库和文件的集中情况；
• 改动文件与未改动文件上的诊断；
• 格式错误或截断的报告；
• 主要任务与已验证任务之间的重复情况；
• 补丁比较成功与未成功的情况。

在依赖先前摘要之前，务必重新计算。大文件可能会抬高出现次数，因此要同时列出出现次数和受影响的试验数。

3. 检查影响较大的问题集

优先检查覆盖率高的规则和明确引入的诊断故障，尤其是：

exhaustive-deps
no-giant-component
js-set-map-lookups
no-array-index-as-key
js-combine-iterations
effect-needs-cleanup
no-adjust-state-on-prop-change
button-has-type
prefer-module-scope-static-value
no-static-element-interactions
prefer-module-scope-pure-function
no-pass-data-to-parent
no-pass-live-state-to-parent
no-derived-state
no-ref-current-in-render
click-events-have-key-events
rerender-lazy-ref-init
only-export-components
rerender-lazy-state-init

对于每个影响较大的问题集，请检查有代表性的阳性和阴性案例、集中度最高的任务，以及结果不同的同类试验。

4. 执行独立的第二轮检查

搜索每个试验，寻找额外的候选项，而不只是已知的聚类。应用以下启发式规则：

• 将开销较大的延迟初始化与创建空 Map、Set 及同类容器的轻量操作区分开。
• 区分渲染派生状态与异步状态、媒体错误、重试、资源生命周期、订阅和瞬时 UI 状态。
• 对受控组件，区分父级必须进行的同步与 effect 循环或不必要的数据传递。
• 沿着本地别名、useMemo、封装组件和辅助函数追踪危险的 HTML 值；保留对 KaTeX 等可信序列化器的来源信息。
• 区分 React 文档认可的前序 prop 比较与纯派生状态和渲染阶段副作用。
• 检查计时器、Promise、动画、中止信号、订阅和过期闭包是否存在通用依赖项或清理警告无法直接说明的竞态问题。
• 检查焦点抢占、焦点恢复、受控选区、键盘语义和 ARIA 状态转换。
• 检查阈值、别名、解构、嵌套回调、JSX 封装、计算属性和 TypeScript 语法。
• 确认诊断针对的是变更代码，而不是既有问题、生成产物、测试夹具或未改动的相邻代码。
• 对每个拟议的误报，找一个附近的真阳性反例。对每个拟议的漏报，找一个检测器能够捕获的附近案例。

需要独立重新检查以下已知线索，不要预设其分类：

fix-react-rdh-nteract-semiotic-a__5uDDmgx
write-react-glific-glific-fronte__22Gg4p2
fix-react-jumperexchange-jumper__2GBTh7Z
write-react-frankchen021-datasto__2N6xFwQ
fix-react-viclafouch-mui-tel-inp__hQXzJgB
fix-react-floating-ui-floating-u__27iKG4t
fix-react-formidablelabs-victory__2uwi2vz
fix-react-igordanchenko-yet-anot__2GZGZYT
fix-react-rdh-appflowy-io-appflo__vK9uEUy

5. 生成审计产物

在基准目录下写入仅用于审计的输出：

audit/rd-0.9.3-second-pass.md
audit/rd-0.9.3-second-pass.jsonl
audit/rd-0.9.3-rule-distribution.tsv

不要编辑 React Doctor 源码、基准源码、任务测试或验证器数据。JSONL 必须为每项发现包含一条记录，其中包括：

{
  "id": "...",
  "classification": "confirmed_fp | confirmed_fn | taxonomy_gap | harness_artifact | candidate",
  "confidence": "high | medium | low",
  "rule": "...",
  "task": "...",
  "trial": "...",
  "file": "...",
  "lines": "...",
  "evidence": "...",
  "baselineDiagnostics": "...",
  "headDiagnostics": "...",
  "testStatus": "...",
  "rdStatus": "...",
  "rationale": "...",
  "recommendedAction": "..."
}

Markdown 报告必须包含：语料/方法、分布、已确认的误报、已确认的漏报、分类体系缺口、测试框架产物、待人工裁定候选项、按优先级排列的规则修复方案，以及局限性。

按以下方式确定修复优先级：

affected trial coverage × confidence × reproducibility

除非用户另外要求实施已确认的规则修复，否则不得将代码变更作为本技能的一部分。