rule-research

ルールを調査する

rule-writing が推測なしで実装できるルールの仕様を作成します。

動作を定義する

正確性に影響する質問だけを解決します。

• どのコードパターンを報告するべきですか？
• どのような実行時の動作が有害ですか？
• どのような類似コードは報告対象にしないべきですか？
• 検出に構文、スコープ、パスの分析が必要ですか？
• インポート、動的、型駆動、またはインタープロシージャルなケースのうち、対象外とするものは何ですか？

ユーザーが実装を依頼した場合は、仕様を簡潔にまとめて続行します。

根拠を集める

1. ルールを1文で定義します：This rule catches <pattern> that causes <problem>.

2. 実行時に問題となる理由を説明します。

3. 近接するルール、テスト、ユーティリティ、生成されたレジストリを調べます。

4. 新しい検出器やヘルパーを提案する前に、truffler を使用します。

   bunx @rayhanadev/truffler "<symbol-or-behavior>" \
     packages/oxlint-plugin-react-doctor/src/plugin \
     --kind function,interface,type,constant --limit 20
   

5. 公式ドキュメント、実装上の注記、関連するリンターの動作、オープンソースの例を集めます。

6. 有力な陽性例、関連パターン、有効な例外、未対応のケースを分けます。

7. 構文のみ、スコープを考慮、パスを考慮のいずれかの検出方法を選びます。

仕様が変わる可能性のある、範囲を限定したオープンソースのサンプルを調べる場合は、rde-eval を使用します。最終的なプルリクエストとの整合性確認は rule-validate に任せます。

仕様を書く

次を返します。

Rule definition:
<pattern and specific problem>

Runtime reason:
<short explanation>

Detector precision:
<syntax-only, scope-aware, or path-aware>

Evidence:

- <source and implication>

Strong positives:

- <reportable examples>

False-positive traps:

- <valid examples>

In scope:

- <supported cases>

Out of scope:

- <explicit boundaries>

Test seeds:

- <invalid and valid fixtures>

Open questions:

- <correctness blockers only>

誤検出は正確性の不具合として扱います。診断範囲は、実証された動作と同等か、それより狭くします。関連する別のアイデアは、個別のルールに分けます。