add-a-linter

vigiles の相互参照エンジンにリンターを追加します（enforce("eslint/...") の領域です）。これはコントリビューター向けのタスクであり、サードパーティー向けの拡張ポイントではありません。LINTERS レジストリは Record<BuiltinLinter, LinterAdapter> であり、コアに組み込まれた閉じた集合です。そのため、リンターを追加するには vigiles 自体を編集します。型システムと適合性テストによって、対応漏れを確実に防止します。

このスキルが存在する理由は、以前はリンターの追加に、互いに離れた約7か所（存在チェック、設定チェッカー、CLI ツールのマップ、候補の列挙、型生成用の検出処理、ドキュメント、サイト）への変更が必要だったにもかかわらず、すべてに手を加えたかを確認する仕組みが何もなかったことです。1か所でも漏れると、何も通知されずに失敗していました。現在は、レジストリエントリーがないと tsc が失敗し、ドキュメントの表やマーケティングサイトにずれがあると src/core/linter-contract.test.ts が失敗します。手順に従い、忘れた箇所はゲートに検出させてください。 research/linter-adapter-architecture.md を参照してください。

たった1つの不変条件

リンターは、1つのレジストリに登録された1つの LinterAdapter です。それ以外のすべて（存在確認、設定の有効性、候補、型生成、ドキュメント、サイト）は、そのアダプターのフィールドまたはメソッドであり、適合性テストによって相互に照合されます。もう「このリンターを登録している別の場所」を探す必要はありません。

手順

この順番で作業してください。各手順のゲートが、次に必要な作業を示します。

1. 名前を追加します（唯一の情報源）。 src/core/spec.ts の BUILTIN_LINTERS に小文字の名前を追加します。BuiltinLinter はこの配列から導出されるため、 保存するとすぐに linters.ts の LINTERS で tsc が失敗し、「property <name> is missing」というエラーが表示されます。このエラーが、そのまま 作業リストになります。

2. 存在チェックの種類を選びます（src/core/linter-adapter.ts の LinterCapabilities.existenceCheck）。これは、アダプターの構築に使用するヘルパーを決めます。

   • node-api — ルールセットを、インストール済みの npm パッケージから解決します （eslint、stylelint）。nodeApiAdapter(name, resolver, configEnabled, discover) を 使用します。
   • cli — 実際のコマンドを使って、ツールにルールの存在を問い合わせます （ruff、clippy、pylint、rubocop、detekt、ktlint、checkstyle、golangci-lint）。 cliAdapter(name, cliTool, checkExists, configEnabled, discover, enumerate?) を 使用します。
   • filesystem — ツールは使わず、プロジェクトファイル内に存在することを確認します （cedar）。リテラルのアダプターを記述します（linters.ts の cedar を参照）。
   • format-only — 参照の形式のみを検証します。ルール一覧を取得するツールはありません （ktlint のカタログは列挙できません）。これも cli アダプターですが、 enumerate 引数を省略します。存在チェックには、修飾形式のルールを使います。

3. 検出処理を実装します。linters.ts に discover<Name>Rules(basePath): DiscoveredRules | null を追加します。プロジェクトの実際のリンター設定を読み取り、 generate-types 向けに有効なルールを返します（列挙できない場合は寛容側に倒し、 すべてのルールをエラーにするのではなく null を返します）。cli リンターの場合は、 ルールが不明なときに例外をスローする存在確認プローブ <name>CheckExists も記述します。 また、実際の設定有効性を読み取る場合は <name>ConfigEnabled チェッカーも記述します。 これらは LINTERS レジストリ内でアダプターから直接参照される、名前付き関数です （別のマップを変更する必要はありません）。構造化設定を解析する際は、手書きの正規表現ではなく 実際のパーサー（js-yaml / @iarna/toml / 共有の markdown-it ヘルパー）を使用します。 parse-structured-input-with-a-real-parser ルールを参照してください。 detekt の parseDetektConfig（js-yaml）が手本です。

4. LINTERS（linters.ts）に、対応するヘルパーを使って登録します。ここで tsc が成功し、レジストリが完成します。

5. ドキュメントを追加します — docs/linter-support.md：## Supported Linters の表に 行を追加し、さらに ## <Linter> セクションも追加します（設定の規約、ルールの接頭辞、 「形式のみ」や「ホワイトリストのみ」などの機能上の制約）。適合性テストでは、 表とレジストリの項目が一致するかを検証するため、行がないと CI が失敗します。

6. サイトは自動的に更新されます — vigiles.sh のチップ一覧（Wedge.tsx）は BUILTIN_LINTERS から導出されるため、新しいリンターは自動的に表示されます。編集する配列はありません。必要に応じて、Wedge.tsx の LINTER_LABELS に表示ラベルを追加できます（例：ESLint、RuboCop）。追加しなければ、小文字の名前で表示されます。適合性テストにより、この導出が維持されていることを確認します（手入力のリストに戻すと CI が失敗します）。

7. cli リンターの場合は、CI で実際に実行するようにしてください。黙ってスキップさせてはいけません。 実際のバイナリを使うテストは、src/core/linters.test.ts の describe.skipIf(!hasBinary("<tool>")) です。CI にバイナリがない場合、これらのテストは黙ってスキップされます（見えにくい欠落です — no-silent-skips ルール）。.github/workflows/ci.yml の test ジョブにツールをインストールし（ジョブの env でバージョンを固定し、キャッシュしてください）、さらに command -v の確認ループにも追加してください。バイナリがない場合にスキップするのではなく、ビルドを失敗させます。次に、相補的なテストを 2 つ作成します。実際のバイナリを使うテスト（describe.skipIf(!hasBinary)）と、バイナリがない場合の正確なエラーを検証するテスト（it.skipIf(hasBinary)）です。どちらか一方は必ず実行されるため、どちらの場合も見逃されません。

8. パリティテストのデータを追加します。 src/core/linter-contract.test.ts の適合性ループは汎用的で、レジストリを反復処理するため、新しいリンターも自動的に対象になります。ただし、新しいリンター固有のパーサーについて、linters.test.ts に設定解析／検出の単体テストを追加し、通常と異なる差異（例：format-only、alwaysEnabled）がある場合は、リンターごとの機能アサーションも追加してください。

これらのゲートで安全性を確保します

npm test を実行してください（または少なくとも npx vitest run src/core/linter-contract.test.ts src/core/linters.test.ts と tsc --noEmit を実行してください）。以下を満たした場合にのみ完了です。

• tsc がエラーなく完了する — レジストリエントリが存在すること（完全性）。
• linter-contract.test.ts が成功する — key === name、すべての機能フラグがメソッドの有無と一致すること、existenceCheck === "cli" ⟺ cliTool が存在すること、レジストリのキーが BUILTIN_LINTERS および docs/linter-support.md およびサイトのチップ一覧と一致すること（ドキュメントとサイトのパリティ）。
• 新しいリンターの設定解析単体テストがバイナリなしで成功し、実際のバイナリを使うテストが CI でスキップされずに実行されること（インストール済みで、存在確認の対象になっていること）。