ホットリロード全体計画

このディレクトリは、issue #3696  の設計作業を追跡するものです。これは、skill、extension、MCP サーバー、LSP サーバー、およびランタイム設定のための包括的なホットリロードシステムに関するものです。

目標

ユーザーは、現在の Qwen Code セッションを再起動することなく、skill、extension の状態、MCP/LSP の設定、およびサポートされている設定を更新できるようにする必要があります。システムは、ランタイム状態の変更を予測可能かつ可視化しつつ、会話のコンテキストを保持する必要があります。

サブタスクの内訳

ホットリロード計画には 6 つの最上位サブタスク があります。現在追跡中の issue では、実装を明確にするためにサブタスク 3 を 3a と 3b に分割しているため、実行チェックリストには 7 つのエントリ が含まれています。

ドキュメントのマッピング

• settings-change-detection.md は サブタスク 1: 設定ファイルの変更検出 に対応します。これはウォッチャーインフラストラクチャを提供します。サポートされている settings.json の変更を検出し、ディスクから設定をリロードして、リスナーに通知します。意図的に、更新された値を Config スナップショットにプッシュしたり、ランタイムサブシステムを再起動したりすることはありません。
• mcp-runtime-reinitialization.md は サブタスク 3a: MCP サーバーのランタイム再初期化 に対応します。これは設定変更イベントを消費し、ランタイム MCP 設定を更新し、ライブ MCP 接続を段階的に調整します。元の issue では MCP と LSP が最上位サブタスク 3 の下にグループ化されていましたが、このドキュメントは MCP の半分のみを対象としています。
• lsp-runtime-reinitialization.md は サブタスク 3b: LSP サーバーのランタイム再初期化 に対応します。ワークスペースの .lsp.json の変更を監視し、既存のネイティブ LSP クライアントを再利用し、ライブ LSP サーバーを段階的に調整します。

実装順序

1. サブタスク 1 を基盤として維持します。設定の変更が検出およびディスパッチされますが、何をリフレッシュするかはコンシューマーが決定します。
2. サブタスク 3a を完了させ、MCP サーバーの追加、削除、および設定の編集がランタイムで有効になるようにします。
3. 同じ原則を使用して LSP ランタイム再初期化のためのサブタスク 3b を追加します。ランタイム設定を更新し、影響を受けるサーバーを停止し、変更されたもののみを再起動します。
4. skill、command、prompt、extension、MCP、および LSP 全体でのキャッシュおよびランタイムリフレッシュのための共有オーケストレーションレイヤーとして、サブタスク 4 を導入します。
5. 手動のユーザーエントリーポイントとしてサブタスク 5 を追加します。/reload は統合オーケストレーションパスを呼び出し、何が変更されたかを報告する必要があります。
6. バックグラウンド変更の UX のためにサブタスク 6 を追加します。検出された変更を自動的に完全に適用できない、または適用すべきでない場合に needsRefresh を設定し、ユーザーに /reload の実行を促します。

設計原則

各レイヤーの範囲を狭く保ちます。

• ファイルウォッチングは設定の変更を検出して報告します。
• サブシステムの再初期化は、影響を受けたランタイム状態のみを更新します。
• 統合オーケストレーションは、既存のリフレッシュ操作を順序立てて実行します。
• UI コマンドと通知は、リロードロジックを重複させることなく、この動作を公開します。