@salesforce/afv-skills 1.33.0 → 1.35.0

package/skills/platform-mcp-tool-widget-coordinate/examples/action-name-source-prompt.md

@@ -0,0 +1,74 @@
+# Example: Invocable action name source (preferred)
+
+A complete walkthrough when the user gives only the **invocable action API name** and the action is deployed to a reachable org (`source = action`). No `.cls` parsing — the Actions REST API describes the typed outputs directly.
+
+## The prompt
+
+> My custom MCP server has a GetAccountSummary tool backed by the `GetAccountSummaryTest` invocable action in my org. Build a widget that renders its output as a rich account card.
+
+## Phase 1 — Input selection
+
+- Source: `action` (prompt gives an action API name; an authenticated org is available).
+- Tool API name: `getAccountSummary` (camelCase of the tool / action label).
+- Action API name: `GetAccountSummaryTest` (the Apex class declaring `@InvocableMethod`).
+
+## Phase 2 — Payload discovery
+
+Read `references/mcp-tool-output-discovery.md`, then describe the action:
+
+```bash
+sf api request rest '/services/data/v63.0/actions/custom/apex/GetAccountSummaryTest' -o myOrg
+```
+
+Read the `outputs` array (ignore `inputs` — that is `accountId`, the tool input). Map each `type`:
+
+| output `name` | Actions API `type` | CLT `lightning:type` |
+|---|---|---|
+| status | STRING | `lightning__textType` |
+| message | STRING | `lightning__textType` |
+| accountId | ID | `lightning__textType` |
+| accountName | STRING | `lightning__textType` |
+| accountDescription | STRING | `lightning__textType` |
+| accountIndustry | STRING | `lightning__textType` |
+| accountPhone | STRING | `lightning__textType` |
+| accountWebsite | STRING | `lightning__textType` |
+| contactCount | INTEGER | `lightning__integerType` |
+| opportunityCount | INTEGER | `lightning__integerType` |
+| largestOpportunityId | ID | `lightning__textType` |
+| largestOpportunityName | STRING | `lightning__textType` |
+| largestOpportunityAmount | DOUBLE | `lightning__numberType` |
+| totalOpportunityAmount | DOUBLE | `lightning__numberType` |
+
+`payloadFields` = the 14 rows above — identical to what the `apex` source would enumerate, but resolved from the live org without parsing source or filtering the request/helper classes.
+
+> If any output had `maxOccurs > 1`, it would be a list — flag it in the plan (beta renders a single response).
+
+## Phase 3 — Build plan (abridged)
+
+```text
+MCP Tool Widget Build Plan: getAccountSummaryWidget
+
+PLAN: Render the GetAccountSummary MCP tool output as an account-summary card.
+
+TOOL / SOURCE:
+  Tool API name: getAccountSummary
+  Payload source: action: Actions REST describe of GetAccountSummaryTest
+
+LIGHTNING TYPES:
+  Response CLT:  getAccountSummaryResponse
+  Envelope CLT: getAccountSummary
+    Renderer (default, bundle root): .../lightningTypes/getAccountSummary/renderer.json
+    Envelope: actionName (text), isSuccess (boolean), outputValues (c__getAccountSummaryResponse)
+
+WIDGET: getAccountSummaryWidget
+  Renderer binding: each attribute → {!$attrs.outputValues.<field>}
+  Properties omitted: status, message
+
+GENERATION ORDER: response CLT → widget → envelope CLT
+```
+
+Proceed unless the next reply pushes back.
+
+## Phases 4–5
+
+Generation and validation are identical to the `apex` walkthrough (`apex-invocable-source-prompt.md`), since both produce the same `payloadFields`. In `field-trace`, `INVOCABLE_FIELDS` comes from `jq -r '.outputs[].name'` on the describe rather than a `grep` of the `.cls`.

package/skills/platform-mcp-tool-widget-coordinate/examples/apex-invocable-source-prompt.md

@@ -0,0 +1,90 @@
+# Example: Apex Invocable source
+
+A complete walkthrough of the flow when the payload source is an Apex `@InvocableMethod` class that already exists in the project (`source = apex`). This is the fallback source — when the action is deployed to a reachable org, prefer `action` (describe it by name via the Actions REST API; see `action-name-source-prompt.md`). Use `apex` when no org is reachable or the describe 404s.
+
+## The prompt
+
+> I have an MCP server tool backed by the `GetAccountSummaryTest` Apex invocable action. Build a widget that renders its output so the account summary shows up as a rich card.
+
+## Phase 1 — Input selection
+
+- Source: `apex` (the prompt names an Apex Invocable class).
+- Tool API name: `getAccountSummary` (from the class / invocable label `Get Account Summary`).
+
+## Phase 2 — Payload discovery
+
+Read `references/mcp-tool-output-discovery.md`, then locate `.../classes/GetAccountSummaryTest.cls`.
+
+The invocable method:
+
+```apex
+@InvocableMethod(label='Get Account Summary')
+global static List<GetAccountSummaryResponse> getAccountSummary(
+    List<GetAccountSummaryRequest> requests
+) { ... }
+```
+
+- Response class = `GetAccountSummaryResponse` (the `List<...>` element type) → **payload source**.
+- Request class = `GetAccountSummaryRequest` → excluded (tool input).
+- `private class OpportunityMetrics` → excluded (internal helper, not part of the invocable schema).
+
+Enumerate `@InvocableVariable` fields on `GetAccountSummaryResponse` and map to CLT types:
+
+| Field | Apex type | CLT `lightning:type` |
+|---|---|---|
+| status | String | `lightning__textType` |
+| message | String | `lightning__textType` |
+| accountId | Id | `lightning__textType` |
+| accountName | String | `lightning__textType` |
+| accountDescription | String | `lightning__textType` |
+| accountIndustry | String | `lightning__textType` |
+| accountPhone | String | `lightning__textType` |
+| accountWebsite | String | `lightning__textType` |
+| contactCount | Integer | `lightning__integerType` |
+| opportunityCount | Integer | `lightning__integerType` |
+| largestOpportunityId | Id | `lightning__textType` |
+| largestOpportunityName | String | `lightning__textType` |
+| largestOpportunityAmount | Decimal | `lightning__numberType` |
+| totalOpportunityAmount | Decimal | `lightning__numberType` |
+
+`payloadFields` = the 14 rows above.
+
+## Phase 3 — Build plan (abridged)
+
+```text
+MCP Tool Widget Build Plan: getAccountSummaryWidget
+
+PLAN: Render the GetAccountSummary MCP tool output as an account-summary card.
+
+TOOL / SOURCE:
+  Tool API name: getAccountSummary
+  Payload source: Apex Invocable class GetAccountSummaryTest
+  Response class FQN: GetAccountSummaryTest.GetAccountSummaryResponse
+
+LIGHTNING TYPES:
+  Response CLT:  getAccountSummaryResponse   (14 payload properties)
+  Envelope CLT: getAccountSummary
+    Renderer (default, bundle root): .../lightningTypes/getAccountSummary/renderer.json
+    Envelope: actionName (text), isSuccess (boolean), outputValues (c__getAccountSummaryResponse)
+
+WIDGET: getAccountSummaryWidget
+  Renderer binding: each attribute → {!$attrs.outputValues.<field>}
+  Properties omitted: status, message (envelope-status text, not rendered on the card)
+
+GENERATION ORDER: response CLT → widget → envelope CLT
+```
+
+Proceed unless the next reply pushes back.
+
+## Phase 4 — Generation order
+
+1. Response CLT `getAccountSummaryResponse` — `lightning__objectType`, all 14 `payloadFields` (1:1 with the response class's `@InvocableVariable` fields — the response CLT always models the complete response, including `status`/`message`).
+2. Envelope CLT `getAccountSummary` — `actionName`, `isSuccess`, `outputValues` → `c__getAccountSummaryResponse`.
+3. Widget `getAccountSummaryWidget` — flat schema over the 12 rendered payload fields (14 minus the two `Properties omitted:` status fields); body binds `{!$attrs.accountName}` etc.
+4. Default renderer at `lightningTypes/getAccountSummary/renderer.json` — `definition: @widget/c/getAccountSummaryWidget`, each attribute `{!$attrs.outputValues.<field>}`.
+
+## Phase 5 — Validation
+
+- `clt-reference-integrity`: envelope `outputValues` → `c__getAccountSummaryResponse`, response CLT exists, no `$schema`/`items` → **pass**.
+- `renderer-wires-widget`: bundle-root renderer present, definition `@widget/c/getAccountSummaryWidget`, every widget prop bound as `{!$attrs.outputValues.<prop>}` → **pass**.
+- `field-trace`: INVENTED empty; OMITTED = `status, message` (both in `Properties omitted:`) → **pass**.

package/skills/platform-mcp-tool-widget-coordinate/examples/nested-object-source-prompt.md

@@ -0,0 +1,191 @@
+# Example: Nested-object payload field (Apex-class-typed response field)
+
+A complete walkthrough of the flow when one `@InvocableVariable` field on the response class is
+itself **another Apex class**, not a primitive (`source = apex`, nested-object branch). This is the
+second, additive payload shape alongside the flat-primitive shape in `apex-invocable-source-prompt.md`
+— read `references/mcp-tool-output-discovery.md` ("Nested-object payload fields") and
+`references/two-clt-modeling.md` ("Nested-object payload fields (a second, additive case)") first.
+
+## The prompt
+
+> I have an MCP server tool backed by the `GetFlightDetailsAction` Apex invocable action. Build a
+> widget that renders its output as a flight details card.
+
+## Phase 1 — Input selection
+
+- Source: `apex` (the prompt names an Apex Invocable class; no org describe needed for this walkthrough).
+- Tool API name: `getFlightDetails` (from the class name `GetFlightDetailsAction`, stripping the
+  trailing `Action` suffix and lower-camelCasing — see the naming convention in
+  `references/two-clt-modeling.md`).
+
+## Phase 2 — Payload discovery
+
+Read `references/mcp-tool-output-discovery.md`, then locate `.../classes/GetFlightDetailsAction.cls`.
+
+The invocable method:
+
+```apex
+@InvocableMethod(label='Get Flight Details' description='Returns flight details based on input ID, Origin, and Destination')
+public static List<FlightDetailsResponse> getFlightDetails(List<FlightDetailsRequest> requests) { ... }
+
+public class FlightDetailsResponse {
+    @InvocableVariable(label='Flight Details')
+    public SearchFlightsAction.Flight flightInfo;
+}
+```
+
+- Response class = `FlightDetailsResponse` (the `List<...>` element type) → **payload source**.
+- Request class = `FlightDetailsRequest` → excluded (tool input).
+- The single `@InvocableVariable` field, `flightInfo`, is declared `SearchFlightsAction.Flight` —
+  **another Apex class**, not `String`/`Integer`/etc. This is the nested-object branch: it does not
+  go in the primitive Apex→CLT mapping table.
+
+Enumerate the referenced class (`SearchFlightsAction.Flight`) for its own `@InvocableVariable`
+leaf fields — these become the widget's flat properties:
+
+```apex
+public class Flight {
+    @InvocableVariable public String flightId;
+    @InvocableVariable public String origin;
+    @InvocableVariable public String destination;
+    @InvocableVariable public String departureTime;
+    @InvocableVariable public String arrivalTime;
+    @InvocableVariable public Long price;
+}
+```
+
+| Leaf field | Apex type | CLT / widget `lightning:type` |
+|---|---|---|
+| flightId | String | `lightning__textType` |
+| origin | String | `lightning__textType` |
+| destination | String | `lightning__textType` |
+| departureTime | String | `lightning__textType` |
+| arrivalTime | String | `lightning__textType` |
+| price | Long | `lightning__numberType` (widget uses `lightning__numberType` for all numerics; the response CLT would use `lightning__integerType` if this leaf were typed directly on the response CLT — but it isn't, since it's flattened through `@apexClassType`, see below) |
+
+`payloadFields` (top-level) = 1 field: `flightInfo`, typed as an Apex class → nested-object branch.
+`payloadFields` (flattened, for the widget) = the 6 leaf rows above.
+
+## Phase 3 — Build plan (abridged)
+
+```text
+MCP Tool Widget Build Plan: getFlightDetailsWidget
+
+PLAN: Render the GetFlightDetails MCP tool output as a flight-details card.
+
+TOOL / SOURCE:
+  Tool API name: getFlightDetails
+  Payload source: Apex Invocable class GetFlightDetailsAction
+  Response class FQN: GetFlightDetailsAction.FlightDetailsResponse
+
+LIGHTNING TYPES:
+  Response CLT:  getFlightDetailsResponse
+    Properties: flightInfo → "@apexClassType/c__SearchFlightsAction$Flight"   # nested-object field, NOT {"type":"object"}
+  Envelope CLT: getFlightDetails
+    Renderer (default, bundle root): .../lightningTypes/getFlightDetails/renderer.json
+    Envelope: actionName (text), isSuccess (boolean), outputValues (c__getFlightDetailsResponse)
+
+WIDGET: getFlightDetailsWidget
+  Schema: flattened to flightInfo's 6 leaf fields (flightId, origin, destination, departureTime, arrivalTime, price)
+  Renderer binding: each attribute → {!$attrs.outputValues.flightInfo.<leaf>}   # two levels deep, not one
+  Properties omitted: none
+
+GENERATION ORDER: response CLT → widget → envelope CLT
+```
+
+Proceed unless the next reply pushes back.
+
+## Phase 4 — Generation order
+
+1. **Response CLT** `getFlightDetailsResponse`:
+
+   ```json
+   {
+     "title": "Get Flight Details Response",
+     "description": "Response fields from the GetFlightDetailsAction invocable-action (FlightDetailsResponse)",
+     "type": "object",
+     "lightning:type": "lightning__objectType",
+     "lightning:tags": ["mcp"],
+     "unevaluatedProperties": false,
+     "properties": {
+       "flightInfo": {
+         "title": "Flight Info",
+         "lightning:type": "@apexClassType/c__SearchFlightsAction$Flight"
+       }
+     }
+   }
+   ```
+
+2. **Widget** `getFlightDetailsWidget` — flat schema over the 6 leaf fields (not the single
+   `flightInfo` field); body binds `{!$attrs.flightId}`, `{!$attrs.origin}`, etc.
+
+3. **Envelope CLT** `getFlightDetails`:
+
+   ```json
+   {
+     "title": "Get Flight Details",
+     "description": "Invocable-action result envelope for the GetFlightDetailsAction MCP tool",
+     "type": "object",
+     "lightning:type": "lightning__objectType",
+     "lightning:tags": ["mcp"],
+     "unevaluatedProperties": false,
+     "properties": {
+       "actionName": { "title": "Action Name", "lightning:type": "lightning__textType" },
+       "isSuccess":  { "title": "Is Success",  "lightning:type": "lightning__booleanType" },
+       "outputValues": { "title": "Output Values", "lightning:type": "c__getFlightDetailsResponse" }
+     }
+   }
+   ```
+
+4. **Default renderer** at `lightningTypes/getFlightDetails/renderer.json` —
+   `definition: @widget/c/getFlightDetailsWidget`, each attribute bound two levels deep through the
+   nested object:
+
+   ```json
+   {
+     "renderer": {
+       "componentOverrides": {
+         "$": {
+           "definition": "@widget/c/getFlightDetailsWidget",
+           "attributes": {
+             "flightId":      "{!$attrs.outputValues.flightInfo.flightId}",
+             "origin":        "{!$attrs.outputValues.flightInfo.origin}",
+             "destination":   "{!$attrs.outputValues.flightInfo.destination}",
+             "departureTime": "{!$attrs.outputValues.flightInfo.departureTime}",
+             "arrivalTime":   "{!$attrs.outputValues.flightInfo.arrivalTime}",
+             "price":         "{!$attrs.outputValues.flightInfo.price}"
+           }
+         }
+       }
+     }
+   }
+   ```
+
+## Phase 5 — Validation
+
+- `clt-reference-integrity`: envelope `outputValues` → `c__getFlightDetailsResponse`,
+  response CLT exists, `flightInfo` uses `@apexClassType/c__SearchFlightsAction$Flight` (not a
+  bare `{"type":"object"}` and not an inlined `lightning__objectType`), no `$schema`/`items` →
+  **pass**.
+- `renderer-wires-widget`: bundle-root renderer present, definition `@widget/c/getFlightDetailsWidget`,
+  every widget property bound two levels deep as `{!$attrs.outputValues.flightInfo.<property>}` (not
+  one level, which would bind to an unresolvable object) → **pass**.
+- `field-trace`: INVOCABLE_FIELDS (top-level, per the gate's literal definition) = `flightInfo` —
+  a single nested-object field, not a primitive. Because it resolves to `@apexClassType/...` (see
+  `clt-reference-integrity` above), it expands to its referenced class's own leaf fields before
+  comparing against the widget: `flightId, origin, destination, departureTime, arrivalTime, price`.
+  Widget properties match this expanded leaf set exactly; INVENTED empty; OMITTED empty → **pass**.
+
+## Notes
+
+- **Why not a single-level CLT.** Typing `flightInfo` as `{"type":"object"}` on the response CLT
+  produces an opaque blob with no leaf fields — not renderable, and rejected by intent even where the
+  CLT metaschema would technically accept a generic object. The `@apexClassType/<ns>__<OuterClass>$<InnerClass>`
+  reference is what actually deploys (verified against a hand-fixed, successfully deployed bundle).
+- **This is additive, not a replacement.** A response class with only primitive `@InvocableVariable`
+  fields (the `AccountSummary`/`GetOrderStatus` examples) still uses the flat mapping tables
+  unchanged. Check each field independently — a response class can mix primitive and Apex-class-typed
+  fields.
+- **`List<ApexClass>` fields** (e.g. `SearchFlightsAction.FlightSearchResponse.availableFlights`, a
+  `List<Flight>`) are out of scope for this beta single-response flow — surface them in the build
+  plan the same way a `maxOccurs > 1` scalar is surfaced, rather than emitting a schema for them.

package/skills/platform-mcp-tool-widget-coordinate/examples/pasted-tool-output-prompt.md

@@ -0,0 +1,85 @@
+# Example: Pasted tool-output source
+
+A complete walkthrough of the flow when the payload source is a pasted MCP tool-output JSON sample and no Apex class is available (`source = sample`).
+
+## The prompt
+
+> Here's what my MCP tool returns. Build a widget for it.
+>
+> ```json
+> {
+>   "actionName": "GetOrderStatus",
+>   "isSuccess": true,
+>   "outputValues": {
+>     "orderId": "80100000ABC",
+>     "orderNumber": "ORD-4471",
+>     "status": "Shipped",
+>     "itemCount": 3,
+>     "orderTotal": 249.95,
+>     "expedited": true
+>   }
+> }
+> ```
+
+## Phase 1 — Input selection
+
+- Source: `sample` (the prompt pastes a tool-output envelope; no Apex class referenced).
+- Tool API name: `getOrderStatus` (from `actionName`).
+
+## Phase 2 — Payload discovery
+
+Read `references/mcp-tool-output-discovery.md`, then parse the `outputValues` object. Infer each `lightning:type` from the JSON value:
+
+| Field | JSON value | Inferred CLT `lightning:type` |
+|---|---|---|
+| orderId | `"80100000ABC"` (string) | `lightning__textType` |
+| orderNumber | `"ORD-4471"` (string) | `lightning__textType` |
+| status | `"Shipped"` (string) | `lightning__textType` |
+| itemCount | `3` (integer) | `lightning__integerType` |
+| orderTotal | `249.95` (fractional) | `lightning__numberType` |
+| expedited | `true` (boolean) | `lightning__booleanType` |
+
+Envelope keys confirmed against the sample: `actionName`, `isSuccess`, `outputValues`. **No extra nesting** — `outputValues.<field>` is flat, so bindings will be `{!$attrs.outputValues.<field>}`.
+
+> If the sample had nested the payload one level deeper (e.g. `outputValues.data.orderId`), the response CLT would model that `data` object and every renderer binding would be `{!$attrs.outputValues.data.<field>}`. Call this out in the plan.
+
+`payloadFields` = the 6 rows above.
+
+## Phase 3 — Build plan (abridged)
+
+```text
+MCP Tool Widget Build Plan: getOrderStatusWidget
+
+PLAN: Render the GetOrderStatus MCP tool output as an order-status card.
+
+TOOL / SOURCE:
+  Tool API name: getOrderStatus
+  Payload source: pasted tool-output sample
+
+LIGHTNING TYPES:
+  Response CLT:  getOrderStatusResponse   (6 payload properties)
+  Envelope CLT: getOrderStatus
+    Renderer (default, bundle root): .../lightningTypes/getOrderStatus/renderer.json
+    Envelope: actionName (text), isSuccess (boolean), outputValues (c__getOrderStatusResponse)
+
+WIDGET: getOrderStatusWidget
+  Renderer binding: each attribute → {!$attrs.outputValues.<field>}
+  Properties omitted: none
+
+GENERATION ORDER: response CLT → widget → envelope CLT
+```
+
+Proceed unless the next reply pushes back.
+
+## Phase 4 — Generation order
+
+1. Response CLT `getOrderStatusResponse` — `lightning__objectType`, 6 properties (numerics: `itemCount` → `lightning__integerType` in the CLT but `lightning__numberType` in the widget schema; `orderTotal` → `lightning__numberType` in both).
+2. Envelope CLT `getOrderStatus` — `actionName`, `isSuccess`, `outputValues` → `c__getOrderStatusResponse`.
+3. Widget `getOrderStatusWidget` — flat schema over the 6 payload fields; body binds `{!$attrs.orderNumber}` etc.
+4. Default renderer at `lightningTypes/getOrderStatus/renderer.json` — `definition: @widget/c/getOrderStatusWidget`, each attribute `{!$attrs.outputValues.<field>}`.
+
+## Phase 5 — Validation
+
+- `clt-reference-integrity`: envelope `outputValues` → `c__getOrderStatusResponse`, response CLT exists, no `$schema`/`items` → **pass**.
+- `renderer-wires-widget`: bundle-root renderer present, definition `@widget/c/getOrderStatusWidget`, all 6 bindings nested under `outputValues` → **pass**.
+- `field-trace`: source is a sample, so INVOCABLE_FIELDS = `outputValues` keys; INVENTED empty, OMITTED empty → **pass**.

package/skills/platform-mcp-tool-widget-coordinate/references/build-plan-format.md

@@ -0,0 +1,74 @@
+# Build Plan Format
+
+Use this template in Phase 3 to print the plan before proceeding. Fill every section. Do not abbreviate. Do not print inside a code fence the user might mistake for output — the plan is conversational.
+
+---
+
+```text
+MCP Tool Widget Build Plan: <widgetName>
+
+PLAN: <one line in developer-facing terms, e.g.:
+  "Render the GetAccountSummary MCP tool output with an account-summary widget">
+
+TOOL / SOURCE:
+  Tool API name: <toolApiName>
+  Payload source: <action: Actions REST describe of <ActionApiName> | apex: class <ClassName> | sample: pasted tool-output>
+  Response class FQN: <namespace>__<ClassName>.<ResponseClass>   # apex source only; omit for action/sample
+
+LIGHTNING TYPES (two object-based CLTs of equal standing — named for what each models, not by role; both carry root-level "lightning:tags": ["mcp"]):
+  Response CLT:
+    Name: <responseCLT>          # convention: <toolApiName>Response
+    Path: <pkgDir>/lightningTypes/<responseCLT>/schema.json
+    Properties: <field: lightning:type, ...>   # 1:1 with response @InvocableVariable fields
+  Envelope CLT:
+    Name: <toolCLT>          # convention: <toolApiName>
+    Path: <pkgDir>/lightningTypes/<toolCLT>/schema.json
+    Renderer (default, at bundle root — wires the widget): <pkgDir>/lightningTypes/<toolCLT>/renderer.json
+    Envelope properties: actionName (text), isSuccess (boolean), outputValues (c__<responseCLT>), <plus any others>
+
+WIDGET:
+  Name: <widgetName>          # convention: <toolApiName>Widget
+  Output:
+    <pkgDir>/uiWidgets/<widgetName>/<widgetName>.json
+    <pkgDir>/uiWidgets/<widgetName>/schema.json
+    <pkgDir>/uiWidgets/<widgetName>/<widgetName>.uiwidget-meta.xml
+  Schema source: derived from the response field list (name + primitive type) — a standalone contract, not tied to any Lightning Type
+  Renderer binding: each widget attribute maps to {!$attrs.outputValues.<field>}
+  Layout intent: <one-line description of the widget composition>
+  Properties omitted: <response fields the widget intentionally drops, with rationale — or "none">
+    # actionName/isSuccess never appear here — they are envelope-only and never candidates for the widget.
+    # Default omissions to declare when present in the response: isSuccess, errorMessage, status, message
+    # (operational/status indicators, not display data) — each needs its own one-line rationale, not just the field name.
+
+SUB-SKILLS THAT WILL RUN:
+  platform-custom-lightning-type-generate   (response CLT, then envelope CLT)
+  platform-widget-generate                  (widget bundle)
+  (renderer.json authored inline in the envelope CLT by this orchestrator)
+
+VALIDATIONS THAT WILL RUN AFTER GENERATION:
+  Widget bundle self-validation (run by platform-widget-generate):
+    - widget schema.json parses and has the required root keys
+    - every leaf in properties has a lightning:type
+    - every {!$attrs.X} resolves to a widget schema property
+    - <name>.uiwidget-meta.xml is well-formed, root <UiWidgetBundle>, declares <widgetType>JSON</widgetType>
+  Cross-skill checks (run by this orchestrator):
+    - clt-reference-integrity: envelope CLT outputValues → c__<responseCLT>; response CLT exists; no $schema/items
+    - renderer-wires-widget: envelope CLT renderer.json (bundle root) references the widget via @widget/c/<widgetName>,
+      binding every widget property as {!$attrs.outputValues.<property>}
+    - field-trace (advisory): print response @InvocableVariable fields and widget schema properties; print the diff.
+      Invented widget fields fail; omissions not declared above warn.
+
+GENERATION ORDER: response CLT → widget → envelope CLT (response CLT must exist before the envelope CLT references it).
+
+----------------------------------------------------------------
+Proceeding unless you push back (reply "no", "stop", "change X"). The plan above is the record of intent.
+```
+
+---
+
+## Notes for the model
+
+- If the user replies with edits or declines, revise the plan and reprint. Do not assume which sections changed.
+- Approval applies only to the plan as printed. A later request for another tool starts a new planning cycle.
+- "Properties omitted" makes intentional drops explicit — e.g. `status`, `message`, internal IDs that do not belong on the render surface.
+- If the payload source is a pasted sample that nests under `outputValues.data`, record that extra level here — it changes the response CLT and every renderer binding to `{!$attrs.outputValues.data.<field>}`.