experience-lwc-widget-migrate

LWC をウィジェットに移行する

LWC を使ってユーザーの目標とデータ契約を把握し、最も適切で役立つウィジェットを構築します。ウィジェットは、それ自体が宣言型のアーティファクトです。platform-widget-generate がこれを作成しますが、利用可能にするには Lightning Type レンダラーを別途接続する必要がある場合があります。このスキルでは、比較、引き継ぎ、統合チェック、および最終状況の正確な報告を行います。

1. 続行するかどうかを判断する

experience-lwc-widget-assess を読み、コンポーネント、そのアクション出力、既存の Lightning Type／レンダラーに適用します。その判定と、レポートの主な調査結果（ブロッカー、契約の変更、失われるインタラクション）をレポートに記載します。評価用の verdict.json ファイルや report.md ファイルは作成しないでください。pointless、blocked、review、または needsHumanReview: true の場合は中止します。意図する変更が明確な場合に限り、viable で続行します。

• port-declarative の場合は、現在表示されているフィールドとアクションを維持します。
• needs-IA-contract-change の場合は、必要となる出力フィールド、または整形済みの値を具体的かつ限定的に特定します。提案中の契約に基づくウィジェットは、その契約がアクションから返されるまではドラフトです。動作するとは表現しないでください。
• 実現可能な代替案がある not-portable の場合は、代替 UX と失われるインタラクションをそれぞれ説明します。忠実な移植ではなく、再構築として扱ってください。

2. ジェネレーターへの引き継ぎ内容を導き出す

提案するウィジェットに表示する各値を、実際の、または提案中のアクション出力までたどります。作成に取りかかる前に、評価プロンプトの説明だけに頼らず、アクションの契約を確認してください。platform-widget-generate には、順序付けされたフィールド形状（name、type、required）、ネストされたフィールド／リスト項目のフィールド、表示要素ごとのタイル上の役割、およびサポートされる終端アクションを渡します。レンダー順とフィールドパスを維持してください。タイル定義と属性には検出結果を、式には文書化された数式カタログを使い、スキーマ型とバンドルのレイアウトにはその指示に従ってください。ここに二重のカタログを用意しないでください。数式でサポートされているスカラー／日付／正規表現の演算に対応できる一方、コレクションの再構成には整形済みの出力が必要な場合があります。

LWC のフィクスチャやアクションの例にサンプルデータが含まれていれば、形状の推測に役立ちます。サンプルデータは任意であり、文書化されたジェネレーター入力ではなく、アクション契約の代わりにもなりません。サンプルフィールドを作り出さないでください。sendMessage などのアクションでは、必要なコンテキストがエージェントに届くことと、エージェントが要求された作業を実行する手段を持つことを確認してください。ウィジェットの入力フォームが収集した値を送信できると決めつけないでください。検出され、検証された仕組みが必要です。

3. 生成して接続する

platform-widget-generate を読み込み、必須のライブ discoverUiComponents と getUiComponentSchemas の呼び出しに従ってください。metadata-experts MCP またはディスカバリーを利用できない場合は、バンドルを作成する前に停止し、完了した評価と提案するフィールド構成を報告してください。ジェネレーターは、ウィジェットの3つのファイルと自己検証を担当します。このスキルにUEM構文や検証チェックリストを転記しないでください。

Agentforce レンダラーの移行では、アクションの出力を受け取る Lightning Type も特定してください。バンドルだけではアクションに接続されません。

• 互換性のある既存の Lightning Type がある場合： スキーマと現在の renderer.json を確認してください。生成後、platform-custom-lightning-type-generate/references/widget-rendition.md を読み、フィールドマッピングを使ってウィジェットを接続し、platform-lightning-type-widget-coordinate のレンダラー確認に従ってください。既存のレンダラーが別のウィジェットまたはLWCを参照している場合は、変更する前に置き換え／統合の判断を明示してください。
• 互換性のある Lightning Type がない場合： プロジェクトまたはユーザーのリクエストから、アクションの出力クラスと Lightning Type 名を特定してください。コーディネーターがサポートするApexベースの方法では、そのTypeと評価済みの出力形状を使って platform-lightning-type-widget-coordinate を使用し、バンドルの生成とレンダラーの接続はコーディネーターに任せてください。このコーディネーターが対応するのは、すべてのTypeではありません。出力／Typeの方法を特定できない場合は停止し、不足している統合手順を明示してください。移行が完了したと主張しないでください。

ユーザーがバンドルのみを依頼した場合は、未接続のバンドルであることを明示して報告してください。それ以外の場合、完了にはバンドルとレンダラーの接続の両方が必要です。

4. 結果を確認する

ジェネレーターのバンドル自己検証を使用してください。次に、結果を評価済みの候補と比較します。保持する表示フィールドすべてに実際の／提案されたペイロードへのバインディングがあること、リスト項目のパスとサポート対象のアクションが一致すること、省略した動作と契約の変更が明記されていること、さらにレンダラーの移行では Lightning Type が属性の一致するこのウィジェットを指していることを確認してください。静的チェックで確認できるのは構造とマッピングであり、デプロイ後の実行時の動作ではありません。評価結果、作成したパス、検証結果、および migrated and wired、bundle only、draft pending IA contract、stopped のいずれかを、その理由とともに報告してください。