rule-validate

ルールを検証する

実装が、テストと実際のコードにおける rule-research の契約に一致していることを確認します。

実装をレビューする

次の点を確認します。

• 誤検出や、主張されている動作の見落とし
• 不正なインポート、エイリアス、またはシャドーイングされたバインディング
• 成立しない制御フローパスの合流
• ネストされた関数を即時実行として扱っている
• 動的プロパティを静的な名前として扱っている
• 透過的なラッパーの見落とし
• サポートされていないインポート値
• 検出内容を誇張するメッセージ
• 有効なケースと無効なケースのテスト不足

新しいヘルパーを採用する前に truffler を使用します。

bunx @rayhanadev/truffler "<helper-name>" packages \
  --kind function,method,interface,type,constant --limit 20

実装上のバグはそれぞれ、対象を絞った回帰テストで修正します。

検証を実行する

対象を絞ったテスト、パッケージの型チェック、および必須の lint とフォーマットチェックを実行します。変更が共有動作に影響する場合は、より広範なチェックも実行します。

対象ルールをローカルで範囲限定して調査するには rde-eval を使用します。件数が少ない場合はすべてのヒットを調べ、多い場合は代表的なサンプルを調べます。確認できた誤検出はすべて、ルールのテストと fuzz コーパスに追加します。

新しいルール、または検出動作を変更した場合は、プルリクエストのヘッドをプッシュした後に run-parity を実行します。ドキュメントのみ、またはテストのみの変更では実行を省略します。パリティを実行できない場合は、具体的な阻害要因を報告します。

両方の Vercel Sandbox の実行が完了していない限り、パリティを達成したと主張しないでください。リポジトリとプロジェクトルートの件数は個別に比較します。分類する前に、対象ルールの差分を調べます。

リリース成果物を準備する

公開パッケージにユーザー向けの変更がある場合は nr changeset を実行します。ルール、バグ修正、誤検出の修正、診断の改善には、リリースへの影響上、より適切なものがない限り、patch changeset を使用します。プライベートな変更、ドキュメント、テスト、またはツールの変更の場合に限り省略し、その理由を明記します。

検証後にプルリクエストの説明文を作成します。

## Why

<specific runtime problem>

## What changed

- <detector behavior>
- <valid patterns preserved>
- <tests added>

## Eval results

| Check             | Result                |
| ----------------- | --------------------- |
| Projects compared | `<count>`             |
| Skipped projects  | `<count>`             |
| Added / removed   | `<added> / <removed>` |
| Target rule delta | `<added> / <removed>` |
| False positives   | `<count>`             |
| Artifacts         | `<paths>`             |

## Test plan

- `<command and result>`

パリティを実行していない場合は、評価テーブルを省略します。代わりにその理由を明記します。

レビューでの指摘に対応する

正確性に関わるバグ、重複したヘルパー、誤解を招く名前、わかりにくいコードを修正します。サポートされていない制御フローは、契約の対象外である場合に限り、対応を見送ります。メッセージの適用範囲を広げたり、誤検出を増やしたりする要望は却下します。

修正または説明をプルリクエストに反映した後、レビューのスレッドを解決します。

検証結果を報告する

実行したコマンド、レビューでの指摘、ローカルでの RDE の根拠、パリティの結果または阻害要因、修正した誤検出、回帰テスト、changeset、プルリクエストの説明、残る非目標を報告します。