@salesforce/afv-skills 1.65.0 → 1.65.1

package/skills/industries-catalog-process-intake-configure/SKILL.md

@@ -1,219 +0,0 @@
----
-name: industries-catalog-process-intake-configure
-description: "Use this skill when users want to cHILD of the create-unified-catalog-service-process orchestrator — one configuration pass over a service process that ALREADY EXISTS. Trigger when users mention configure, unified, catalog, service, process, intake, automation, connect, api, service-automation-connect-api."
-metadata:
-  version: "1.0"
-  accessCheck: "IndustriesEpc.orgHasUnifiedCatalog"
----
-
-# Managing Configure Unified Catalog Service Process Intake
-
-## When to Use This Skill
-
-CHILD of the create-unified-catalog-service-process orchestrator — one configuration pass over a service process that ALREADY EXISTS. Run standalone against an existing process (supply its catalogItemId), or as the phase that orchestrator routes to; for a NEW end-to-end process start at create-unified-catalog-service-process, which asks the creation fork FIRST.
-Use this when an admin wants to add or swap the intake form (request form) on a service process — e.g. "generate a Flow intake form for my order-replacement process" or "attach my existing OmniScript to this service process". DONE when a Flow or OmniScript surface is bound to the process and reads back on the verify GET with the anchor still intact. Org-gated on Unified Catalog. Two user decisions drive the branch — surface type (Flow / OmniScript) and mode (generate-new / attach-existing) — both enforced in preconditions and choice_points; step mechanics and the DETACH TRAP are in agent_guidance and step assertions.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Org must have Unified Catalog enabled.
- (check: `Unified Product Catalog enabled`)
-- HARD CONSTRAINT — the service process must ALREADY EXIST and its catalogItemId (== productId) must be known before this workflow runs. The first step (resolve-catalog-item) GETs the item to confirm it exists and is usedFor=ServiceProcess before any write; a 404 there means the id is wrong or the process was never created — the process must be created first, then re-run here with its catalogItemId.
- (check: `process_exists_with_known_catalog_item_id`)
-- HARD CONSTRAINT — a service process should have its intake ATTRIBUTES saved before a surface is generated. generate-intake-form-flow builds the surface FROM the process's saved attributes; generating against a process with no attributes yields an empty form, and a malformed attribute can make generation fail. Confirm the process has its attributes (GET the item and check sections[] is non-empty) before choosing generate-new. If generation fails on a malformed attribute, the fix is on the process's attribute definitions, not in this workflow. Attach-existing is unaffected by this — it binds a pre-built surface.
- (check: `attributes_saved_before_generate`)
-- HARD CONSTRAINT — the SURFACE TYPE (Flow vs OmniScript) MUST be elicited from the user, never defaulted. It changes which generate endpoint / list endpoint is used and the `type` sent when binding. Do NOT assume Flow.
- (check: `user_has_chosen_surface_type`)
-- HARD CONSTRAINT — the MODE (generate a new surface vs attach an existing one) MUST be elicited from the user, never defaulted. Generate-new mints a fresh surface from the saved attributes; attach-existing binds a surface the org already has. Ask which one.
- (check: `user_has_chosen_intake_mode`)
-- HARD CONSTRAINT — GENERATE-NEW is supported for Flow ONLY. An OmniScript intake surface can only be ATTACHED from an OmniScript that already exists in the org (attach-existing); there is no supported generate-new-OmniScript path in this workflow (getting OmniScript generation working requires changes in the OmniScript Builder and the Unified Catalog headless design-time experience, out of scope here). If the user chose surface-type Omniscript, the mode MUST be attach-existing — do NOT attempt to generate an OmniScript.
- (check: `omniscript_is_attach_existing_only`)
-- HARD CONSTRAINT (attach-existing only) — the surface to attach MUST be a real id taken from the matching list step (list-screen-flows for Flow, list-omniscript-records for OmniScript) for THIS org. Never guess or hand-construct a Flow/OmniScript id. List the eligible surfaces, let the user pick one, and bind that exact id as intakeForm.intakeFormId.
- (check: `attached_surface_is_a_real_listed_id`)
-- HARD CONSTRAINT (every branch — the bind runs in generate-new AND attach-existing) — binding via patchCatalogItemGet with operationType:"Update" is a FULL overwrite: it MUST re-send the item's identity fields (targetObject, name, usedFor, isActive). Omitting targetObject CLEARS the anchor (it reads back absent on the next GET, NOT reset to a default) even after it was set at create time. The bind PATCH always carries these four fields; the verify GET confirms the anchor is unchanged.
- (check: `bind_patch_resends_anchor_identity_fields`)
-- HARD CONSTRAINT — if the process ALREADY HAS a surface bound (resolve-catalog-item returned a non-empty intakeForm.intakeFormId), binding a new one REPLACES it: the old surface is unbound (and, for a just-generated surface, the previous one is left orphaned in the org). This is a destructive swap of a live request form. CONFIRM with the user before binding — show the currently-bound surface (existing_intake_form_surface / existing_intake_form_type) and ask whether to replace it. If the item has no surface bound, this is a first attach and no confirmation is needed. This applies to EVERY branch, because the replacement always happens at bind-existing-surface (which runs in both generate-new and attach-existing), never at the generate step: a generate call on an already-bound item does NOT overwrite the binding on its own — it mints an orphan surface and leaves the old binding in place; only the follow-up bind performs the swap, which is exactly why the confirmation gates the bind, in whichever mode reached it.
- (check: `replace_existing_surface_confirmed`)
-
-**Operational rules:**
-
-- MUST-DO CONTRACT (read before executing — each rule is enforced by the named precondition/step; do NOT skip because the detail is further down):
-  1. CONFIRM the process exists first — run resolve-catalog-item (GET) and capture its
-     identity fields (name, usedFor, isActive, targetObject) and current intakeForm.id.
-     A 404 means the catalogItemId is wrong; do NOT proceed.
-     [precondition: process_exists_with_known_catalog_item_id]
-  2. ELICIT BOTH decisions up front: surface type (Flow / OmniScript) and mode
-     (generate-new / attach-existing). Never default either.
-     [preconditions: user_has_chosen_surface_type, user_has_chosen_intake_mode]
-  3. GENERATE-NEW (FLOW ONLY): call generate-intake-form-flow with the process's productId
-     (== catalogItemId) to mint a Flow (type=Flow) FROM the saved attributes; it returns the
-     id but does NOT reliably attach it — you MUST then run bind-existing-surface with the
-     returned id to attach it. Confirm the process has attributes first. OmniScript has NO
-     generate-new path — use attach-existing for OmniScript.
-     [preconditions: attributes_saved_before_generate, omniscript_is_attach_existing_only]
-  4. ATTACH-EXISTING: list via the matching step (list-screen-flows — the UIAPI GraphQL
-     FlowRecord query the UI itself uses — for Flow; list-omniscript-records for
-     OmniScript), present the COMPLETE set as numbered text, let the user type their pick,
-     then bind that exact id via bind-existing-surface. For a Flow, bind the
-     node.FlowDefinition.value (300-prefix definition id), NOT the 2aF version-view id.
-     [precondition: attached_surface_is_a_real_listed_id]
-  5. The bind PATCH is a FULL overwrite — ALWAYS re-send targetObject + name + usedFor +
-     isActive, and carry the existing intakeForm.id forward, or the anchor is CLEARED
-     (reads back absent, not reset to a default) and/or a previously attached surface detaches.
-     [precondition: bind_patch_resends_anchor_identity_fields]
-  6. IF a surface is ALREADY BOUND (resolve-catalog-item.existing_intake_form_surface is
-     non-empty), binding replaces it — the old surface is unbound (generate-new also leaves
-     the freshly minted one orphaned until bind swaps it). This is a destructive swap of a
-     live request form: show the user the currently-bound surface and CONFIRM before binding.
-     First attach (no surface bound) needs no confirmation.
-     [precondition: replace_existing_surface_confirmed]
-  7. VERIFY: GET the item and confirm intakeForm.intakeFormId + intakeForm.type are the
-     chosen surface AND targetObject is unchanged. [step: verify-intake]
-- ASK MODALITY: use a structured picker for the two small bounded choices (surface type, mode). For the attach-existing surface list (Flows / OmniScripts), which is unbounded, list the COMPLETE set as numbered text (name, apiName/uniqueName, id) and let the user type their selection; PRESENT smartly — match a named target locally, list a small set in full, and narrow a large one (typed name or a recent top slice) rather than dumping every row. The Flow list is a paged GraphQL query (first:2000 + pageInfo.hasNextPage/endCursor) — page through to completeness before asking.
-TIMING: ask surface type + mode up front (they select the branch), then run only the steps that apply to the chosen branch (the rest are guarded by applies_when).
-BRANCHES (2 modes × N surface types — exactly one surface-source path runs, then a common bind):
-  - generate-new (FLOW ONLY): call generate-intake-form-flow to MINT the Flow (it returns the
-      id but does not reliably attach). OmniScript has no generate-new path.
-  - attach-existing: call the surface-specific lister and let the user pick. Flow ->
-      list-screen-flows; OmniScript -> list-omniscript-records.
-Both modes then converge on bind-existing-surface (the single attach step, runs in every branch) with the surface id + type, and end with verify-intake. EXTENDING to a new surface type (e.g. a future LWC form): add it to choice_points[surface-type].options, add its own generator + lister steps (each guarded by applies_when on the new surface-type value), and ensure bind-existing-surface.surfaceType accepts the new wire value. No change to the mode logic, the anchor handling, or verify.
-
-## Verification Checklist
-
-After every write operation, confirm the effect by re-reading state:
-
-- After `resolve-catalog-item`, `generate-intake-form-flow`, `bind-existing-surface`: call `verify-intake` (`GET /connect/service-automation/catalog/catalog-item/{catalogItemId}`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `resolve-catalog-item` | read | implemented | `GET /connect/service-automation/catalog/catalog-item/{catalogItemId}` | — |
-| `generate-intake-form-flow` | write | implemented | `POST /connect/service-automation/intake-form/generate-intake-form` | `resolve-catalog-item` |
-| `list-screen-flows` | read | implemented | `queryScreenFlows` | `resolve-catalog-item` |
-| `list-omniscript-records` | read | proposed | `GET /headless/invoke/platform/service-process-wizard-setup/get-omniscript-records` | `resolve-catalog-item` |
-| `bind-existing-surface` | write | implemented | `PATCH /connect/service-automation/catalog/catalog-item/{catalogItemId}` | `resolve-catalog-item`, `generate-intake-form-flow`, `list-screen-flows`, `list-omniscript-records` |
-| `verify-intake` | verify | implemented | `GET /connect/service-automation/catalog/catalog-item/{catalogItemId}` | `resolve-catalog-item`, `generate-intake-form-flow`, `bind-existing-surface` |
-
-### Dependency graph
-
-```mermaid
-graph TD
-  resolve_catalog_item["resolve-catalog-item (read)"]
-  generate_intake_form_flow["generate-intake-form-flow (write)"]
-  list_screen_flows["list-screen-flows (read)"]
-  list_omniscript_records["list-omniscript-records (read)"]
-  bind_existing_surface["bind-existing-surface (write)"]
-  verify_intake["verify-intake (verify)"]
-  resolve_catalog_item --> generate_intake_form_flow
-  resolve_catalog_item --> list_screen_flows
-  resolve_catalog_item --> list_omniscript_records
-  resolve_catalog_item --> bind_existing_surface
-  generate_intake_form_flow --> bind_existing_surface
-  list_screen_flows --> bind_existing_surface
-  list_omniscript_records --> bind_existing_surface
-  resolve_catalog_item --> verify_intake
-  generate_intake_form_flow --> verify_intake
-  bind_existing_surface --> verify_intake
-```
-
-### Read operations
-
-#### `resolve-catalog-item`
-
-CONFIRM + CAPTURE — GET the existing service process to prove it exists and to capture the identity fields the later bind must re-send. Fails fast (404) if the catalogItemId is wrong or the process was never created. Capture name, usedFor, isActive, targetObject (the anchor) and the current intakeForm.id (the container minted at create time) — the bind step carries these forward to avoid the DETACH TRAP.
-
-
-**Call:** `GET /connect/service-automation/catalog/catalog-item/{catalogItemId}`   — status: `implemented`
-
-**Inputs:**
-
-- `catalogItemId` *(`String`)* — The catalogItemId (== productId) of the EXISTING service process. If the user does not have it, the process must be created first before this workflow can run.
-
-#### `list-screen-flows`
-
-ATTACH-EXISTING, FLOW — list the org's active Screen Flows via UIAPI GraphQL: FlowRecord filtered to FlowType=="Screen" AND ProgressStatus=="InProgress" (InProgress is the active-version state). Present the COMPLETE set as numbered text (Name, FlowRecord_ApiName, and the bindable definition id) and let the user type their pick; page via pageInfo.endCursor (first:2000 + hasNextPage) — PRESENT smartly: if the user already NAMED the target, match it in the fetched set and show only the matches; if the set is small (≤ ~25) list it all as numbered text; if it is large, do NOT dump every row — show the most-recently-modified top slice (or ask a narrowing keyword) and invite the user to type a name to search (the full set is already fetched, so the local match stays exact). TARGETED LOOKUP: when the user has already NAMED the flow, add a label predicate to the where filter — {FlowLabel: {like: "%<name>%"}}, AND-combined with the FlowType/ProgressStatus filters above — to fetch just the matches in ONE call instead of paging the whole list; fall back to the full paged listing only when no name was given or the filtered query returns nothing. The list is org-specific — take it from this call, never a fixed list. ID TO BIND: the node.Id here is the FlowRecord (version-view) id (2aF… prefix). The id the catalog-item bind wants as intakeForm.intakeFormId is the FLOW DEFINITION id (300… prefix) — the same shape the generate path returns. Read it from node.FlowDefinition.value; for org-authored flows it is populated (a 300-prefixed FlowDefinition id). Managed-package standard flows show FlowDefinition==null and are generally not offered as custom intake surfaces; prefer flows with a non-null FlowDefinition.value.
-
-
-**Call:** `queryScreenFlows`   — status: `implemented`
-
-**Depends on:** `resolve-catalog-item`
-
-#### `list-omniscript-records`
-
-ATTACH-EXISTING, OMNISCRIPT — list the OmniScripts selectable as a service-process intake surface. Present the COMPLETE set as numbered text (name, uniqueName, type/subType, id) and let the user type their pick; PRESENT smartly — match a named target locally, list a small set in full, and narrow a large one (typed name or a recent top slice) rather than dumping every row. TARGETED LOOKUP: this controller returns the full active set with NO server-side name filter, so when the user has already NAMED the OmniScript, match it by name/uniqueName in the returned array and offer just those rows rather than making the user scroll the whole list. The chosen record's id becomes intakeForm.intakeFormId on the bind.
-
-
-**Call:** `GET /headless/invoke/platform/service-process-wizard-setup/get-omniscript-records`   — status: `proposed`
-
-**Depends on:** `resolve-catalog-item`
-
-### Write operations
-
-#### `generate-intake-form-flow`
-
-GENERATE-NEW, FLOW — mint a new Screen Flow request form from the process's saved attributes. Sends {name, description, productId, type:"Flow"}; the server builds the Flow from the item's sections/attributes and returns 201 with the new Flow definition id (300-prefix). ATTACH IS NOT GUARANTEED BY GENERATE: the mint call does NOT reliably leave the Flow bound to the item — a follow-up bind PATCH (see bind-existing-surface) is required, passing the returned 300-prefix id as intakeForm.intakeFormId with type:"Flow" and re-sending the anchor identity fields (DETACH TRAP). Requires the process to already have its attributes saved (see the attributes_saved_before_generate precondition). PRODUCT-COLLECTION PRECONDITION: if the process uses a product collection, that collection must already sit on its own dedicated ProductRequestSection layout page BEFORE generating (see configure-unified-catalog-service-process-attributes-and-product-collection) — a collection left on the attribute section or in the unplaced bucket generates a Flow with NO product-selection screen.
-
-
-**Call:** `POST /connect/service-automation/intake-form/generate-intake-form`   — status: `implemented`
-
-**Inputs:**
-
-- `productId` *(`String`)* — The catalogItemId (== productId) of the process to generate the Flow for.
-- `name` *(`String`)* — Human-readable name for the generated intake Flow (the request-form label). Elicit it; do not default silently.
-
-- `description` *(`String`)* — Description of the intake Flow. The Generate Intake Form UI marks this REQUIRED (Form Title + Description are both mandatory in the wizard) — elicit it, do not send empty.
-
-
-**Depends on:** `resolve-catalog-item`
-
-**Rollback:** Generate only MINTS the Flow; if bind-existing-surface has since attached it, detach via patchCatalogItemGet with intakeForm operationType semantics (see bind-existing-surface — re-send the anchor identity fields); the intake-form resource has no DELETE. If bind has not run, the minted Flow is orphaned metadata. Either way the Flow metadata itself is cleaned up through Flow tooling, not this API.
-
-#### `bind-existing-surface`
-
-BIND — attach a Flow/OmniScript surface to the process via patchCatalogItemGet, sending intakeForm:{id:<existing container id>, intakeFormId:<surface id>, operationType:"Update", type:<Flow|Omniscript>}. This is the SINGLE attach mechanism for ALL branches: in generate-new it binds the surface the generate step just minted (generate does NOT auto-attach); in attach-existing it binds the surface the user picked from a list. DETACH TRAP: operationType:"Update" is a FULL overwrite — this PATCH MUST also re-send the item's identity fields (targetObject, name, usedFor, isActive), sourced from resolve-catalog-item. Omitting targetObject CLEARS the anchor (it reads back absent, not reset to a default); omitting name/usedFor clears them too. Carry resolve-catalog-item.intake_form_id forward as intakeForm.id when the item already has a container (it does, if create provisioned one); omit it only if resolve-catalog-item returned no intakeForm.id. REPLACE GUARD: if resolve-catalog-item.existing_intake_form_surface is non-empty, this bind REPLACES the currently-bound surface — confirm the swap with the user first [precondition: replace_existing_surface_confirmed].
-
-
-**Call:** `PATCH /connect/service-automation/catalog/catalog-item/{catalogItemId}`   — status: `implemented`
-
-**Inputs:**
-
-- `catalogItemId` *(`String`)* — The catalogItemId (== productId) of the process to bind the surface to.
-- `intakeFormSurfaceId` *(`String`)* — The surface id to bind, sourced by mode. GENERATE-NEW (FLOW ONLY): the id returned by generate-intake-form-flow.intake_form_id (a 300-prefix Flow definition id). ATTACH-EXISTING: the user's pick — for a Flow, node.FlowDefinition.value (300-prefix definition id) from list-screen-flows.flow_definition_ids; for an OmniScript, an id from list-omniscript-records.omniscript_ids. In every case it MUST be a real id from the generate response or the org's list, never hand-constructed, and for Flow it must be the definition id (300…), NOT the 2aF version-view id. Sent as intakeForm.intakeFormId.
-
-  - **Source:** output of `list-screen-flows`, `list-omniscript-records`
-- `surfaceType` *(`String`)* — "Flow" or "Omniscript" (note the lower-case s on the wire) — the chosen surface type. Sent as intakeForm.type.
-
-- `containerId` *(`String`)* — The existing intake container id (intakeForm.id) from resolve-catalog-item, carried forward as intakeForm.id so the Update does not orphan the container. Omit only when resolve-catalog-item returned no intakeForm.id.
-
-  - **Source:** output of `resolve-catalog-item`
-- `targetObject` *(`String`)* — The anchor object — a CLOSED enum accepting only Case, Incident, or ServiceRequest. Re-sent to avoid the DETACH TRAP [precondition: bind_patch_resends_anchor_identity_fields]. Take the value from resolve-catalog-item, never a fixed assumption.
-
-  - **Source:** output of `resolve-catalog-item`
-- `name` *(`String`)* — The process name — re-sent to preserve identity on this full-overwrite Update.
-- `usedFor` *(`String`)* — The usedFor value (ServiceProcess) — re-sent to preserve identity.
-- `isActive` *(`Boolean`)* — The isActive flag — re-sent to preserve identity.
-
-**Depends on:** `resolve-catalog-item`, `generate-intake-form-flow`, `list-screen-flows`, `list-omniscript-records`
-
-**Rollback:** To unbind, re-invoke patchCatalogItemGet clearing/replacing intakeForm.intakeFormId (or binding a different surface), always re-sending the anchor identity fields. The catalog-item resource has no DELETE method.
-
-### Verify operations
-
-#### `verify-intake`
-
-Read the process back and confirm the intake surface is bound and the anchor held. Works for every branch — generate-new (Flow) and attach-existing (Flow or OmniScript).
-
-
-**Call:** `GET /connect/service-automation/catalog/catalog-item/{catalogItemId}`   — status: `implemented`
-
-**Inputs:**
-
-- `catalogItemId` *(`String`)* — The catalogItemId (== productId) of the process to verify.
-
-**Depends on:** `resolve-catalog-item`, `generate-intake-form-flow`, `bind-existing-surface`

package/skills/industries-catalog-process-knowledge-configure/SKILL.md

@@ -1,153 +0,0 @@
----
-name: industries-catalog-process-knowledge-configure
-description: "Use this skill when users want to cHILD of the create-unified-catalog-service-process orchestrator — one configuration pass over a service process that ALREADY EXISTS. Trigger when users mention configure, unified, catalog, service, process, knowledge, automation, connect, api, service-automation-connect-api."
-metadata:
-  version: "1.0"
-  accessCheck: "IndustriesEpc.orgHasUnifiedCatalog"
----
-
-# Managing Configure Unified Catalog Service Process Knowledge
-
-## When to Use This Skill
-
-CHILD of the create-unified-catalog-service-process orchestrator — one configuration pass over a service process that ALREADY EXISTS. Run standalone against an existing process (supply its catalogItemId), or as the phase that orchestrator routes to; for a NEW end-to-end process start at create-unified-catalog-service-process, which asks the creation fork FIRST.
-Use this when an admin wants to add (or remove) the Knowledge articles shown on a service process that ALREADY EXISTS — e.g. "attach the reimbursement-policy article to this service process". DONE when the chosen articles read back in associatedArticles on the verify GET with the anchor still intact. Org-gated on Unified Catalog. This attaches EXISTING published articles; it does not author or publish an article. associatedArticles is a DELTA list: send ONLY the change — a new article as operationType:"Create", a removal as operationType:"Delete" carrying that article's association id — never re-send the already-attached ones (re-sending an attached article as "Create" is rejected 400 "already attached"). DETACH-TRAP handling and the delta-list rules are in agent_guidance and step assertions.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Org must have Unified Catalog enabled.
- (check: `Unified Product Catalog enabled`)
-- HARD CONSTRAINT — the service process must ALREADY EXIST and its catalogItemId (== productId) must be known before this workflow runs. The first step (resolve-catalog-item) GETs the item to confirm it exists and is usedFor=ServiceProcess before any write; a 404 there means the id is wrong or the process was never created — the process must be created first, then re-run here with its catalogItemId.
- (check: `process_exists_with_known_catalog_item_id`)
-- HARD CONSTRAINT — each article to associate MUST be a real KnowledgeArticleId taken from the list step (list-knowledge-articles) for THIS org. Never guess or hand-construct an article id. Only PUBLISHED (Online) articles are listable/associable. List the eligible articles, let the user pick one or more, and bind those exact ids.
- (check: `attached_article_is_a_real_listed_id`)
-- HARD CONSTRAINT — associatedArticles on patchCatalogItemGet is a DELTA list, NOT a full replacement. Send ONLY the entries that change; the articles already attached stay attached without being re-sent. To ADD an article, send just that one as operationType:"Create". To REMOVE one, send just that one as operationType:"Delete" carrying its association id (the associatedArticles[].id from resolve-catalog-item — a 1WK-prefix id; a Delete without that id is rejected). Do NOT re-send an already-attached article as "Create" — it is rejected 400 "This article is already attached to this record". (An already-attached article re-sent as "Update" does NOT error but CHURNS its association id — the 1WK id is replaced with a fresh one; the end set is unchanged but any 1WK id captured earlier goes stale. Never treat an association id as durable across a re-Update; always re-read it from a fresh GET before a Delete.) Confirm the final set on the verify GET.
- (check: `bind_sends_only_changed_articles`)
-- HARD CONSTRAINT — patchCatalogItemGet overwrites the item's scalar identity: the bind MUST re-send the item's identity fields (targetObject, name, usedFor, isActive). Omitting targetObject CLEARS the anchor — it reads back absent on the next GET, not reset to a default, even after it was set at create time. The intakeForm block is ALSO a full overwrite: sending it with only {id, operationType:Update} preserves the container but WIPES the bound surface (intakeFormId + type disappear). When the item has an intake surface, the bind MUST re-send intakeForm.intakeFormId AND intakeForm.type alongside the container id, not just the id. The bind PATCH always carries the four identity fields and re-sends the FULL intakeForm (id + intakeFormId + type) when one exists; the verify GET confirms the anchor and intake surface are intact.
- (check: `bind_patch_resends_anchor_identity_fields`)
-
-**Operational rules:**
-
-- MUST-DO CONTRACT (read before executing — each rule is enforced by the named precondition/step; do NOT skip because the detail is further down):
-  1. CONFIRM the process exists first — run resolve-catalog-item (GET) and capture its
-     identity fields (name, usedFor, isActive, targetObject), its current intakeForm.id,
-     and its CURRENT associatedArticles[] — each entry is {id, knowledgeArticleId}; the
-     association id (1WK-prefix) is required to REMOVE that article later. A 404 means the
-     catalogItemId is wrong; do NOT proceed.
-     [precondition: process_exists_with_known_catalog_item_id]
-  2. LIST the org's PUBLISHED (Online) Knowledge articles via list-knowledge-articles,
-     present the COMPLETE set as numbered text (Title, KnowledgeArticleId), and let the
-     user pick one or more. [precondition: attached_article_is_a_real_listed_id]
-  3. BIND via patchCatalogItemGet sending ONLY the change — associatedArticles is a DELTA
-     list, not a full replacement: send each NEWLY chosen article as operationType:"Create"
-     (its knowledgeArticleId only); to REMOVE an article, send just that one as
-     operationType:"Delete" carrying its association id from resolve-catalog-item. Do NOT
-     re-send the already-attached articles — they stay attached, and re-sending an attached
-     one as "Create" is rejected 400 "already attached".
-     [precondition: bind_sends_only_changed_articles]
-  4. The bind PATCH is a FULL overwrite of the ITEM's scalar identity — ALWAYS re-send
-     targetObject + name + usedFor + isActive. The intakeForm block is ALSO a full overwrite:
-     when the item has an intake surface, re-send the FULL block — intakeForm.id AND
-     intakeForm.intakeFormId AND intakeForm.type (operationType:Update). Sending only {id}
-     preserves the container but WIPES the bound surface. Omit intakeForm only
-     when the item has no surface. Otherwise the anchor clears (reads back absent) and/or the intake surface
-     detaches. (The identity overwrite and the associatedArticles delta are independent: the
-     scalars are replaced, the article list is a delta.)
-     [precondition: bind_patch_resends_anchor_identity_fields]
-  5. VERIFY: GET the item and confirm associatedArticles contains the intended final set of
-     knowledgeArticleIds AND targetObject is unchanged. [step: verify-articles]
-- ASK MODALITY: for the article list (unbounded), list the COMPLETE set as numbered text (Title, KnowledgeArticleId, LastModifiedDate) and let the user type one or more selections; present smartly (match a named target locally; list small sets in full; narrow a large set with a typed name rather than dumping every row — the full set is already fetched). The list is a paged GraphQL query (first:2000 + pageInfo.hasNextPage/endCursor) — page through to completeness before asking. Only Online (published) articles appear; a draft/archived article will not be listed and cannot be associated until published.
-TIMING: resolve → list → bind → verify. There is one write path; the add and remove semantics both flow through the associatedArticles[] delta on the bind — add sends a Create entry, remove sends a Delete entry carrying the association id.
-
-## Verification Checklist
-
-After every write operation, confirm the effect by re-reading state:
-
-- After `resolve-catalog-item`, `bind-knowledge-articles`: call `verify-articles` (`GET /connect/service-automation/catalog/catalog-item/{catalogItemId}`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `resolve-catalog-item` | read | implemented | `GET /connect/service-automation/catalog/catalog-item/{catalogItemId}` | — |
-| `list-knowledge-articles` | read | implemented | `queryKnowledgeArticles` | `resolve-catalog-item` |
-| `bind-knowledge-articles` | write | implemented | `PATCH /connect/service-automation/catalog/catalog-item/{catalogItemId}` | `resolve-catalog-item`, `list-knowledge-articles` |
-| `verify-articles` | verify | implemented | `GET /connect/service-automation/catalog/catalog-item/{catalogItemId}` | `resolve-catalog-item`, `bind-knowledge-articles` |
-
-### Read operations
-
-#### `resolve-catalog-item`
-
-CONFIRM + CAPTURE — GET the existing service process to prove it exists and to capture the identity fields the later bind must re-send AND the CURRENT associatedArticles[]. Each associatedArticles entry is {id, knowledgeArticleId}: the id (1WK-prefix association id) is what a later Delete must carry to remove that article; the knowledgeArticleId tells you which articles are already attached so you don't try to re-add one (a re-add as "Create" is rejected 400 "already attached"). Fails fast (404) if the catalogItemId is wrong or the process was never created. Capture name, usedFor, isActive, targetObject (the anchor), the current intake surface (intakeForm.id AND intakeForm.intakeFormId + intakeForm.type — the bound Flow/OmniScript, NOT just the container id) and the current associatedArticles.
-
-
-**Call:** `GET /connect/service-automation/catalog/catalog-item/{catalogItemId}`   — status: `implemented`
-
-**Inputs:**
-
-- `catalogItemId` *(`String`)* — The catalogItemId (== productId) of the EXISTING service process. If the user does not have it, the process must be created first before this workflow can run.
-
-#### `list-knowledge-articles`
-
-LIST — the org's PUBLISHED (Online) Knowledge articles via UIAPI GraphQL: Knowledge__kav filtered to PublishStatus=="Online". Present the COMPLETE set as numbered text (Title, KnowledgeArticleId, LastModifiedDate) and let the user pick one or more; page via pageInfo.endCursor (first:2000 + hasNextPage) — PRESENT smartly: if the user already NAMED the target, match it in the fetched set and show only the matches; if the set is small (≤ ~25) list it all as numbered text; if it is large, do NOT dump every row — show the most-recently-modified top slice (or ask a narrowing keyword) and invite the user to type a name to search (the full set is already fetched, so the local match stays exact). TARGETED LOOKUP: when the user has already NAMED the article, add a title predicate to the where filter — {Title: {like: "%<name>%"}}, AND-combined with the PublishStatus filter above — to fetch just the matches in ONE call instead of paging the whole list; fall back to the full paged listing only when no name was given or the filtered query returns nothing. The list is org-specific — take it from this call, never a fixed list. ID TO BIND: bind the node.KnowledgeArticleId.value (the kA0-prefix KnowledgeArticleId, the stable per-article id across versions), NOT node.Id (the per-version Knowledge__kav row id). associatedArticles.knowledgeArticleId expects the KnowledgeArticleId.
-
-
-**Call:** `queryKnowledgeArticles`   — status: `implemented`
-
-**Depends on:** `resolve-catalog-item`
-
-### Write operations
-
-#### `bind-knowledge-articles`
-
-ASSOCIATE BIND — change the process's associatedArticles[] via patchCatalogItemGet. DELTA LIST: associatedArticles is a delta, not a full replacement — send ONLY the entries that change. To ADD each newly chosen article, send {knowledgeArticleId, operationType:"Create"}; to REMOVE an article, send {id: <its 1WK association id from resolve-catalog-item>, knowledgeArticleId, operationType:"Delete"}. Do NOT re-send the already-attached articles — they stay attached, and re-sending an attached one as "Create" is rejected 400 "This article is already attached to this record". A Delete without the association id is also rejected — carry the id from resolve-catalog-item.existing_associated_articles. DETACH TRAP: this PATCH is a full overwrite of the ITEM's scalar identity — it MUST also re-send the item's identity fields (targetObject, name, usedFor, isActive), sourced from resolve-catalog-item. The intakeForm block is ALSO a full overwrite: when the item has an intake surface, re-send the FULL block — intakeForm.id (container) AND intakeForm.intakeFormId (the bound Flow/OmniScript) AND intakeForm.type, all from resolve-catalog-item, with operationType:"Update". Sending only {id, operationType:Update} preserves the container but WIPES the bound surface (intakeFormId + type vanish). Omit the intakeForm block only if resolve-catalog-item returned no intake_surface_id. Omitting targetObject CLEARS the anchor (it reads back absent on the next GET, not reset to a default). (The scalar identity is replaced; the associatedArticles list is a delta — the two behave independently in the same PATCH.)
-
-
-**Call:** `PATCH /connect/service-automation/catalog/catalog-item/{catalogItemId}`   — status: `implemented`
-
-**Inputs:**
-
-- `catalogItemId` *(`String`)* — The catalogItemId (== productId) of the process to associate the articles with.
-- `associatedArticles` *(`Array`)* — The DELTA of articles to change — send ONLY changed entries, never the already-attached ones. To ADD an article: {knowledgeArticleId, operationType:"Create"}, where knowledgeArticleId is a chosen id from list-knowledge-articles.article_ids (kA0-prefix KnowledgeArticleId, never hand-constructed) that is NOT already in resolve-catalog-item.existing_article_ids. To REMOVE an article: {id, knowledgeArticleId, operationType:"Delete"}, where id is that article's association id (1WK-prefix) from resolve-catalog-item.existing_associated_articles. Re-sending an already-attached article as "Create" is rejected 400 "already attached"; a Delete missing the association id is also rejected.
-
-  - **Source:** output of `list-knowledge-articles`, `resolve-catalog-item`
-- `intakeContainerId` *(`String`)* — The existing intake container id (intakeForm.id) from resolve-catalog-item, carried forward as intakeForm.id (with operationType:"Update"). NOTE the container id alone is NOT enough — the intakeForm block is a full overwrite, so intakeSurfaceId + intakeSurfaceType below must also be re-sent or the bound surface is wiped. Omit the whole intakeForm block only when resolve-catalog-item returned no intake_surface_id.
-
-  - **Source:** output of `resolve-catalog-item`
-- `intakeSurfaceId` *(`String`)* — The bound intake surface id (intakeForm.intakeFormId — the Flow/OmniScript definition id) from resolve-catalog-item. MUST be re-sent alongside the container id: sending intakeForm with only {id} wipes the surface. Present only when the item has a surface.
-
-  - **Source:** output of `resolve-catalog-item`
-- `intakeSurfaceType` *(`String`)* — The bound intake surface type (intakeForm.type — "Flow" or "OmniScript") from resolve-catalog-item. Re-sent with intakeSurfaceId to preserve the bound surface.
-
-  - **Source:** output of `resolve-catalog-item`
-- `targetObject` *(`String`)* — The anchor object (a closed set — Case, Incident, or ServiceRequest) — re-sent on this identity-overwrite PATCH or the anchor CLEARS — it reads back absent on the next GET, not reset to a default (DETACH TRAP). Take the value from resolve-catalog-item, never a fixed assumption.
-
-  - **Source:** output of `resolve-catalog-item`
-- `name` *(`String`)* — The process name — re-sent to preserve identity on this identity-overwrite PATCH.
-- `usedFor` *(`String`)* — The usedFor value (ServiceProcess) — re-sent to preserve identity.
-- `isActive` *(`Boolean`)* — The isActive flag — re-sent to preserve identity.
-
-**Depends on:** `resolve-catalog-item`, `list-knowledge-articles`
-
-**Rollback:** To remove an article added here, re-invoke patchCatalogItemGet with that article as operationType:"Delete" carrying its association id (read it back from the bind response or a fresh GET), always re-sending the anchor identity fields AND the full intakeForm block (id + intakeFormId + type when a surface exists) — the rollback PATCH is the same full-overwrite, so anchor-only re-send would wipe the surface. Because the list is a delta, the other articles are untouched. The catalog-item resource has no DELETE method.
-
-### Verify operations
-
-#### `verify-articles`
-
-Read the process back and confirm the intended articles are associated and the anchor held.
-
-
-**Call:** `GET /connect/service-automation/catalog/catalog-item/{catalogItemId}`   — status: `implemented`
-
-**Inputs:**
-
-- `catalogItemId` *(`String`)* — The catalogItemId (== productId) of the process to verify.
-
-**Depends on:** `resolve-catalog-item`, `bind-knowledge-articles`

package/skills/industries-catalog-process-preprocessor-configure/SKILL.md

@@ -1,168 +0,0 @@
----
-name: industries-catalog-process-preprocessor-configure
-description: "Use this skill when users want to cHILD of the create-unified-catalog-service-process orchestrator — one configuration pass over a service process that ALREADY EXISTS. Trigger when users mention configure, unified, catalog, service, process, preprocessor, automation, connect, api, service-automation-connect-api."
-metadata:
-  version: "1.0"
-  accessCheck: "IndustriesEpc.orgHasUnifiedCatalog"
----
-
-# Managing Configure Unified Catalog Service Process Preprocessor
-
-## When to Use This Skill
-
-CHILD of the create-unified-catalog-service-process orchestrator — one configuration pass over a service process that ALREADY EXISTS. Run standalone against an existing process (supply its catalogItemId), or as the phase that orchestrator routes to; for a NEW end-to-end process start at create-unified-catalog-service-process, which asks the creation fork FIRST.
-Use this when an admin wants to set (or remove) the Apex preprocessor on a service process that ALREADY EXISTS — e.g. "add a preprocessor that rejects duplicate laptop requests". DONE when the chosen class reads back as the ONE preProcessors entry on the verify GET with the anchor still intact. Org-gated on Unified Catalog. This references an EXISTING Apex class; it does not author or compile one. SINGLE-VALUED: a process has at most ONE preprocessor. To SET when none exists, send the class as operationType:"Create". To CHANGE the existing one, REPLACE — send the current class as operationType:"Delete" (carrying its junction id) AND the new class as operationType:"Create" in the same bind. To REMOVE, send the current class as operationType:"Delete" carrying its junction id. NEVER send a Create while a preprocessor is already attached without also Deleting it: the API accepts the second Create (200) but the extra junction is INVALID — it never renders in the UI and is not honoured. A Delete WITHOUT its junction id does not error: it silently creates a stray entry instead of removing anything, so the junction id is mandatory on every Delete. DETACH-TRAP handling and the single-valued replace rule are in agent_guidance and step assertions.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Org must have Unified Catalog enabled.
- (check: `Unified Product Catalog enabled`)
-- HARD CONSTRAINT — the service process must ALREADY EXIST and its catalogItemId (== productId) must be known before this workflow runs. The first step (resolve-catalog-item) GETs the item to confirm it exists and is usedFor=ServiceProcess before any write; a 404 there means the id is wrong or the process was never created — the process must be created first, then re-run here with its catalogItemId.
- (check: `process_exists_with_known_catalog_item_id`)
-- HARD CONSTRAINT — the preprocessor to set MUST be a real ApexClass Id taken from the list step (list-apex-classes) for THIS org. Never guess or hand-construct a class id. List the eligible classes, let the user pick ONE, and bind that exact id.
- (check: `preprocessor_is_a_real_listed_apex_class`)
-- HARD CONSTRAINT — a service process is SINGLE-VALUED for preprocessors: at most ONE. The Connect API UNDER-ENFORCES this — sending a second class as operationType:"Create" while one is already attached is accepted (200) and persists a second junction, but that row is INVALID (never renders in the UI, not honoured). So the bind rule is REPLACE, not add:
-  - SET (none attached): send the new class as {preProcessorsID, operationType:"Create"}.
-  - CHANGE (one attached): send the existing class as {id:<its 127-prefix junction id>,
-    preProcessorsID, operationType:"Delete"} AND the new class as {preProcessorsID,
-    operationType:"Create"} in the SAME bind.
-  - REMOVE: send the existing class as {id, preProcessorsID, operationType:"Delete"}.
-NEVER send a Create while a preprocessor is already attached without also Deleting it. A Delete WITHOUT its junction id does NOT error — it silently ADDS a stray entry instead of removing anything, so the junction id (preProcessors[].id from resolve-catalog-item, a 127-prefix id) is mandatory on every Delete. Confirm the final set (exactly one, the intended class) on the verify GET.
- (check: `bind_replaces_single_preprocessor`)
-- HARD CONSTRAINT — patchCatalogItemGet overwrites the item's scalar identity: the bind MUST re-send the item's identity fields (targetObject, name, usedFor, isActive). Omitting targetObject CLEARS the anchor — it reads back absent on the next GET, not reset to a default, even after it was set at create time. The intakeForm block is ALSO a full overwrite: sending it with only {id, operationType:Update} preserves the container but WIPES the bound surface (intakeFormId + type disappear). When the item has an intake surface, the bind MUST re-send intakeForm.intakeFormId AND intakeForm.type alongside the container id, not just the id. The bind PATCH always carries the four identity fields and re-sends the FULL intakeForm (id + intakeFormId + type) when one exists; the verify GET confirms the anchor and intake surface are intact.
- (check: `bind_patch_resends_anchor_identity_fields`)
-
-**Operational rules:**
-
-- MUST-DO CONTRACT (read before executing — each rule is enforced by the named precondition/step; do NOT skip because the detail is further down):
-  1. CONFIRM the process exists first — run resolve-catalog-item (GET) and capture its
-     identity fields (name, usedFor, isActive, targetObject), its current intakeForm.id,
-     and its CURRENT preProcessors[] — each entry is {id, preProcessorsID}; the junction id
-     (127-prefix) is required to REMOVE that preprocessor later. A 404 means the
-     catalogItemId is wrong; do NOT proceed.
-     [precondition: process_exists_with_known_catalog_item_id]
-  2. LIST the org's Apex classes via list-apex-classes, present the COMPLETE set as numbered
-     text (Name, ApexClass Id), and let the user pick ONE.
-     [precondition: preprocessor_is_a_real_listed_apex_class]
-  3. BIND via patchCatalogItemGet — SINGLE-VALUED, so REPLACE rather than add. If NONE is
-     attached, send the chosen class as operationType:"Create" (its preProcessorsID only). If
-     ONE is already attached and you are CHANGING it, send the existing class as
-     operationType:"Delete" (carrying its 127-prefix junction id from resolve-catalog-item) AND
-     the new class as operationType:"Create" in the SAME bind. To REMOVE, send the existing
-     class as operationType:"Delete" carrying its junction id. NEVER send a Create while a
-     preprocessor is already attached without also Deleting it — the API accepts it (200) but
-     the extra junction is INVALID (never shows in the UI, not honoured). A
-     Delete missing the junction id silently ADDS a stray entry rather than removing; carry the
-     127-prefix id.
-     [precondition: bind_replaces_single_preprocessor]
-  4. The bind PATCH is a FULL overwrite of the ITEM's scalar identity — ALWAYS re-send
-     targetObject + name + usedFor + isActive. The intakeForm block is ALSO a full overwrite:
-     when the item has an intake surface, re-send the FULL block — intakeForm.id AND
-     intakeForm.intakeFormId AND intakeForm.type (operationType:Update). Sending only {id}
-     preserves the container but WIPES the bound surface. Omit intakeForm only
-     when the item has no surface. Otherwise the anchor clears (reads back absent) and/or the intake surface
-     detaches. (The identity overwrite and the preProcessors delta are independent: the scalars
-     are replaced, the preprocessor list is a delta.)
-     [precondition: bind_patch_resends_anchor_identity_fields]
-  5. VERIFY: GET the item and confirm preProcessors contains EXACTLY ONE entry — the intended
-     class — with no second/stray junction, AND targetObject is unchanged.
-     [step: verify-preprocessors]
-- ASK MODALITY: for the Apex-class list (unbounded), list the COMPLETE set as numbered text (Name, ApexClass Id) and let the user type ONE selection; PRESENT smartly — match a named target locally, list a small set in full, and narrow a large one (typed name or a recent top slice) rather than dumping every row. The list is a paged SOQL query — page through nextRecordsUrl to completeness before asking. The list is org-specific — take it from this call, never a fixed list.
-TIMING: resolve → list → bind → verify. There is one write path. SET, CHANGE, and REMOVE all flow through the preProcessors[] delta on the bind — SET sends one Create, CHANGE sends a Delete (of the existing, carrying its junction id) PLUS a Create (of the new) together, REMOVE sends one Delete carrying the junction id.
-
-## Verification Checklist
-
-After every write operation, confirm the effect by re-reading state:
-
-- After `resolve-catalog-item`, `bind-preprocessors`: call `verify-preprocessors` (`GET /connect/service-automation/catalog/catalog-item/{catalogItemId}`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `resolve-catalog-item` | read | implemented | `GET /connect/service-automation/catalog/catalog-item/{catalogItemId}` | — |
-| `list-apex-classes` | read | implemented | `queryApexClasses` | `resolve-catalog-item` |
-| `bind-preprocessors` | write | implemented | `PATCH /connect/service-automation/catalog/catalog-item/{catalogItemId}` | `resolve-catalog-item`, `list-apex-classes` |
-| `verify-preprocessors` | verify | implemented | `GET /connect/service-automation/catalog/catalog-item/{catalogItemId}` | `resolve-catalog-item`, `bind-preprocessors` |
-
-### Read operations
-
-#### `resolve-catalog-item`
-
-CONFIRM + CAPTURE — GET the existing service process to prove it exists and to capture the identity fields the later bind must re-send AND the CURRENT preProcessors[]. Each preProcessors entry is {id, preProcessorsID}: the id (127-prefix junction id) is what a later Delete must carry to remove that preprocessor; the preProcessorsID (an ApexClass 01p id) tells you which classes are already attached. Fails fast (404) if the catalogItemId is wrong or the process was never created. Capture name, usedFor, isActive, targetObject (the anchor), the current intake surface (intakeForm.id AND intakeForm.intakeFormId + intakeForm.type — the bound Flow/OmniScript, NOT just the container id) and the current preProcessors.
-
-
-**Call:** `GET /connect/service-automation/catalog/catalog-item/{catalogItemId}`   — status: `implemented`
-
-**Inputs:**
-
-- `catalogItemId` *(`String`)* — The catalogItemId (== productId) of the EXISTING service process. If the user does not have it, the process must be created first before this workflow can run.
-
-#### `list-apex-classes`
-
-LIST — the org's Apex classes via SOQL over ApexClass. Present the COMPLETE set as numbered text (Name, ApexClass Id) and let the user pick ONE; page via nextRecordsUrl — never cap or truncate. TARGETED LOOKUP: when the user has already NAMED the class, append AND Name LIKE '%<name>%' to the SOQL WHERE (alongside Status='Active') to fetch just the matches in ONE call instead of paging the whole list; fall back to the full listing only when no name was given or the filter returns nothing. The list is org-specific — take it from this call, never a fixed list. ID TO BIND: bind the ApexClass Id (01p-prefix). preProcessors.preProcessorsID expects that id.
-
-
-**Call:** `queryApexClasses`   — status: `implemented`
-
-**Inputs:**
-
-- `q` *(`string`)*
-
-**Depends on:** `resolve-catalog-item`
-
-### Write operations
-
-#### `bind-preprocessors`
-
-SET BIND — change the process's single preprocessor via patchCatalogItemGet. SINGLE-VALUED / REPLACE: a process has at most ONE preprocessor. To SET when none is attached, send the chosen class as {preProcessorsID, operationType:"Create"}. To CHANGE the existing one, send the current class as {id:<its 127-prefix junction id from resolve-catalog-item>, preProcessorsID, operationType:"Delete"} AND the new class as {preProcessorsID, operationType:"Create"} in the SAME preProcessors[] array. To REMOVE, send only the current class as {id, preProcessorsID, operationType:"Delete"}. NEVER send a Create while a preprocessor is already attached without also Deleting it — the API accepts the second Create (200) and persists it, but that extra junction is INVALID: it never renders in the UI and is not honoured. A Delete WITHOUT the junction id does NOT error — it silently ADDS a stray entry instead of removing, so carry the id from resolve-catalog-item.existing_preprocessors. DETACH TRAP: this PATCH is a full overwrite of the ITEM's scalar identity — it MUST also re-send the item's identity fields (targetObject, name, usedFor, isActive), sourced from resolve-catalog-item. The intakeForm block is ALSO a full overwrite: when the item has an intake surface, re-send the FULL block — intakeForm.id (container) AND intakeForm.intakeFormId (the bound Flow/OmniScript) AND intakeForm.type, all from resolve-catalog-item, with operationType:"Update". Sending only {id, operationType:Update} preserves the container but WIPES the bound surface (intakeFormId + type vanish). Omit the intakeForm block only if resolve-catalog-item returned no intake_surface_id. Omitting targetObject CLEARS the anchor (it reads back absent on the next GET, not reset to a default). (The scalar identity is replaced; the preProcessors list is a delta — the two behave independently in the same PATCH.)
-
-
-**Call:** `PATCH /connect/service-automation/catalog/catalog-item/{catalogItemId}`   — status: `implemented`
-
-**Inputs:**
-
-- `catalogItemId` *(`String`)* — The catalogItemId (== productId) of the process to set the preprocessor on.
-- `preProcessors` *(`Array`)* — The preProcessors[] delta for a SINGLE-VALUED preprocessor — REPLACE, not add. SET (none attached): [{preProcessorsID, operationType:"Create"}], where preProcessorsID is the chosen id from list-apex-classes.class_ids (01p-prefix ApexClass id, never hand-constructed). CHANGE (one attached): send BOTH in one array — the existing class as {id, preProcessorsID, operationType:"Delete"} (id = its 127-prefix junction id from resolve-catalog-item.existing_preprocessors) AND the new class as {preProcessorsID, operationType:"Create"}. REMOVE: [{id, preProcessorsID, operationType:"Delete"}]. NEVER send a bare Create while a preprocessor is already attached — the API accepts it (200) but the extra junction is INVALID (invisible in the UI, not honoured). A Delete missing the junction id silently adds a stray entry instead of removing.
-
-  - **Source:** output of `list-apex-classes`, `resolve-catalog-item`
-- `intakeContainerId` *(`String`)* — The existing intake container id (intakeForm.id) from resolve-catalog-item, carried forward as intakeForm.id (with operationType:"Update"). NOTE the container id alone is NOT enough — the intakeForm block is a full overwrite, so intakeSurfaceId + intakeSurfaceType below must also be re-sent or the bound surface is wiped. Omit the whole intakeForm block only when resolve-catalog-item returned no intake_surface_id.
-
-  - **Source:** output of `resolve-catalog-item`
-- `intakeSurfaceId` *(`String`)* — The bound intake surface id (intakeForm.intakeFormId — the Flow/OmniScript definition id) from resolve-catalog-item. MUST be re-sent alongside the container id: sending intakeForm with only {id} wipes the surface. Present only when the item has a surface.
-
-  - **Source:** output of `resolve-catalog-item`
-- `intakeSurfaceType` *(`String`)* — The bound intake surface type (intakeForm.type — "Flow" or "OmniScript") from resolve-catalog-item. Re-sent with intakeSurfaceId to preserve the bound surface.
-
-  - **Source:** output of `resolve-catalog-item`
-- `targetObject` *(`String`)* — The anchor object (a closed set — Case, Incident, or ServiceRequest) — re-sent on this identity-overwrite PATCH or the anchor CLEARS — it reads back absent on the next GET, not reset to a default (DETACH TRAP). Take the value from resolve-catalog-item, never a fixed assumption.
-
-  - **Source:** output of `resolve-catalog-item`
-- `name` *(`String`)* — The process name — re-sent to preserve identity on this identity-overwrite PATCH.
-- `usedFor` *(`String`)* — The usedFor value (ServiceProcess) — re-sent to preserve identity.
-- `isActive` *(`Boolean`)* — The isActive flag — re-sent to preserve identity.
-
-**Depends on:** `resolve-catalog-item`, `list-apex-classes`
-
-**Rollback:** To undo, re-invoke patchCatalogItemGet with the class added here as operationType:"Delete" carrying its junction id (read it back from the bind response or a fresh GET); if this bind REPLACED a prior preprocessor, also re-Create the prior class to restore it. Always re-send the anchor identity fields AND the full intakeForm block (id + intakeFormId + type when a surface exists) — the rollback PATCH is the same full-overwrite, so anchor-only re-send would wipe the surface. The catalog-item resource has no DELETE method.
-
-### Verify operations
-
-#### `verify-preprocessors`
-
-Read the process back and confirm the intended preprocessor is the sole entry (or none after a REMOVE) and the anchor held.
-
-
-**Call:** `GET /connect/service-automation/catalog/catalog-item/{catalogItemId}`   — status: `implemented`
-
-**Inputs:**
-
-- `catalogItemId` *(`String`)* — The catalogItemId (== productId) of the process to verify.
-
-**Depends on:** `resolve-catalog-item`, `bind-preprocessors`