plan

統合プランを生成する（SDK インストール）

検出した内容に基づいて、適切な SDK を選択し、必要な最小限の変更を計画します。

このスキルは LaunchDarkly SDK Install（オンボーディング） の下にネストされています。親の ステップ 2 は plan です。前: リポジトリのスタックを検出する。次: コード変更を適用する。

適切な SDK を選択する

SDK recipes リファレンスを使用して、検出したスタックを SDK に照合します。一般的なスタックについては、そのファイルの トップ 10 SDK（ここから開始） から始めてください。あまり一般的でない SDK については、(その他) のセクションを使用してください。

重要な判断:

プロジェクトの種類	SDK の種類	キーの種類
バックエンド API、サーバーレンダリングアプリ、CLI ツール	サーバーサイド SDK	SDK キー
ブラウザー SPA（React、Vue、Angular、バニラ JS）	クライアントサイド SDK	クライアントサイド ID
iOS または Android ネイティブアプリ	モバイル SDK	モバイルキー
React Native	モバイル SDK	モバイルキー
Flutter（iOS、Android、またはデスクトップ アプリ ターゲット）	クライアントサイド SDK（Flutter）	モバイルキー
Flutter web	クライアントサイド SDK（Flutter）	クライアントサイド ID
Electron デスクトップアプリ	クライアントサイド SDK（Node.js）	クライアントサイド ID
Cloudflare Workers、Vercel Edge、AWS Lambda@Edge	Edge SDK	SDK キー
.NET クライアント（MAUI、Xamarin、WPF、UWP）	モバイル SDK（.NET）	モバイルキー
C/C++ クライアントアプリケーション	クライアントサイド SDK（C/C++）	モバイルキー
C/C++ サーバーアプリケーション	サーバーサイド SDK（C/C++）	SDK キー
Haskell サーバー	サーバーサイド SDK（Haskell）	SDK キー
Lua サーバー	サーバーサイド SDK（Lua）	SDK キー
Roku（BrightScript）	クライアントサイド SDK（Roku）	モバイルキー

サポートされているすべての SDK、パッケージ名、インストールのヒント、公式 Docs リンクについては、SDK recipes および snippets/ 配下のリンクされたファイルを使用してください。

デュアル SDK 統合

このセクションは、ユーザーがサーバー側とクライアント側の両方の統合を求めた場合、またはスタックが明らかに 2 つの LaunchDarkly SDK を必要とする場合（例: サーバー側評価およびブラウザー UI フラグを伴う Next.js、1 つのワークスペースターゲット内の別々のバックエンド + SPA リポジトリなど）に使用します。

しないでください: 1 つの SDK でオンボーディングを「完了」させつつ、2 つ目を曖昧にごまかすこと（package.json に 2 つ目のパッケージがない、2 つ目の初期化パスがない、2 つ目のレシピに従っていない）。各 SDK は個別の製品であり、独自のインストールコマンドと初期化を持ちます。

2 つの SDK のそれぞれについて、計画には（抜けなく）明記する必要があります:

サーバー側トラック:

1. レシピ / SDK レシピ の行またはスニペット名
2. パッケージ名（正確な成果物）
3. インストールコマンド（レシピからの完全なコマンド）
4. 依存関係ファイル（行が追加される場所）
5. エントリポイントファイル（例: instrumentation.ts、API エントリ、main.py）
6. 環境変数（通常は LAUNCHDARKLY_SDK_KEY）
7. 初期化の概要（どこで実行されるか、どのドキュメント/スニペットか）

クライアント側トラック:

1. レシピ / スニペット名（サーバーとは異なる行）
2. パッケージ名（例: React Web 対 Node サーバー -- クライアントの成果物でなければなりません）
3. インストールコマンド（2 つ目のコマンド -- 決して暗黙にしない）
4. 依存関係ファイル
5. エントリポイントファイル（例: app/providers.tsx、ルートレイアウト、main.tsx）
6. 環境変数（バンドラー接頭辞付きのクライアント側 ID、例: NEXT_PUBLIC_...）
7. 初期化の概要（クライアントレシピのプロバイダー/ラッパー/フック）

2 つのパッケージと 2 つのエントリポイントを挙げられない場合、計画は完了していません -- SDK レシピ と検出に戻ってください。

重要な相違点:

• Next.js: サーバー上で評価する API ルート / サーバーコンポーネント / RSC コンテキストにはサーバー側 SDK、クライアントコンポーネントには React クライアント SDK を使用します。ユーザーが両方を希望した場合、計画には両方のトラックを完全に記載します。最初に片方のサーフェスのみを希望する場合は、計画にその旨を明記してください。
• Node.js: バックエンドサービス（Express、Fastify など）の場合は、サーバー側 SDK を使用します。デスクトップ/Electron アプリ用の Node.js クライアント SDK もあります。
• React: スタンドアロンの SPA の場合は、launchdarkly-react-client-sdk を使用します。Next.js の一部である場合は、上記を参照してください。
• .NET: ASP.NET およびバックエンドサービスにはサーバー SDK（LaunchDarkly.ServerSdk）を使用します。MAUI、Xamarin、WPF、UWP には .NET モバイル SDK（LaunchDarkly.ClientSdk、モバイルキー）を使用します -- SDK レシピ -- .NET (クライアント)。Blazor WebAssembly（およびその他のブラウザーでホストされる .NET クライアント UI）は依然として LaunchDarkly.ClientSdk を使用しますが、モバイルキーではなくクライアント側 IDを使用します -- 同じレシピを参照してください。
• Flutter: Flutter クライアント SDK（launchdarkly_flutter_client_sdk -- SDK レシピ -- Flutter）を使用します。一般的な iOS/Android/デスクトップアプリビルドにはモバイルキーを使用し、Flutter web にはクライアント側 ID（およびプロジェクトの公開環境変数のパターン）を使用します。ユーザーが複数のターゲットを出荷する場合は、最初にどれを接続するかを確認するか、ターゲットごとに別々の環境/設定を計画してください。

変更を計画する

統合計画では、正確に以下を特定する必要があります:

1. 変更するファイル

リポジトリスタックの検出 で収集した情報 -- 具体的には検出されたパッケージマネージャー、依存関係ファイル、アプリケーションのエントリーポイント -- を使用します。

• 依存関係ファイル: 検出時に特定されたファイル（例: package.json、requirements.txt、go.mod）-- 検出されたパッケージマネージャーを使用して SDK を追加します
• エントリーポイントファイル: 検出時に特定されたアプリケーションのエントリーポイント -- SDK の初期化コードを配置する場所です。デュアル SDK の計画では、2 つのエントリーポイントを記載します（デュアル SDK 統合 を参照）。
• 環境/設定ファイル: 実際のシークレットには統合ルートの .env を優先します（存在しない場合は作成してください）。そのルートの .gitignore に .env が記載されていることを確認してください。プレースホルダーにのみ .env.example / .env.sample を使用します。プロジェクトが dotenv を使用していない場合は、既存の設定パターンに従ってください -- 同意、キーの書き込み、サーバー+クライアントのハイブリッドケースについては、コード変更の適用 のステップ 2 を参照してください。

2. コード変更

対象範囲の各 SDK（1 つまたは 2 つのトラック）について、具体的な変更を説明します。

1. SDK 依存関係の追加 -- SDK レシピのインストールコマンド（デュアル SDK の場合は各パッケージごとに繰り返します）
2. SDK インポートの追加 -- そのトラックのエントリーポイントの先頭に記述するインポートステートメント
3. SDK 初期化の追加 -- そのレシピ/スニペットにあるその SDK の初期化コードを、適切なライフサイクル（サーバーかクライアントか）の早い段階に配置します
4. 認証情報の設定 -- 環境変数を介して行い、ハードコードは決してしません（トラックごとに SDK キーかクライアントサイド ID か）

3. 環境変数の規約

プロジェクトが設定をどのように扱っているかを確認します。

• .env: スタックが dotenv を使用している場合（または LaunchDarkly のために導入する場合）は、統合ルートに .env が存在しなければ作成し、必要に応じて LAUNCHDARKLY_SDK_KEY、LAUNCHDARKLY_CLIENT_SIDE_ID / バンドラー接頭辞付きのクライアント ID、または LAUNCHDARKLY_MOBILE_KEY を追加する計画を立てます（名前、実際の値の前の同意、サーバー+クライアントのハイブリッドケースについては、コード変更の適用 のステップ 2 を参照してください）。そのルートの .gitignore に .env が含まれていることを確認する計画も立てます（記載がなければ追加しますが、他のリポジトリ編集と同じユーザーの許可を得て行います）。
• .env.example / .env.sample: 存在する場合は、プレースホルダーのエントリのみを計画します（実際のシークレットは不可）。
• 設定モジュールまたは process.env: プロジェクトが .env を使用していない場合は、シークレットに関する既存のパターンに従う計画を立てます。

計画を提示する

変更を加える前に、計画をユーザーに要約してください。

単一 SDK:

1. [install command] を使用して [package name] をインストールする
2. [dependency file] に SDK 依存関係を追加する
3. [entrypoint file] にインポートと初期化を追加する
4. .env に [env var] を追加する（存在しない場合は作成する。実際の値はユーザーの同意後に設定）
5. .env が .gitignore に含まれていることを確認する
6. プロジェクトで .env.example を使用している場合は、そこにプレースホルダーを追加する

ユーザーが他の依存関係の変更を明示的に承認しない限り、LaunchDarkly SDK パッケージのみが追加されます。

デュアル SDK: デュアル SDK 統合に従い、同じ番号形式の手順をトラックごとに個別に提示してください（例: 「サーバーサイド:」の手順 1〜7、続いて「クライアントサイド:」の手順 1〜7）。2 つ目のトラックを省略しないでください。

計画を提示した後:

D6 -- 非ブロッキング（異議がなければ続行）: 「これから行うことは次のとおりです。中止したい場合や、問題がある場合は知らせてください。」といった注記とともに計画の要約をユーザーに提示します。その後、明示的な承認を待たずに コード変更の適用 に進みます。ユーザーが異議を唱えたり、問題があると述べた場合は、続行する前に対処し、計画を調整してください。

これは、手続きを減らすために意図的に非ブロッキングとしています。計画はユーザーに表示され、いつでも中断できます。実際の安全ゲートは、適用ステップにおける D7（シークレットの同意）と D8（非 LD 依存関係の変更）です。

エントリーポイントが曖昧な場合や、複数の SDK が該当する可能性がある場合、それらの具体的な質問はブロッキングです。構造化質問ツールを使用して計画提示の一環として質問し、続行する前に回答を待ってください。

計画確認の一環として、SDK キー、クライアントサイド ID、モバイルキーを尋ねないでください。親フローが コード変更の適用 でそれらを収集します。上記の Key type 列は技術的な計画のためのものにすぎず、シークレットを求めるものではありません。

最新の SDK を満たすために無関係な依存関係をアップグレードすると約束したり、示唆したりしないでください。適用では、LaunchDarkly 以外のパッケージを変更する前に明示的な承認が必要です。

---

完了時: コード変更の適用