plugin-fleet-sweep

DSH ホストのアップグレードに伴うプラグイン群の一斉点検

ホストをアップグレードすると、すべてのプラグインが依存する契約が一度に変わります。作業単位は個々のプラグインではなく、定められた順序で一斉点検するプラグイン群全体です。各プラグインに対して判定を行い、問題のあるプラグインごとにリリースを進めます。一斉点検は、実際にアップグレードされたホストで実施します。ソースコードや Node ベースのテストに問題がなくても、ブラウザーエンジンやランタイムのサーフェスの変更に対応できている証拠にはなりません。

常設ルール

1. ソースコードではなく、対象ホストで検証します。 クライアントバンドルが配信され、CSS の style[data-plugin] タグが存在し、slot entry crashed / activation-failure の記録がゼロの場合に、プラグインは「読み込まれた」と判断します。サーフェスマーカーが DOM にあり、想定されるリクエストが発生して初めて、プラグインが「動作する」と判断します。どちらを確認できたか記録してください。
2. まず、手軽に静的な一斉点検を行います。 ブラウザーを操作する前に、すべてのプラグインのソースコードを対象に、新しいホストで名前が変更または削除された API を（plugin-upgrade/references/ にある対象バージョンのコリドーカードを基に）grep で検索します。静的検索で見つかった箇所は、その時点で「修正されるまでは問題あり」と判定できます。
3. エラーがないことは、弱い証拠です。 UI が操作をトリガーとするサーフェス（貼り付け、ファイル操作、フォーカスイベントの後にのみ表示されるもの）は、アイドル状態での一斉点検では何も表示されません。各プラグインのトリガーを把握し、シミュレートするか、成功を主張する代わりに「読み込み済み、操作経路は未検証」と判定してください。
4. 修正とリリースはプラグインごとに行い、プラグイン群全体をまとめたコミットにはしません。 問題のあるプラグインごとに、独自のブランチまたは main へのコミット、バージョン更新、変更履歴への記載、タグ付け、ミラーへのプッシュを行います（各リポジトリ独自のミラーフローを使ってください。sync-mirrors.mjs は作者のプラグインリポジトリ専用です。対象リポジトリのドキュメントに記載された手順を使うか、ミラーがなければ省略してください）。プラグイン群を混在させたコミットでは、プラグインごとのロールバックが不可能になります。
5. プラグインを複数世代のホストに対応させる必要がある場合は、ホストのバージョンに固定したビルドより互換性を優先します。 名前が変更されたホストのエクスポートは、静的な名前付きインポートではなく、実行時にフォールバックチェーン（旧名 → 新しい名前の候補）を使って解決します。また、ユニットテストのモジュールモックにはすべてのフォールバック名を追加してください（厳密なモックは未定義のエクスポートへのアクセス時に例外をスローするため、実際の問題が隠れてしまいます）。

ワークフロー

1. 対象ホストのバージョンに対応するコリドーカード（plugin-upgrade/references/v<target>.md）を読み、そこに記載された名前変更・削除対象のサーフェスを基に静的検索パターンを作成します。
2. 静的な一斉点検：プラグイン群の各リポジトリを対象に、それらのパターンを grep で検索します。見つかった箇所は、ファイル名と行番号を添えて「修正されるまでは問題あり」と記録します。
3. 実環境での一斉点検：実際の GUI を、アップグレード済みホストに対して操作可能なヘッドレスブラウザーで読み込み、プラグインごとに以下を確認します：（a）クライアントの CSS / style タグが存在する、（b）slot entry crashed のコンソール記録がゼロ、（c）サーフェスの DOM マーカーが存在する、（d）想定されるリクエストが発生する。手順： references/fleet-sweep-checklist.md （認証済み GUI へのアクセスと計測の規律については、plugin-runtime-debug/references/browser-forensics.md を参照してください）。
4. 操作をトリガーとするサーフェスは、トリガー（貼り付け、ファイルへの書き込み、キーボードショートカット）をシミュレートして再検証するか、判定を明示的に引き下げます。
5. 問題のあるプラグインごとに、ホストのソースコードを基に診断します（plugin-runtime-debug の常設ルールを参照）。プラグイン群が複数のホストバージョンにまたがる場合は、複数世代のホストに対応する方法で修正し、プラグインの型チェック、テスト、ビルドを実行してからリリースします。リリースには、バージョン更新、対象ホストのバージョン範囲を明記した変更履歴または互換性表の行、コミット、タグ付け、ミラーへのプッシュを含めます。
6. リリース後に実環境での一斉点検を再実行し、最終的なプラグインごとの判定表（プラグイン、対応するホストバージョン、証拠）を記録します。

レポート

最後に、プラグインごとの表を記載してください。内容は、判定（動作中／修正・リリース済み／操作経路未検証／動作不良）、対象となったホストのバージョン、証拠（どのアサーションがどこで通過したか）です。見つかったホスト側のバグは、最小限の再現手順とともに上流に報告してください。また、次回のホストのアップグレードで上書きされる、インストール先ツリー内のホットフィックスがあれば、その内容を再適用用の資料として列挙してください。