platform-mcp-tool-widget-coordinate

ウィジェットを使ったカスタム MCP ツール出力のレンダリング

オブジェクトベースのカスタム Lightning 型（CLT）2つとHXLウィジェットを連携させ、実装がApexの@InvocableMethodであるカスタムMCPサーバーツールの出力をレンダリングします。このスキルはコンテンツを直接作成せず、依存関係の順序に従ってリーフスキルを読み込んで呼び出し、ユーザーの承認を得てから進め、完了を報告する前に検証ゲートを実行します。

所有範囲 — このスキルが所有するのは、次の項目のみです。

1. MCPツールのユースケース — ツールの出力形式を特定し、適切な順序でリーフスキルを連携させます。
2. エンベロープCLTのデフォルトのrenderer.json — エンベロープとウィジェットをつなぐ、このスキルがインラインで作成する唯一の成果物です。

CLTはplatform-custom-lightning-type-generateが作成し、すべてのウィジェットメタデータ（スキーマ＋本文＋.uiwidget-meta.xml）はplatform-widget-generateが作成および検証します。このスキルはウィジェットメタデータを一切作成せず、Apexクラスも変更しません。各リーフスキルに入力を渡し、結果を連携させます。

スコープ

Apex Invocable Actionを基盤とするカスタムMCPサーバーツールのみが対象です。MCPツールは、プラットフォームのinvocable-action結果エンベロープを返します。これはactionName、isSuccess、およびツールの実際のペイロードを格納するoutputValuesノードを持つオブジェクトです。このエンベロープをウィジェットでレンダリングするには、対等な2つのオブジェクトベースCLT（lightning__objectType）としてモデル化します。2つに分ける理由は、一方がもう一方を名前で参照する必要があるためです（CLTは自分自身を参照できないため、異なるデプロイ名が必要です）。それぞれが実際にモデル化する内容に基づいて名前を付け、説明します。「Payload CLT」／「Envelope CLT」や「Inner CLT」／「Outer CLT」のように、役割を表す名称をでっち上げてはいけません。

• ツール結果のエンベロープを模倣するCLTの名前は<toolApiName>です。そのoutputValuesプロパティは、c__<responseCLT>を介してもう一方のCLTを型として指定します（CLT参照のプレフィックス。以下の名前空間に関する注記を参照）。
• Invocable Actionのレスポンスの正確な形状（@InvocableMethodのレスポンスクラスにある@InvocableVariableフィールド）を表すCLTの名前は<toolApiName>Responseです。「Response」は架空の役割名ではなく、Apexソース自体がそのクラスに使っている名称です。

ウィジェットはレスポンスフィールド（フラットな形式）を基準にし、エンベロープCLT内のデフォルトのrenderer.jsonが{!$attrs.outputValues.<field>}を使って、エンベロープのネスト構造をフラットなウィジェットにつなぎます。

名前空間プレフィックスの由来（c__ / @apexClassType/<ns>__…）： Actions REST describeはプレフィックスのないクラス名（Outer$Inner）を返し、名前空間は含みません。プレフィックスは組織のCLT名前空間であり、このスキルが追加します。名前空間のない組織（一般的なケースで、このドキュメント全体では文字どおり使用します）ではc__、パッケージ化された組織ではパッケージ名前空間の<ns>__を使用します（クラスのNamespacePrefixから取得し、組織に名前空間がない場合に限りcをデフォルトとします）。以下のすべてのc__は、このプレフィックスです。

対象外の場合は、次のスキルに振り分けます。

• Apexを基盤とするエージェントアクションの出力のカスタマイズ（ApexベースのCLT@apexClassType/...、単一CLT、サーフェス固有のレンダラー）→ platform-lightning-type-widget-coordinate。
• MCPツール／Lightning Typeを使わない単独のウィジェット → platform-widget-generate。
• CLTのみ、またはApexクラスのみの作成 → platform-custom-lightning-type-generate／platform-apex-generate。

ベータ版のカーディナリティ： invocable-actionの結果はバルク配列（content[]）です。ベータ版では、このスキルは単一のレスポンス（content[]の最初の要素）をモデル化してレンダリングします。CLTエンベロープがモデル化するのは1つの結果オブジェクトであり、content[]のラッパーではありません。

---

platform-lightning-type-widget-coordinate との違い

項目	エージェントアクションフロー（...lightning-type-widget-coordinate）	この MCP ツールフロー
CLT の種類	Apex ベース（@apexClassType/...）	オブジェクトベース（lightning__objectType）
CLT の数	1 つ	2 つ（エンベロープ + レスポンス）
フィールドのソース	@AuraEnabled	トップレベルのレスポンスクラスにある @InvocableVariable（参照される内部クラスは public／@AuraEnabled — 厳格なルール 6 を参照）
レンダラーの場所	lightningTypes/<T>/lightningDesktopGenAi/renderer.json（サーフェス固有）	lightningTypes/<toolCLT>/renderer.json（デフォルト。schema.json と同じ階層）
レンダラーのバインド	フラットな {!$attrs.<field>}	ネストされた {!$attrs.outputValues.<field>}

---

フェーズグラフ

フェーズ	目的	出力
1 — 入力の選択	ペイロードのソースを特定します。Invocable アクションの API 名（推奨）、Apex Invocable クラス、または貼り付けられたツール出力 JSON サンプルのいずれかです。	source（action | apex | sample）、ツール API 名
2 — ペイロードの特定	Actions REST API を通じて Invocable アクションを記述し、型付きの outputs を読み取ります（またはソースからレスポンスクラスを解析するか、サンプルから outputValues を読み取ります）。	payloadFields（名前 + lightning:type）
3 — ビルド計画	計画全体を出力し、次の返信で明示的な異議がなければ続行します。	出力された計画
4 — 生成	リーフスキルを読み込んで実行します。レスポンス CLT → エンベロープ CLT → ウィジェット → エンベロープ CLT 内のインラインデフォルトレンダラーの順です。	書き込まれたファイル
5 — 検証	厳格なゲート（ブロック）と警告ゲート（助言）を実行します。	ゲートレポート
6 — 要約	ファイル、検証、デプロイ順序、プレビューの準備状況をまとめます。	要約

フェーズごとの手順： スキルを毎回新たに読み込む → ワークフローを実行する → 出力を検証する → 次のフェーズに進む前にチェックポイントを設ける。リーフスキルの内容を覚えていても、スキルは更新されるため、必ず新たに読み込んでください。

---

フェーズ 1 — 入力の選択

ペイロードの形状のソースを特定します。以下の順に優先してください。

ソース	条件	フェーズ 2 のアクション
action	プロンプトでInvocable アクションの API 名が直接指定されている、またはアクションに解決できる Apex クラス名が指定されており、認証済みの組織が利用可能です。推奨。	Actions REST API を通じてアクションを記述し、型付きの outputs を読み取ります。
sample	接続可能な組織がない（または describe が 404 を返す）が、貼り付けられたツール出力 JSON サンプルを利用できます。	サンプルから outputValues オブジェクトを解析します。
apex	Apex クラスのみが利用可能です（解決可能なアクション名がなく、接続可能な組織もサンプルもありません）。この場合に限るフォールバックであり、デプロイ済みの内容と一致しない可能性があります。	レスポンスクラスを特定し、@InvocableVariable フィールドを列挙します。

ツール API 名を記録します（すべての成果物の命名に使用します。命名規則は以下を参照）。

ソースの優先順位： ライブの正式なスキーマソースはローカルクラスの解析より優先され、ローカルクラスの解析は貼り付けられた例より優先されます。順番は以下のとおりです。

1. アクション API 名と認証済みの組織が利用可能な場合は action。Actions REST API の describe はプラットフォーム自体が公開するものと同じスキーマであるため、リクエストやヘルパーによるフィルタリングが不要で、実際のフィールド型を取得できます。
2. 実行時の JSON サンプルが貼り付けられている場合は sample（実行時のレスポンスであり、明示的かつ最新です）。
3. Apex クラスがローカルに存在し、上記のいずれにも該当しない場合は apex（フォールバックのみ — アクションの背後に実際にデプロイされている内容と一致しない可能性があります）。

いずれも利用できない場合は、作業を停止し、アクション名、クラス、サンプル、またはスキーマをユーザーに求めてください。

---

フェーズ 2 — ペイロードの検出

まず references/mcp-tool-output-discovery.md を読み（必須 — この要約だけをもとにフェーズ 2 を実行しないでください）、選択したソースに対応する手順を実行します。このリファレンスは、ソースごとの完全な手順、フィールド型の対応表、ネスト／リストの扱いについての正式な情報源です。以下のポインターはその案内にすぎません。

• action（推奨）： sf api request rest '/services/data/v<APIVER>/actions/custom/apex/<ActionApiName>' -o <org> で詳細を取得します。outputs 配列のみを使用します（リクエストラッパーである inputs は無視します）。各 type を大文字小文字を区別せず CLT lightning:type に対応付けます。"type": null かつ "apexClass": "<Outer>$<Inner>" キーを持つエントリーは、Apex クラス型のフィールドです（詳細情報の欠落ではありません）。maxOccurs: 1 は単一のネストされたオブジェクト、maxOccurs > 1 はトップレベルのリストです。詳細取得が 404 になった場合は、sample、次に apex の順にフォールバックします。
• apex（フォールバック）： クラスを特定し、レスポンスクラス（@InvocableMethod の戻り値 List<...> の要素型）を識別し、その @InvocableVariable フィールドを列挙します（リクエストクラスと private ヘルパーは除外します）。Apex 型を CLT 型に対応付けます。
• sample（フォールバック）： outputValues オブジェクトを解析し、JSON 値から各フィールドの lightning:type を推測します。

ネストされたオブジェクトとリストのフィールド（すべてのソースで、フラットなプリミティブ型の場合に加えて適用）： 別の Apex クラスとして型付けされたフィールド — 単一のオブジェクト（maxOccurs: 1）、トップレベルのリスト（maxOccurs > 1）、またはラッパーオブジェクト内のリスト（詳細取得では maxOccurs: 1 の apexClass 出力が 1 つ返され、内部のリストが隠されている場合） — は対象範囲に含まれ、単なる {"type":"object"} やインラインの lightning__objectType としてモデル化してはなりません。レスポンス CLT では @apexClassType/c__<Outer>$<Inner> として型付けします（CLT レベルの lightning__listType／items は使用しません）。参照先／内部クラスはそのpublic／@AuraEnabled メンバーで列挙し（ハードルール 6）、リーフがクラス自体である場合は再帰的に処理します。各形状に応じた CLT の型付けとレンダラーのバインディング深度は、references/mcp-tool-output-discovery.md と references/two-clt-modeling.md（「トップレベルのリストとラッパー内のリスト」）に記載されています — ハードルール 4、6、14、および examples/nested-object-*-source-prompt.md の手順例も参照してください。

レスポンス CLT とウィジェットのスキーマを定義する、順序付きの { name, title, lightning:type } のリストである payloadFields を記録します。ビルド計画には、それを生成したソースも記録します。

古さへの対策：セッションをまたぐキャッシュは維持しないでください。プロジェクトのローカルファイルを毎回新たに読み込み、セッションごとに組織から再取得してください。

---

フェーズ 3 — ビルド計画と承認ゲート

references/build-plan-format.md のテンプレートを使ってビルド計画を出力します。計画には次を含めてください。

• 開発者向けの一行要約（PLAN: 行）。
• ツールの API 名とレスポンスクラスの FQN（または「貼り付けられたサンプルから」）。
• 2 つの CLT 名（エンベロープとペイロード）およびウィジェット名と、それぞれの絶対パス。
• エンベロープ CLT に含めるのは actionName（テキスト）、isSuccess（ブール値）、outputValues（型は c__<responseCLT>。レンダラーが値を受け渡すための重要なフィールド）だけです — actionName／isSuccess はエンベロープ専用で、ウィジェットには決して含めません（ハードルール 5）。また、レスポンス CLT とウィジェットが保持するレスポンスフィールドも記載します。
• 生成後に実行する検証。

計画をすべて出力してから、ユーザーの次の返信で明示的な異議が示されない限り続行します。 明示的な異議とは、no、stop、wait、change X、use Y instead、または同等の拒否／変更要求です。明示的な承認は歓迎しますが、必須ではありません — 返信がない場合、関係のない追加質問がある場合、または単一ターンの評価が自然に続く場合は、すべて暗黙の承認とみなします。計画が会話の記録に表示されていることが必須です。異議があった場合は、修正して再度出力してから先に進みます。

---

フェーズ 4 — 生成

以下の順序でリーフスキルを読み込み、呼び出します。各スキルについて、スキルを読み込み、フェーズ 3 の仕様に基づいてワークフローを実行し、出力を検証してから、次に進む前にチェックポイントを作成します。

1. Response CLT — platform-custom-lightning-type-generate を読み込みます。オブジェクトベースの CLT <responseCLT>（規約：<toolApiName>Response）を作成します。properties にはフェーズ 2 の payloadFields を指定します。ルートは lightning__objectType とし、ルートレベルに "lightning:tags": ["mcp"] を設定します。

   • レスポンス CLT のトップレベルプロパティは、describe の outputs[] の名前（または apex／sample の場合は、レスポンスクラスの @InvocableVariable フィールド。describe で公開されるフィールドと同じ）と 1 対 1 に対応します。 describe に N 個の兄弟出力がある場合は、フラットなプロパティを N 個用意します。出力が 1 つの場合は、その出力名のプロパティを 1 つ用意します。単一プロパティの CLT が正しいのは、describe 自体が単一の出力を返す場合のみです。
   • 複数の兄弟出力を、独自に作った 1 つのラッパープロパティにまとめてはいけません。 複数の出力を格納するために単独のプロパティ名を付けると、どの describe 出力にもないキーを作ることになり、action ソースでは解決できません。レスポンスクラス名は outputs[] に現れません。各レスポンス CLT プロパティ名は、describe の出力名までたどれる必要があります（field-trace／clt-reference-integrity を参照）。
   • トップレベルのリスト出力は、要素クラスを直接指定します（@apexClassType/c__<Outer>$<ElementClass>）。ラップしません。上記の「ネストされたオブジェクトのリスト」を参照してください。

2. Envelope CLT — platform-custom-lightning-type-generate を読み込みます。オブジェクトベースの CLT <toolCLT>（規約：エンベロープである <toolApiName>）を作成します。こちらもルートレベルに "lightning:tags": ["mcp"] を設定し、以下を指定します。

   • actionName → lightning__textType
   • isSuccess → lightning__booleanType
   • outputValues → c__<responseCLT>（参照 CLT パターン。エンベロープ CLT より先にレスポンス CLT をデプロイする必要があります）

3. ウィジェット — platform-widget-generate を読み込みます。schema.json のプロパティを payloadFields（名前とプリミティブ型）とするフラットなウィジェットを作成します。これは独立したウィジェットの契約であり、Lightning Type から派生したり、それに依存したりするものではありません。ウィジェットがレンダリングするのは outputValues のデータフィールドのみです。エンベロープ専用の actionName／isSuccess は決してレンダリングしません。ウィジェット本文では各フィールドを {!$attrs.<field>} でバインドします。ウィジェットはエンベロープに依存せず、outputValues 自体を参照することはありません。

4. デフォルトレンダラー（ENVELOPE CLT 内に記述。省略不可）。 まず platform-custom-lightning-type-generate/references/widget-rendition.md を読みます（必須 — 記憶を頼りに作成したり、非推奨の形式を使っている可能性のある既存のサンプルをコピーしたりしないでください）。次に <pkgDir>/lightningTypes/<toolCLT>/renderer.json を作成します。これはデフォルトレンダラーで、バンドルのルートに schema.json と並べて置きます（lightningDesktopGenAi/ 配下には置きません）。renderer.componentOverrides["$"] では、definition を @widget/c/<widgetName> に設定し、ウィジェットのすべての schema プロパティを、エンベロープの outputValues ノード配下にネストした対応するペイロードフィールドに {!$attrs.outputValues.<payloadField>} でマッピングします。このネストしたバインドが、エンベロープ CLT とフラットなウィジェットをつなぎます。renderer.json 内にウィジェット本文を重複して記述しないでください。JSON の作成例は references/two-clt-modeling.md にあります。

既存のレンダラーの扱い： 対象パスに renderer.json がすでに存在する場合は、まず内容を読みます。同じウィジェットを参照し、バインドも同じであれば、そのままにします。別のウィジェット、またはカスタム LWC のルートオーバーライド（c/<component>）を参照している場合は、上書きする前に作業を停止し、競合を報告します。

---

フェーズ 5 — 検証ゲート

references/validation-gates.mdを読みます（必須 — 各ゲートの実行手順と、合格／不合格を判定する正確な条件が記載されています）。すべてのゲートを実行してください。ウィジェットバンドル内部のチェック（スキーマの解析、ルートキー、リーフ型、{!$attrs.X}の解決、.uiwidget-meta.xmlの形式検証）はplatform-widget-generateが担当し、独自の自己検証で実行します。

必須 — 失敗した場合は処理をブロックします：

1. clt-reference-integrity — エンベロープのoutputValuesの型がc__<responseCLT>であり、レスポンスCLTが存在して両方が解析できること。$schema／itemsがないこと。すべての非プリミティブなレスポンスプロパティが@apexClassType/...参照であること（裸のオブジェクトや、CLTレベルのlightning__listTypeは不可）。
2. renderer-wires-widget — バンドルルートのrenderer.jsonが@widget/c/<widgetName>を配線し、ウィジェットのすべてのプロパティをoutputValuesの下に、describeで指定された深さでバインドしていること（トップレベルのプリミティブまたはリスト出力は2セグメント、ラッパーオブジェクト内のリーフ／リストは3セグメント）。双方向に確認します。バインドの不足も余分なバインドも不合格です。
3. nested-list-coverage — フェーズ 2で見つかったすべてのネストされたオブジェクトフィールドとリストフィールドがウィジェットに表示され、正しい深さでバインドされていること。「対象範囲外」／「ベータ版の単一レスポンス」は、正当な除外理由になりません。

警告 — 参考情報：

1. field-trace — references/validation-gates.mdにあるトレースを実行します。レスポンスフィールドを列挙し、ウィジェットスキーマのキーをjqで取得して、INVENTEDとOMITTEDに分類します。ウィジェットに独自に追加されたフィールドは不合格です。省略されたレスポンスデータフィールドは警告となります。

各ゲートの結果を、フェーズ 6で名前とともに報告してください（pass、fail (<reason>)、warn (<reason>)、not run）。「すべて合格」と要約しないでください。このスキルが生成するのはメタデータのみで、デプロイは行いません。デプロイは呼び出し側の責任です。

---

フェーズ 6 — 概要

MCP Tool Widget Build Complete: <widgetName>

FILES GENERATED:
  Response CLT:
    <pkgDir>/lightningTypes/<responseCLT>/schema.json
  Envelope CLT:
    <pkgDir>/lightningTypes/<toolCLT>/schema.json
    <pkgDir>/lightningTypes/<toolCLT>/renderer.json          # default renderer — wires the widget
  Widget bundle:
    <pkgDir>/uiWidgets/<widgetName>/<widgetName>.json
    <pkgDir>/uiWidgets/<widgetName>/schema.json
    <pkgDir>/uiWidgets/<widgetName>/<widgetName>.uiwidget-meta.xml

VALIDATIONS:
  widget self-validation (platform-widget-generate gates): <pass | fail — see sub-skill report>
  clt-reference-integrity (envelope.outputValues → c__<responseCLT>; nested → @apexClassType): <pass | fail (<reason>)>
  renderer-wires-widget (nested {!$attrs.outputValues.X} bindings): <pass | fail (<reason>)>
  nested-list-coverage (every discovered nested/list field rendered): <pass | fail (<reason>)>
  field-trace (INVENTED + OMITTED lists printed): <pass | warn (<reason>) | fail (invented: <list>)>

---

ハードルール（常に適用）

1. 最初に計画を立ててから進めます。 ファイルを書き込む前に、Phase 3 のビルド計画全体を出力します。明示的な拒否または変更依頼があれば停止して修正し、それ以外の場合は続行します。不変条件は、対話形式で人間の承認を得ることではなく、計画が会話の記録に表示されていることです。これは手動チャット、エージェント間のフロー、単一ターンの評価すべてに当てはまります。
2. オブジェクトベースの CLT は 2 つにし、1 つにはしません。 エンベロープとペイロードは別々の CLT です。エンベロープの outputValues は c__<responseCLT> で型指定し、ネストされた lightning__objectType としてインライン化しません。両方の CLT にルートレベルの "lightning:tags": ["mcp"] を含めます（platform-custom-lightning-type-generate/assets/primitive-types-and-constraints.md を参照）。
3. レンダラーは ENVELOPE CLT 内のバンドルルートに配置します。 lightningTypes/<toolCLT>/renderer.json はデフォルトのレンダラーで、schema.json と並ぶ位置に置きます。lightningDesktopGenAi/renderer.json（これはエージェントアクションフロー固有の配置先です）には置かず、レスポンス CLT にも置きません。
4. レンダラーのバインディングはネストします。 すべてのウィジェット属性を {!$attrs.outputValues.<field>} に割り当て、{!$attrs.<field>} にはしません。ウィジェットのスキーマはフラットのままにし、橋渡しはレンダラーで行います。
5. ウィジェットの基盤にするのはエンベロープではなくペイロードです。 ウィジェットのスキーマプロパティには、ペイロード（outputValues）のフィールドを使用します。ウィジェットから actionName や isSuccess を参照してはいけません。これらはエンベロープ CLT にのみ存在するエンベロープ専用フィールドです。
6. フィールドの取得元はクラスの役割によって異なります。 最上位のレスポンスクラスは @InvocableVariable によって判定します。describe に表示されるのはそれらのフィールドのみなので、@AuraEnabled だけが付いた（またはアノテーションのない）最上位フィールドは、出力ではないものとして正しく扱われます。最上位のレスポンスクラスでは @InvocableVariable を使ってフィールドを列挙し、リクエストクラスとプライベートヘルパークラスは除外します。@apexClassType/<ns>__<Outer>$<Inner> を介して参照される内部クラス／参照先クラスでは、代わりにパブリックメンバー／@AuraEnabled メンバーを列挙します。そのリーフは describe に表示されず、そこで @InvocableVariable は使われないため、@InvocableVariable で検索してもリーフは 0 件になり、CLT とウィジェットは空になります。
7. フィールドを捏造しません。 ウィジェットのスキーマ（およびレスポンス CLT）には、ツールが実際に公開しているフィールドのサブセットのみを含めます。つまり、最上位の @InvocableVariable 出力と、参照される内部クラスのパブリック／@AuraEnabled リーフだけに限定し、どのクラスも公開していないプロパティは含めません。field-trace には両方のリストが出力されます。
8. ベータ版では単一レスポンスを使用します。 content[] の一括ラッパーではなく、1 つの結果オブジェクトをモデル化します。
9. 生成前に必ずリーフスキルを読み込みます。 記憶に頼って作成してはいけません。
10. ゲートは説明するのではなく、実行します。 ゲートを実行せずに pass と報告することは重大な違反です。代わりに not run と報告します。
11. Vibes の安全なシェルフィルターを作動させるシェルメタ文字は使用しません。 このオーケストレーターおよび呼び出すリーフスキルが出力するすべての Bash ツール呼び出しで、コマンド置換（$(…) またはバッククォート）、プロセス置換（<(…)、>(…)）、ブレース展開（{a,b,c} または {1..N}）、eval／exec を使用してはいけません。これらは Bypass モードでも手動承認を必須にし、評価を停止させます。個別のコマンドを実行し（mkdir -p a && mkdir -p b）、中間値はそれぞれ専用のコマンドで出力して結果を判断し、値を再利用する場合は通常のシェル変数（X=literal）またはヒアストリングを使用してください。
12. action スキーマは Actions REST API の describe から取得し、MCP エンドポイントへの生の HTTP リクエストや認証情報の抽出から取得してはいけません。 既存の sf 組織認証を使用する組織の Actions REST API に対して、sf api request rest を使用します。a4d_mcp_settings.json やその他の MCP 設定ファイルを読み込んだり、組織のアクセストークンを抽出したり、MCP サーバーエンドポイントに curl で直接アクセスしたりしてはいけません。これにはセッションが持たない認証情報が必要で、ランタイムではその形式で実際には公開されていない URL を対象にすることになります。
13. 出力の形状を調べるために MCP ツールを呼び出してはいけません。 ペイロードの記述時に、基盤となるアクションを実行してはいけません。スキーマは、基盤となるアクションの Actions REST API describe を使って解決します。レスポンスを観察する目的で、サンプル入力や推測した入力を指定してツールを呼び出してはいけません。アクション名を解決できない場合は、何も呼び出さず、ユーザーに sample の貼り付けを依頼します。
14. 別の Apex クラス型として指定されたレスポンスフィールドを、単なる {"type":"object"} にしてはいけません。 レスポンス CLT では @apexClassType/<ns>__<OuterClass>$<InnerClass> 型にし、ウィジェットではリーフフィールドにフラット化し、レンダラーでは 2 階層深くバインドします（{!$attrs.outputValues.<objectField>.<leaf>}）。これはフラットなプリミティブ型の場合（ハードルール 5）に追加されるルールであり、置き換えるものではありません。references/two-clt-modeling.md を参照してください。

---

リファレンスファイル一覧

ファイル	読むタイミング
references/mcp-tool-output-discovery.md	フェーズ 2 — 3 つのソース、フィールドの列挙、型のマッピング。
references/two-clt-modeling.md	フェーズ 4 — エンベロープ CLT とレスポンス CLT、ネストされたレンダラーのバインディング、命名規則、ネストされたオブジェクトの処理。
references/build-plan-format.md	フェーズ 3 — 計画テンプレート。
references/validation-gates.md	フェーズ 5 — RUN 手順を含む、ハードゲート／警告ゲートの全テーブル。
examples/action-name-source-prompt.md	フェーズ 3 — 呼び出し可能なアクション API 名からのウォークスルー（推奨）。
examples/apex-invocable-source-prompt.md	フェーズ 3 — Apex Invocable クラスからのウォークスルー（フォールバック）。
examples/pasted-tool-output-prompt.md	フェーズ 3 — 貼り付けたツール出力サンプルからのウォークスルー（フォールバック）。
examples/nested-object-single-source-prompt.md	フェーズ 3 — Apex クラス参照の単一ペイロードフィールド。
examples/nested-object-list-source-prompt.md	フェーズ 3 — トップレベルのリストとラッパー内のリスト。