@salesforce/afv-skills 1.37.0 → 1.38.0

package/skills/service-itsm-incident-priority-configure/examples/seed-full-matrix.md

@@ -0,0 +1,52 @@
+# Seeding a Full Matrix
+
+Seed all cells at once with the conventional Impact × Urgency mapping. With the sf-CLI Tooling API path, each cell is its own POST — there is no server-side "replace whole matrix" endpoint. Compose the plan first, confirm with the user, then dispatch one POST per cell.
+
+## Pre-requisites
+
+1. Fetch the entity's active picklist values — see `../references/sf-cli-invocation.md` § Picklist extraction.
+2. Read the current matrix rows via Tooling SOQL. If the matrix is non-empty and the user asked to *seed*, ask whether they want to **replace** (delete existing rows first) or **augment** (add only missing cells) — do not seed blindly on top of existing rows.
+3. Confirm the conventional mapping below uses only values in the fetched picklists. If the org has customized picklists, adjust the plan before dispatch — do not silently coerce.
+
+## Conventional mapping (defaults only)
+
+```text
+Impact ↓ / Urgency →   High       Medium     Low
+High                    Critical   High       Moderate
+Medium                  High       Moderate   Low
+Low                     Moderate   Low        Low
+```
+
+Treat as a starting point; customers often grow to 4–5 levels per axis and add `Trivial` / `Emergency`. Confirm the resulting priorities with the user before dispatch.
+
+## Dispatch — one POST per row
+
+Replace `<alias>` with the user's target-org alias. Pick starting `<unique>` as `max(current DeveloperName suffix) + 1`, incrementing for each row.
+
+```bash
+# One row per POST — repeat for each of the nine cells.
+# Pass each body inline with --body '{...}'; sf api request rest also accepts
+# --body @file, but inline keeps the payload in the skill's control.
+sf api request rest \
+  "/services/data/v67.0/tooling/sobjects/ServiceOpPriorityConfig" \
+  --method POST \
+  --header "Content-Type:application/json" \
+  --body '{"ReferenceObject": "Incident", "Impact": "High", "Urgency": "High", "Priority": "Critical", "DeveloperName": "ServiceOpPriorityConfigIncidentSeed0", "MasterLabel": "ServiceOpPriorityConfigIncidentSeed0"}' \
+  --target-org <alias>
+
+# Repeat for rows 1–8 with the mapping above (increment the Seed<N> suffix).
+```
+
+Each POST returns `201 {"id": "<Id>", "success": true}`. If any POST returns a non-2xx, halt and surface the raw response — do not continue seeding partially.
+
+For a scripted seed, iterate the mapping array in the caller's language of choice (bash + `jq`, node, etc.). Every row must be validated against the Phase-1 picklists before dispatch — the Tooling REST endpoint accepts garbage values silently.
+
+## Replace vs. augment
+
+The Tooling API path is not atomic across rows. Two choices:
+
+**Augment (recommended):** For each conventional row, check the Phase-2 snapshot. Only POST rows whose `(Impact, Urgency)` coordinate is not already present. Existing rows keep their current Priority. The server does NOT enforce uniqueness on `(ReferenceObject, Urgency, Impact)`, so a POST on an already-present coordinate silently persists as a duplicate row — dedup is client-side only.
+
+**Replace:** First `sf data delete record --sobject ServiceOpPriorityConfig --use-tooling-api --record-id <Id>` for every existing row, then POST the conventional set. Between the delete and the last POST the matrix is *partially populated* — the runtime priority derivation will use whatever rows are present at each moment. Warn the user before choosing replace.
+
+Do not seed blindly on an entity with existing rows — surface the current state and confirm the intended semantics (replace vs. augment) with the user before Phase 4.

package/skills/service-itsm-incident-priority-configure/references/sf-cli-invocation.md

@@ -0,0 +1,264 @@
+# sf CLI invocation reference — service-itsm-incident-priority-configure
+
+This skill invokes every read and write through the **`sf` CLI**. Two transports are used:
+
+- `sf api request rest` — direct authenticated REST call against the org.
+- `sf data query --use-tooling-api` / `sf data delete record --use-tooling-api` — Tooling API convenience wrappers with better parsing than raw REST.
+- `sf project retrieve start` + `sf project deploy start` — for the `StandardValueSet` metadata that carries the default fallback priority.
+
+Every invocation below was verified 200 (or `Succeeded` for the metadata deploy) against `orgfarm-afdcaf38b6` on 2026-08-04. Path prefixes are load-bearing; do not strip `/services/data/v67.0/` or `/services/data/v67.0/tooling/`.
+
+## Authentication
+
+`sf` mints the bearer token from the CLI's authenticated org — the skill never handles tokens. Confirm the target org first:
+
+```bash
+sf org list
+sf org display --target-org <alias>
+```
+
+If the org is not `Connected`, run `sf org login web --alias <alias>` (or the JWT equivalent) and re-verify. Every command below takes `--target-org <alias>`.
+
+## Response envelope
+
+`sf api request rest` outputs the raw HTTP body (append `--include` to see the status line + headers). Tooling REST GETs return standard `{records: [...], size: N, totalSize: N, done: true, ...}`. PATCH on the two Setup Connect API prefs returns `{"isPreferenceEnabled": <bool>}` — the new state is echoed, so no re-read is needed.
+
+`sf data query` normalizes Tooling SOQL results into a table by default; add `--json` for a machine-parseable envelope.
+
+---
+
+## Routes
+
+### 1. Preflight — Incident describe (`sf api request rest`)
+
+```bash
+sf api request rest \
+  "/services/data/v67.0/sobjects/Incident/describe" \
+  --method GET \
+  --target-org <alias>
+```
+
+**Expected:** HTTP 200. Body carries the entity schema. Extract active picklist values for `Impact`, `Urgency`, `Priority` from the `fields[]` array — each field has `picklistValues[]` and each entry has `value` (API name), `label`, and `active` (only `true` counts). Use `value`, not `label` — customers rename labels but the server stores API values.
+
+If the describe response is very large (>1MB), dispatch a subagent (haiku tier) to pull just the three picklists.
+
+If the response is a `404 NOT_FOUND`, Incident Management is not enabled on the org. Direct the user to enable it first (use the `service-itsm-incident-mgmt-configure` skill).
+
+### 2. Matrix enable flag — `IncPriorityMatrixEnabled`
+
+**Read:**
+
+```bash
+sf api request rest \
+  "/services/data/v67.0/setup/org/preferences/IncPriorityMatrixEnabled" \
+  --method GET \
+  --target-org <alias>
+```
+
+Response: `{"isPreferenceEnabled": <bool>}` — 200.
+
+**Write:**
+
+```bash
+sf api request rest \
+  "/services/data/v67.0/setup/org/preferences/IncPriorityMatrixEnabled" \
+  --method PATCH \
+  --header "Content-Type:application/json" \
+  --body '{"desiredState": true}' \
+  --target-org <alias>
+# use '{"desiredState": false}' to disable
+```
+
+Response: `{"isPreferenceEnabled": <bool>}` — 200. **The response echoes the new state**, so no re-read is required.
+
+Disabling stops the server from deriving Priority on future Incident writes. Matrix rows and the default priority are **not** cleared; re-enabling restores derivation instantly. Existing Incidents keep their stamped priority.
+
+### 3. Manual override — `IncPriorityOverrideEnabled`
+
+Same shape as `IncPriorityMatrixEnabled` — same URL path except the pref name changes. Read/write via `sf api request rest`, same body shape, same response.
+
+The override flag controls whether users can override the derived priority on an individual Incident record. Flipping it does **not** touch matrix rows or the default priority.
+
+### 4. Matrix rows — read
+
+```bash
+sf data query \
+  --use-tooling-api \
+  --target-org <alias> \
+  --query "SELECT Id, DeveloperName, ReferenceObject, Urgency, Impact, Priority FROM ServiceOpPriorityConfig WHERE ReferenceObject = 'Incident'"
+```
+
+Zero to `|Impact| × |Urgency|` rows returned. Row keys are PascalCase (`Id`, `DeveloperName`, `ReferenceObject`, `Urgency`, `Impact`, `Priority`) — these are Tooling SObject field names, not the lowercase JSON keys the Aura controller used. `DeveloperName` is included so the add step can derive a fresh unique suffix from existing rows.
+
+For programmatic scripts, add `--json` and parse `result.records[]`.
+
+### 5. Matrix rows — add
+
+```bash
+sf api request rest \
+  "/services/data/v67.0/tooling/sobjects/ServiceOpPriorityConfig" \
+  --method POST \
+  --header "Content-Type:application/json" \
+  --body '{"ReferenceObject": "Incident", "Urgency": "<one of the fetched Urgency values>", "Impact": "<one of the fetched Impact values>", "Priority": "<one of the fetched Priority values>", "DeveloperName": "ServiceOpPriorityConfigIncident<unique-suffix>", "MasterLabel": "ServiceOpPriorityConfigIncident<same-suffix>"}' \
+  --target-org <alias>
+```
+
+Pass the body inline with `--body '{...}'`. `sf api request rest` accepts either inline JSON or `--body @file`; inline keeps the payload in the skill's control and avoids writing to a path outside the project.
+
+Response: `{"id": "<Id>", "success": true, "errors": [], "warnings": [], "infos": []}` — 201.
+
+Suffix pattern: pattern-match the existing rows' `DeveloperName` values from the Phase-2 read and pick a fresh integer that isn't already used. `DeveloperName` uniqueness is enforced by the Tooling API.
+
+**Important:** The Tooling REST endpoint does NOT enforce picklist validation on `Urgency`, `Impact`, `Priority`. Garbage values are accepted at the wire level but the runtime matrix evaluator refuses to use them. Validate every value against the Phase-1 picklist values before dispatch.
+
+**Duplicates:** the server does NOT enforce `(ReferenceObject, Urgency, Impact)` uniqueness — a second POST on the same coordinate is accepted as a separate row (verified 2026-08-04 on `itsm-eval-org`: two rows with identical `(Incident, Medium, High)` both persisted with distinct `Id`s). Client-side dedup against the Phase-2 snapshot is the ONLY guard against duplicate matrix cells; if you skip it, the runtime picks one of the duplicates non-deterministically.
+
+**ReferenceObject:** the server accepts any string for `ReferenceObject` (verified: a `Problem` row inserted successfully). `ServiceOpPriorityConfig` is the shared SObject for Incident / Problem / ChangeRequest matrices. Scope to `Incident` is skill-enforced only — refuse any other value client-side.
+
+### 6. Matrix rows — change
+
+```bash
+sf api request rest \
+  "/services/data/v67.0/tooling/sobjects/ServiceOpPriorityConfig/<Id>" \
+  --method PATCH \
+  --header "Content-Type:application/json" \
+  --body '{"Priority": "<new value>"}' \
+  --target-org <alias>
+```
+
+Response: 204 No Content. Look up `<Id>` from the Phase-2 SOQL results by matching `(ReferenceObject=Incident, Urgency, Impact)`.
+
+**Duplicate coordinates:** if more than one Phase-2 row matches the coordinate (the server does not enforce uniqueness), do NOT dispatch the PATCH — the choice of `<Id>` would be non-deterministic. Report all matching rows (`Id`, `DeveloperName`, current `Priority`) and require the user to name the exact `Id` to change or approve a consolidation plan (delete the extras, then change the survivor).
+
+Validate the new Priority against the Phase-1 picklist values.
+
+### 7. Matrix rows — remove
+
+```bash
+sf data delete record \
+  --sobject ServiceOpPriorityConfig \
+  --record-id <Id> \
+  --use-tooling-api \
+  --target-org <alias>
+```
+
+Response: `Successfully deleted record: <Id>`. Look up `<Id>` from the Phase-2 SOQL results by matching `(ReferenceObject=Incident, Urgency, Impact)`.
+
+**Duplicate coordinates:** if more than one Phase-2 row matches the coordinate, do NOT dispatch — deleting an arbitrary duplicate leaves the matrix non-deterministic. Report all matching rows (`Id`, `DeveloperName`, current `Priority`) and require the user to name the exact `Id`(s) to delete or explicitly confirm "delete all rows at this coordinate".
+
+**Note:** `sf api request rest ... --method DELETE` on a Tooling SObject currently fails with `SfError: No 'mode' found in 'body' entry` in `sf` CLI 2.143. Use `sf data delete record` instead.
+
+### 8. Default fallback priority — read
+
+```bash
+sf api request rest \
+  "/services/data/v67.0/tooling/query/?q=SELECT+Id,MasterLabel,Metadata+FROM+StandardValueSet+WHERE+MasterLabel='IncidentPriority'" \
+  --method GET \
+  --target-org <alias>
+```
+
+Response: 200 with `records[0].Metadata.standardValue[]`. Find the entry with `"default": true` — its `valueName` is the current fallback priority. Every other entry has `"default": false`.
+
+### 9. Default fallback priority — write
+
+Editing `default: true` on a `StandardValueSet` is a metadata operation — the Tooling REST PATCH on `StandardValueSet/<Id>` returns `FIELD_INTEGRITY_EXCEPTION: Unable to load specified entity`. The canonical `sf` CLI path is metadata deploy.
+
+```bash
+# Prepare a scratch project (only needed once per session).
+# The force-app/main/default/ path is dictated by packageDirectories[0].path in
+# sfdx-project.json below — sf project retrieve start writes the metadata there
+# by convention, not by user choice.
+WORKDIR=$(mktemp -d)
+mkdir -p "$WORKDIR/force-app/main/default/standardValueSets"
+cat > "$WORKDIR/sfdx-project.json" <<'EOF'
+{
+  "packageDirectories": [{"path":"force-app","default":true}],
+  "namespace": "",
+  "sfdcLoginUrl": "https://test.salesforce.com",
+  "sourceApiVersion": "67.0"
+}
+EOF
+
+# Step 1: retrieve current StandardValueSet
+cd "$WORKDIR" && sf project retrieve start \
+  --metadata "StandardValueSet:IncidentPriority" \
+  --target-org <alias>
+
+# Step 2: edit the XML to set <default>true</default> on the new default
+#         and <default>false</default> on every other value.
+
+# Step 3: deploy the modified file
+sf project deploy start \
+  --metadata "StandardValueSet:IncidentPriority" \
+  --target-org <alias> \
+  --wait 10
+```
+
+**Expected:** `Status: Succeeded` in the deploy output. On failure, report the raw deploy output verbatim.
+
+The XML shape is:
+
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<StandardValueSet xmlns="http://soap.sforce.com/2006/04/metadata">
+    <sorted>false</sorted>
+    <standardValue>
+        <fullName>Critical</fullName>
+        <default>false</default>
+        <label>Critical</label>
+    </standardValue>
+    <standardValue>
+        <fullName>High</fullName>
+        <default>true</default>
+        <label>High</label>
+    </standardValue>
+    <!-- ... one <standardValue> block per active picklist value ... -->
+</StandardValueSet>
+```
+
+Exactly one `<default>true</default>` should be present at deploy time.
+
+---
+
+## Idempotency contract
+
+| Concern | Match rule (skip the write when …) |
+|---------|-------------------------------------|
+| `IncPriorityMatrixEnabled` | Phase-2 `isPreferenceEnabled` already equals the requested boolean |
+| `IncPriorityOverrideEnabled` | Phase-2 `isPreferenceEnabled` already equals the requested boolean |
+| Add a cell | A Phase-2 row already matches `(ReferenceObject, Urgency, Impact)` — even if its Priority differs (surface the mismatch and ask; add is not a change) |
+| Change a cell | The Phase-2 row's `Priority` already equals the requested value |
+| Remove a cell | No Phase-2 row matches `(ReferenceObject, Urgency, Impact)` |
+| Default fallback priority | The Phase-2 `default: true` entry's `valueName` already equals the requested value |
+
+When idempotent, report `ALREADY-<state>` and skip Phase 4 entirely.
+
+---
+
+## Picklist extraction
+
+From the Phase-1 Incident describe response, iterate `fields[]`:
+
+- Look up each field by exact `name` (`Impact`, `Urgency`, `Priority`).
+- Keep only `picklistValues[]` entries with `active == true`.
+- Use `value` (API name), not `label` — the server stores API values on `ServiceOpPriorityConfig`.
+
+If the describe response is very large, dispatch a subagent (haiku tier) to extract just the three picklists.
+
+Every `Impact`, `Urgency`, `Priority` in an add or change payload — including the default value in the `StandardValueSet` deploy — must be in the fetched active set. Never hardcode `High/Medium/Low` or `Critical/High/Moderate/Low`; customers rename, add, or remove values.
+
+For an uncustomized org the defaults are `High/Medium/Low` on `Impact` and `Urgency`, and `Critical/High/Moderate/Low` on `Priority` — treat as examples, not guarantees.
+
+---
+
+## Gotchas
+
+| Issue | Detail |
+|-------|--------|
+| Tooling REST accepts garbage picklist values | The wire-level POST/PATCH does NOT validate `Urgency` / `Impact` / `Priority` against the picklist. Runtime matrix evaluation ignores garbage rows. Always validate client-side before dispatch. |
+| Duplicate `(ReferenceObject, Urgency, Impact)` rows | Accepted silently at the wire level — the server does NOT enforce uniqueness. Both rows persist and the runtime picks one non-deterministically. Deduplicate against the Phase-2 snapshot before POST; this check is the only guard. |
+| `ReferenceObject` accepts any string | The `ServiceOpPriorityConfig` SObject is shared with `Problem` and `ChangeRequest` matrices; the server accepts any value in `ReferenceObject`. Scope to `Incident` is skill-enforced only — refuse other values client-side. |
+| `sf api request rest ... --method DELETE` on Tooling | Fails with `SfError: No 'mode' found in 'body' entry` (sf CLI 2.143). Use `sf data delete record --use-tooling-api` instead. |
+| `/headless/invoke/service/service-itsm/...` returns 404 through `sf api request rest` | Those routes are Aura-dispatcher only; not addressable via the REST API host. Use the Tooling SObject and Setup Connect API prefs instead — that's what this skill does. |
+| Direct PATCH on `StandardValueSet/<Id>` via Tooling REST | Returns `FIELD_INTEGRITY_EXCEPTION: Unable to load specified entity`. Metadata deploy is the canonical path for picklist defaults. |
+| Existing Incidents' Priority | Not re-derived on matrix change. New writes use the new matrix; the stamped Priority on existing Incident records stays put. |

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

@@ -1,191 +0,0 @@
-# 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-policy-rule-generate/references/fixtures-index.md

@@ -1,29 +0,0 @@
-# Fixtures Index
-
-> **For human maintainers only.** This index requires a checkout of `enforce-o-matic-impl`. The agent should rely on [`templates.md`](templates.md), which reproduces the relevant XML shapes inline.
-
-Quick lookup from "what I need" to "fixture that already does it".
-
-All fixtures are under `enforce-o-matic-impl/test/func/filemetadata/<name>/`.
-
-| If you need… | Fixture |
-|---|---|
-| Bare permit rule, no conditions | `baseSteelthread`, `steelthreadPayload` |
-| Custom conjunction `(AND 1 2)` over UNLESS | `conjunctionExpressionSteelthread` |
-| Tag check | `conditionTagValidSteelthread`, `conditionCustomTagValidDataMaskingSteelthread` |
-| Classification check | `conditionClassificationValidClauseSteelthread`, `conditionClassificationValidDataMaskingSteelthread` |
-| Dataspace / session dataspace | `conditionDataspaceValidSteelthread`, `conditionSessionDataspaceValidSteelthread` |
-| Custom permission gate | `conditionAssignedPermPathValidSteelthread` |
-| Plain RLS (record field = user ID) | `conditionRLSValidSteelthread` (1st condition), `conditionStandardIdRLSValidSteelthread` |
-| RLS via PROJECTION join | `conditionRLSValidSteelthread` (2nd condition) |
-| Scalar / plural SOQL principal (out-of-contract) | `conditionScalarAttributeValidSteelThread`, `conditionPluralAttributeValidSteelthread` |
-| Hierarchy traversal | `conditionWithHierarchy` |
-| Field masking transform | `conditionClassificationValidDataMaskingSteelthread`, `conditionInvalidDataMaskingSteelthread` (negative) |
-| Field-scoped resource domain | `resourceDomainWithField` |
-| Core standard object policy (Case) | `coreObjectCaseWithPolicy` (persistence-layer only; not a working IDENTIFIED_RECORD shape — see §8.4 of policy.md) |
-| Extended steelthread (set referenced from sibling package) | `extendedSteelthread` |
-| Negative: missing operator | `conditionMissingOperatorSteelthread` |
-| Negative: missing path | `conditionMissingPathSteelthread` |
-| Negative: invalid context path | `conditionInvalidContextPathSteelthread` |
-| Negative: invalid data masking shape | `conditionInvalidDataMaskingSteelthread` |
-| Negative: invalid payload | `invalidPayload` |