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. 独立した第 2 パスを実施する

既知のクラスターだけでなく、各試行を検索して追加候補を探してください。次のヒューリスティックを適用します。

• コストの高い遅延初期化と、空の Map、Set、および同等のコンテナーの低コストな初期化を区別します。
• レンダリングから導出される状態と、非同期ステータス、メディアエラー、再試行、リソースのライフタイム、サブスクリプション、一時的な UI 状態を区別します。
• 制御コンポーネントでは、必要な親との同期と、エフェクトループや不要なデータ転送を区別します。
• 危険な HTML 値を、ローカルエイリアス、useMemo、ラッパー、ヘルパー関数を通じて追跡します。KaTeX などの信頼できるシリアライザーの出所は保持してください。
• React のドキュメントで推奨されている以前の props との比較と、純粋な導出状態およびレンダリングフェーズの副作用を区別します。
• タイマー、Promise、アニメーション、中止シグナル、サブスクリプション、古くなったクロージャーに、一般的な依存関係やクリーンアップに関する警告では直接説明できない競合がないか調べます。
• フォーカスの強制移動、フォーカスの復元、制御された選択範囲、キーボードのセマンティクス、ARIA の状態遷移を確認します。
• 閾値、エイリアシング、分割代入、ネストされたコールバック、JSX ラッパー、計算プロパティ、TypeScript 構文を確認します。
• 診断対象が変更されたコード上にあり、既存の問題、生成されたアーティファクト、フィクスチャー、または変更されていない隣接コードではないことを確認します。
• FP として提案するものごとに、近くにある真の陽性例を探します。FN として提案するものごとに、検出器が検出する近くの事例を探します。

既知の手がかりは、分類を先入観で決めず、独立して再確認してください。

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 には、各検出結果につき次の項目を含むレコードを 1 件ずつ記録してください。

{
  "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 レポートには、コーパス／方法論、分布、確認済みの FP、確認済みの FN、分類上のギャップ、ハーネスのアーティファクト、手動判定の候補、優先順位を付けたルール修正、制限事項を含めてください。

修正の優先順位は、次に基づいて決めてください。

affected trial coverage × confidence × reproducibility

このスキルでは、確認済みのルール修正の実装をユーザーが別途依頼しない限り、コードを変更しないでください。