@salesforce/afv-skills 1.65.0 → 1.66.0

package/skills/fsc-actionable-segmentation-settings-configure/SKILL.md

@@ -1,180 +0,0 @@
----
-name: fsc-actionable-segmentation-settings-configure
-description: "Use this skill when users want to manages Actionable Segmentation (FSC Actionable List) admin settings. Trigger when users mention actionable, segmentation, settings, actionable segmentation settings."
-metadata:
-  version: "1.0"
-  accessCheck: "(ActionableList.userHasActionableListAccess) || (SetupUtil.isSetupAdmin)"
----
-
-# Managing Actionable Segmentation Settings
-
-## When to Use This Skill
-
-Manages Actionable Segmentation (FSC Actionable List) admin settings. Three concept clusters: (1) two org prefs `listPref` (master feature toggle) and `adminConfigAccess` (admin-config edit perm) read together as a map and toggled individually; (2) install + status of the bundled CRM Analytics (Wave) application that backs the feature; (3) admin-list-view ops on `ActionableListDefinition` (ALD) records — toggle IsActive, upsert dataset columns and member statuses with server-enforced caps + uniqueness, and a canDelete + delete pair. `BatchCalcJobDefinition` lookup by anchor entity supports the ALD editor.
-
-## Workflow
-
-Enable the feature via save-pref(listPref=true), then install-wave-application; poll get-actionable-list-folder-status until it returns `CompletedStatus` (`InProgressStatus` while still running; `NotAvailable` before it starts). ALD edits need an existing ALD id (creation lives on industries-actionablelist-connect-api). Always call can-delete-actionable-list-definition before delete-actionable-list-definition.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- User must have ActionableList ActionableListAccess access. (check: `Actionable List access`)
-- Caller must be a Setup admin. The backing bean gates BOTH the read (getActionableListAllConfigurations) and the write (savePref) with `!isSetupAdmin() && ORG_HAS_ACTIONABLE_LIST → NoAccessException`, so once ActionableList is enabled on the org a non-admin cannot read the config map or toggle any pref. Skill-wide, not step-scoped. (check: `Setup administrator access`)
-
-**Destructive operations — require explicit user confirmation:**
-
-- **`delete-actionable-list-definition`** — Delete the ActionableListDefinition; cascades to its dataset columns and member statuses. Pair with can-delete-actionable-list-definition to gate the call and avoid orphaning ActionableList rows.
-  - Rollback: No automatic rollback.
-
-## Verification Checklist
-
-After every write operation, confirm the effect by re-reading state:
-
-- After `save-pref`: call `verify-save-pref` (`GET /headless/invoke/platform/actionable-segmentation-settings`)
-- After `install-wave-application`: call `verify-install-wave-application` (`GET /headless/invoke/platform/actionable-segmentation-settings/get-actionable-list-folder-status`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `get-all-configurations` | read | proposed | `GET /headless/invoke/platform/actionable-segmentation-settings` | — |
-| `get-datatable-data-types` | read | proposed | `GET /headless/invoke/platform/actionable-segmentation-settings/get-datatable-data-types` | — |
-| `save-pref` | write | implemented | `PATCH /headless/invoke/platform/actionable-segmentation-settings/save-pref` | — |
-| `get-actionable-list-folder-status` | read | proposed | `GET /headless/invoke/platform/actionable-segmentation-settings/get-actionable-list-folder-status` | — |
-| `install-wave-application` | write | proposed | `PATCH /headless/invoke/platform/actionable-segmentation-settings/install-wave-application` | — |
-| `update-actionable-list-member-status` | write | proposed | `PATCH /headless/invoke/platform/actionable-segmentation-settings/update-actionable-list-member-status` | — |
-| `update-dataset-columns` | write | proposed | `PATCH /headless/invoke/platform/actionable-segmentation-settings/update-dataset-columns` | — |
-| `toggle-actionable-list-definition` | write | proposed | `PATCH /headless/invoke/platform/actionable-segmentation-settings/toggle-actionable-list-definition` | — |
-| `can-delete-actionable-list-definition` | read | proposed | `GET /headless/invoke/platform/actionable-segmentation-settings/can-delete-actionable-list-definition` | — |
-| `delete-actionable-list-definition` | delete | proposed | `DELETE /headless/invoke/platform/actionable-segmentation-settings/delete-actionable-list-definition` | — |
-| `get-batch-calc-job-definitions` | read | proposed | `GET /headless/invoke/platform/actionable-segmentation-settings/get-batch-calc-job-definitions` | — |
-| `verify-save-pref` | verify | — | `GET /headless/invoke/platform/actionable-segmentation-settings` | `save-pref` |
-| `verify-install-wave-application` | verify | — | `GET /headless/invoke/platform/actionable-segmentation-settings/get-actionable-list-folder-status` | `install-wave-application` |
-
-### Read operations
-
-#### `get-all-configurations`
-
-Returns Map<String,Boolean> with `listPref` (master toggle) and `adminConfigAccess` (admin-config edit perm). Throws NoAccessException for non-Setup-admins when listPref is on. AURA-IS-CANONICAL — feature-scoped 2-key projection of org prefs.
-
-**Call:** `GET /headless/invoke/platform/actionable-segmentation-settings`   — status: `proposed`
-
-#### `get-datatable-data-types`
-
-Returns supported column types as Map<name,apiValue>: Boolean, Currency, Date, DateTime, Email, Location, Number, Percent, Phone, Text (default), Url. AURA-IS-CANONICAL — wraps internal Java enum, no public describe surface.
-
-**Call:** `GET /headless/invoke/platform/actionable-segmentation-settings/get-datatable-data-types`   — status: `proposed`
-
-#### `get-actionable-list-folder-status`
-
-Returns the bundled CRM Analytics (Wave) app install status, or null when caller lacks View Setup. Fixed 3-value enum: `CompletedStatus` (install finished successfully), `InProgressStatus` (install still running), `NotAvailable` (no install present / not started). AURA-IS-CANONICAL — controller hides the canonical Wave folder name; raw `/wave/folders/{id}` requires the agent to know it.
-
-**Call:** `GET /headless/invoke/platform/actionable-segmentation-settings/get-actionable-list-folder-status`   — status: `proposed`
-
-#### `can-delete-actionable-list-definition`
-
-Returns true when no ActionableList rows reference the given ALD (delete would not orphan). Call before delete-actionable-list-definition. AURA-IS-CANONICAL — wraps orphan-check semantics that may evolve; raw SOQL count bakes the current implementation in.
-
-**Call:** `GET /headless/invoke/platform/actionable-segmentation-settings/can-delete-actionable-list-definition`   — status: `proposed`
-
-**Inputs:**
-
-- `actionableListDefinitionId` *(`String`)*
-
-#### `get-batch-calc-job-definitions`
-
-Lists BatchCalcJobDefinition records whose AnchorEntity matches the given object API name. Powers the ALD editor's calc-job picker. AURA-IS-CANONICAL — BatchCalcJobDefinition is industries-internal; sObject substitution plausible but unverified.
-
-**Call:** `GET /headless/invoke/platform/actionable-segmentation-settings/get-batch-calc-job-definitions`   — status: `proposed`
-
-**Inputs:**
-
-- `anchorEntity` *(`String`)*
-
-### Write operations
-
-#### `save-pref`
-
-Writes one org pref. `pref` is restricted to {listPref, adminConfigAccess}; any other name is ignored. Server-enforced gating inside savePref: a non-Setup-admin caller (with ActionableList enabled) gets NoAccessException; a Setup-admin caller must additionally have Data Pipelines/Insights enabled (InsightsAccessCheck.ORG_HAS_DATA_PIPELINES_APP AND ORG_HAS_DATA_PIPELINES_APP_ENABLED — else AuraHandledException "DataPipeLineNotEnabledError") and Data Processing Engine enabled (CalcserviceAccessCheck.ORG_HAS_CALCSERVICE — else "DPENotEnabledError"). AURA-IS-CANONICAL — the pref allowlist + admin cross-feature gate are not reconstructable via a raw pref / Metadata-API write.
-
-**Call:** `PATCH /headless/invoke/platform/actionable-segmentation-settings/save-pref`   — status: `implemented`
-
-**Inputs:**
-
-- `pref` *(`String`)* — Value for the pref field.
-- `enabled` *(`boolean`)* — Whether d is enabled.
-
-#### `install-wave-application`
-
-Triggers install of the bundled CRM Analytics (Wave) app required for Actionable Segmentation. Setup-admin only. Idempotent at the service layer. AURA-IS-CANONICAL — controller hides the canonical templateApiName; sibling SORs RevenueInsightsSetup / ServiceUnifiedAnalytics wrap the install per-feature for the same reason.
-
-**Call:** `PATCH /headless/invoke/platform/actionable-segmentation-settings/install-wave-application`   — status: `proposed`
-
-#### `update-actionable-list-member-status`
-
-Upserts ActionableListMemberStatus rows on one ALD. inputJson is `{memberStatus:[{id?, statusIcon, status}]}`; entries without id created, with id modified, duplicate `status` rejected server-side. Returns ALL member statuses (max 100). AURA-IS-CANONICAL — batch + uniqueness not reconstructable via per-row sObject PATCH.
-
-**Call:** `PATCH /headless/invoke/platform/actionable-segmentation-settings/update-actionable-list-member-status`   — status: `proposed`
-
-**Inputs:**
-
-- `actionableListDefinitionId` *(`String`)* — Id of the actionable list definition.
-- `inputJson` *(`String`)* — Value for the input json field.
-
-#### `update-dataset-columns`
-
-Upserts ActionableListDatasetColumn rows on one ALD. inputJson is `{datasetColumn:[{id, sourceFieldName, objectName, isDefault, dataDomain, dataType, isTypeAheadSearchEnabled}]}`. Server enforces MAX_DEF_ALDC_IN_ALD cap on default-flagged columns and rejects renaming the anchor object's Id column. AURA-IS-CANONICAL.
-
-**Call:** `PATCH /headless/invoke/platform/actionable-segmentation-settings/update-dataset-columns`   — status: `proposed`
-
-**Inputs:**
-
-- `actionableListDefinitionId` *(`String`)* — Id of the actionable list definition.
-- `inputJson` *(`String`)* — Value for the input json field.
-
-#### `toggle-actionable-list-definition`
-
-Sets IsActive on the named ALD and returns the updated record (id + recordLink + named fields). AURA-IS-CANONICAL — Connect API has no PATCH on ALD; raw sObject PATCH returns 204, losing the controller's record-projection response.
-
-**Call:** `PATCH /headless/invoke/platform/actionable-segmentation-settings/toggle-actionable-list-definition`   — status: `proposed`
-
-**Inputs:**
-
-- `actionableListDefinitionId` *(`String`)* — Id of the actionable list definition.
-- `isActive` *(`boolean`)* — Whether active is enabled.
-
-### Verify operations
-
-#### `verify-save-pref`
-
-Read back the org-pref map via getActionableListAllConfigurations to confirm save-pref took effect; check the targeted key (`listPref` or `adminConfigAccess`) equals the value that was written.
-
-**Call:** `GET /headless/invoke/platform/actionable-segmentation-settings`
-
-**Depends on:** `save-pref`
-
-#### `verify-install-wave-application`
-
-Read the Wave folder install status via getActionableListFolderStatus to confirm install-wave-application kicked off and to poll until it reports `CompletedStatus` (`InProgressStatus` while the install is still running; `NotAvailable` before it starts).
-
-**Call:** `GET /headless/invoke/platform/actionable-segmentation-settings/get-actionable-list-folder-status`
-
-**Depends on:** `install-wave-application`
-
-### Destructive operations
-
-#### `delete-actionable-list-definition`
-
-Delete the ActionableListDefinition; cascades to its dataset columns and member statuses. Pair with can-delete-actionable-list-definition to gate the call and avoid orphaning ActionableList rows.
-
-**Call:** `DELETE /headless/invoke/platform/actionable-segmentation-settings/delete-actionable-list-definition`   — status: `proposed`
-
-**Inputs:**
-
-- `actionableListDefinitionId` *(`String`)*

package/skills/fsc-digital-origination-bre-decision-matrix-foundation-create/SKILL.md

@@ -1,196 +0,0 @@
----
-name: fsc-digital-origination-bre-decision-matrix-foundation-create
-parent: "digital-origination-bre-setup"
-purpose: "Create, populate, and activate a Business Rules Engine decision matrix used by a lending BRE feature."
-description: "Create a Business Rules Engine decision matrix, define its input and output columns, load its rows, and activate the version - the shared building block for the Digital Lending Disclosures and Consent, Document Upload, and STP applicant eligibility features. The matrix is a CalculationMatrix sObject (key prefix 0lI); its Type field MUST be set to \"Standard\" (the derived version MatrixType formula reads from it - a null Type makes the runtime lookup throw \"Unsupported Matrix type null\"). Columns are written through the BRE Taurus decision-matrix Connect builder API (columns auto-create version 1); rows are written by direct CalculationMatrixRow sObject insert with an engine-computed MD5-hash Name into a draft version; and the version is activated through the decision-matrix builder controller. Resolves an existing matrix by exact name before creating one, and validates activation with a fresh read AND a live BRE lookup."
-metadata:
-  version: "1.0"
----
-
-# Digital Origination decision-matrix foundation
-
-Create the Business Rules Engine **decision matrix** that a lending BRE feature depends on: a lookup of
-input column values to output column values. This sibling owns the matrix lifecycle only — create,
-columns, rows, activate. The calling feature sibling supplies the matrix name, the column contract, and
-the concrete rows, and consumes the returned matrix and version IDs.
-
-A decision matrix here is the admin-typed lookup surface from the help articles (Business Rules Engine →
-Lookup Tables → New → Decision Matrix), **not** the source-object decision *table* used by
-`digital-origination-pricing-setup`. Do not use the decision-table Connect API for this work.
-
-## The matrix is a CalculationMatrix, not a DecisionMatrixDefinition
-
-Org-verified: the FSC Digital Lending decision matrix is stored as a **`CalculationMatrix`** sObject
-(key prefix `0lI`), with `CalculationMatrixVersion` (`0lN`), `CalculationMatrixColumn` (`0lJ`), and
-`CalculationMatrixRow` (`9mt`). The BRE `DecisionMatrixDefinition`/`DecisionMatrixDefinitionVersion`
-sObjects (prefixes `9QN`/`9QO`) are a **different model** — the Connect decision-matrix API rejects a
-`9QN` id with `INVALID_ID_FIELD`. Always create and address the matrix as a `CalculationMatrix`.
-
-There is **no Connect "create matrix definition" operation.** The matrix definition is created by a
-direct `CalculationMatrix` sObject insert (or, the officially supported path, a Metadata API deploy of a
-`DecisionMatrixDefinition` metadata component with `type` set). Do not look for a
-`POST /connect/business-rules/...` create op — it does not exist.
-
-## The single most important field: `CalculationMatrix.Type`
-
-**Org-verified root cause — set `CalculationMatrix.Type` or the matrix will never evaluate.**
-`CalculationMatrixVersion.MatrixType` is a **derived formula field** that mirrors the parent
-`CalculationMatrix.Type` at query time (it is read-only — createable=false, updateable=false — so nothing
-writes it directly). A raw `CalculationMatrix` sObject insert leaves `Type` null, so `MatrixType` reads
-null on every version forever, and the runtime lookup dispatch (`Standard` vs `Grouped`) falls through to
-`throw "Unsupported Matrix type null"` — surfaced to callers as *"there isn't any output for the specified
-input parameters."* The same null also 500s the Connect rows write.
-
-**Fix / requirement:** immediately after inserting the `CalculationMatrix`, PATCH
-`Type = "Standard"` (a plain settable STATICENUM; enum `CalcMatrixType` = `Standard` | `Grouped` — use
-`Standard` unless you genuinely need grouped semantics). Verify with a query that
-`CalculationMatrixVersion.MatrixType` reads `Standard`, not null. The supported *creation* path — a
-Metadata API deploy of a `DecisionMatrixDefinition` with a required `type` — sets `Type` for you; a raw
-sObject insert does not, so you must PATCH it.
-
-## Preconditions and input contract
-
-Require from the calling feature sibling:
-
-- Target-org alias and acting admin.
-- Exact matrix **Name**.
-- Column contract: for each column, the header name/apiName, header type (`Input` or `Output`), and
-  data type. Use the exact enum the `CalculationMatrixColumn` describe accepts — verified tokens:
-  `ColumnType` = `Input` | `Output`; `DataType` = `Text` | `Number` | `NumberRange` | `TextRange` |
-  `Currency` | `Percent` | `Boolean`. Map help-article labels (e.g. "Number Range") to these tokens
-  (`NumberRange`) — never submit the English label.
-- Row contract: one or more rows, each mapping input values to output values.
-
-Confirm Rule Engine Designer access from the `permissions` sibling before creating a matrix.
-
-## Corpus operations and sObjects to use
-
-**Create the matrix definition (sObject insert).** Insert a `CalculationMatrix` record — required field
-`Name`, optional `Description`. Capture the returned id (`0lI…`) as `matrixId`. **Then PATCH
-`CalculationMatrix.Type = "Standard"`** (see "The single most important field" above) — without it the
-matrix never evaluates.
-
-**Columns — approved BRE Taurus decision-matrix Connect API**
-(SOR `connect-api/bre-taurus/industries-interaction-decisionmatrix-connect-api__sfdc.industries.interaction.decisionmatrix.connect.api_oas_67.0`):
-
-| Purpose | Step | Endpoint |
-|---|---|---|
-| Add columns | `post-decision-matrix-columns` | `POST /connect/omnistudio/decision-matrices/{matrixId}/columns` |
-| Verify columns | `verify-columns` / `get-decision-matrix-columns` | `GET /connect/omnistudio/decision-matrices/{matrixId}/columns` |
-| Read rows | `verify-rows` / `get-decision-matrix-rows` | `GET /connect/omnistudio/decision-matrices/{matrixId}/versions/{versionId}/rows` |
-
-Rows are written by **direct `CalculationMatrixRow` sObject insert**, not a Connect POST — see the rows
-section below. The Connect `post-decision-matrix-rows` op exists but 500s on the verified org.
-
-Each column object: `{name, apiName, columnType, dataType, displaySequence}` — and, for a `NumberRange`
-input column, `rangeValues` (see below). **The first `post-decision-matrix-columns` call auto-creates
-version 1** (`CalculationMatrixVersion`, `0lN`). Do **not** insert a `CalculationMatrixVersion` yourself —
-inserting it before columns fails ("needs at least one input and one output column"), and inserting it
-after fails ("version number 1 already in use"). Read the auto-created version id with a SOQL query on
-`CalculationMatrixVersion` filtered by `CalculationMatrixId`.
-
-**`NumberRange` banding is a column property, set at column-creation time.** A `NumberRange` input column
-carries a `rangeValues` string — a comma-separated list of band boundaries (org-verified shape, e.g.
-`"0,740,10000"` for two bands 0–739 and 740–9999). It **cannot** be edited later: once the version is
-enabled the Connect columns-POST returns "You can't edit the column data in an enabled Decision Matrix
-version," and once the matrix has more than one version it returns "Can't edit columns in a Decision
-Matrix with more than 1000 rows or more than one version." So set `rangeValues` on the very first
-`post-decision-matrix-columns` call. A column posted without it reads back `rangeValues: null` and the
-runtime lookup will never match a range row.
-
-**Rows — direct `CalculationMatrixRow` sObject insert with an engine-computed MD5-hash `Name`
-(org-verified).** Insert each row as a `CalculationMatrixRow` sObject. Fields: `CalculationMatrixVersionId`
-(the ONLY FK — there is no `CalculationMatrixId` field on the row), `Name` (the engine hash, below),
-`InputData` (JSON string), `OutputData` (JSON string). Direct inserts **do** materialize into the runtime
-lookup **once `CalculationMatrix.Type` is set** (the earlier belief that they don't was a
-misdiagnosis — the real blocker was the null `Type`). The Connect `post-decision-matrix-rows` write 500s
-on the verified org (`UNKNOWN_EXCEPTION`) regardless of body, so do not depend on it.
-
-- **The `Name` MUST be the engine's row hash, or the lookup won't find the row.** Algorithm (this is the
-  exact hash the matrix engine computes to match a row at lookup time, reproduced here): over the **input columns only**, sort keys in natural String order;
-  for each build `columnName + String.valueOf(value).toLowerCase()` (the column `Name` is NOT lowercased,
-  the value IS); join with `""` (no separator); MD5 the UTF-8 bytes; hex-encode lowercase (32 chars).
-  Example (`CreditScore` boundary `740`): `md5("CreditScore740")` = `f3b5ae55316f2fb03e4b416d3b80940e`.
-- **`InputData` shape:** for a `NumberRange` column, the **band-boundary value as a string**
-  (`{"CreditScore":"0"}`, `{"CreditScore":"740"}` — NOT `{"min":0,"max":739}`; the boundary is the hashed
-  value). For `Text`, the literal value. `OutputData` carries the raw typed output (`{"IsSTP":true}`,
-  `{"docTypeLabel":"ApplicationForm"}`, `{"DataUsePurpose":"<id>"}`).
-- **Rows can only be inserted/deleted while the version is a draft (`IsEnabled=false`)** — an enabled
-  version rejects row DML. Set `IsEnabled=false` first. To change an existing row, DELETE then INSERT
-  (an in-place UPDATE is rejected by the matrix save-hook). To add rows to an already-enabled matrix,
-  disable the version (or append a new draft version — see step 4a), do the row DML, then re-activate.
-
-Verify with the `get-decision-matrix-rows` GET (or a SOQL on `CalculationMatrixRow`), then prove
-materialization with a live BRE lookup.
-
-**Activate — decision-matrix builder controller** (SOR
-`wizard-ui-industries-interaction-decisionmatrix-components`):
-
-| Purpose | Step | Endpoint |
-|---|---|---|
-| Activate a matrix version | `decision-matrix-version-controller-activate-d-m-version` | `PATCH /headless/invoke/industries/industries-interaction-decisionmatrix/activate-dmversion` (body `{decisionMatrixVersionId}`) |
-
-Related builder ops exist (`get-decision-matrix-definition-id`, `create-new-dmversion`,
-`is-missing-columns-in-dm`) but `create-new-dmversion` needs an existing anchor version, so it is for
-adding a **second** version to an already-built matrix, not the initial build.
-
-## Create-or-reuse algorithm
-
-1. **Resolve existing.** SOQL `CalculationMatrix` by exact `Name`. If found, capture its id and its
-   latest `CalculationMatrixVersion`; read its columns/rows via the Connect GETs. Do not create a
-   duplicate merely because an id was not handed in. (`GET /connect/omnistudio/decision-matrices` search
-   is gated by `orgHasInteractionCalculationAccess` and may 400 — fall back to SOQL.)
-2. **Create the matrix if absent.** Insert a `CalculationMatrix` sObject with the requested `Name`.
-   Capture `matrixId`. **PATCH `Type = "Standard"`** and confirm the version's derived `MatrixType` reads
-   `Standard` (not null) — this is the step that makes the matrix evaluable at runtime.
-3. **Add columns (with `NumberRange` banding).** Call `post-decision-matrix-columns` with the full column
-   contract — including `rangeValues` on any `NumberRange` input column, because it cannot be set later —
-   then confirm with `get-decision-matrix-columns`. This auto-creates version 1 — read its id from
-   `CalculationMatrixVersion` (filter on `CalculationMatrixId`). Set input attributes on input columns
-   only.
-4. **Add rows by direct sObject insert.** For the auto-created draft version 1, insert each
-   `CalculationMatrixRow` with `CalculationMatrixVersionId`, the MD5-hash `Name`, `InputData`
-   (`NumberRange` = boundary-scalar string, `Text` = literal), and `OutputData` (raw typed value). Confirm
-   with the `get-decision-matrix-rows` GET (or SOQL) that every row round-trips. The version must be a
-   draft (`IsEnabled=false`) for the insert; the auto-created v1 is a draft until you activate it.
-   4a. **Editing rows on an already-enabled matrix.** If the target version is enabled, set
-   `IsEnabled=false` first (or append a new draft `CalculationMatrixVersion` — the `create-new-dmversion`
-   clone API returns "Cannot create definition record" on sObject-created matrices, so a direct version
-   insert with `IsEnabled=false` and the next `VersionNumber` is the fallback), do the row DML
-   (DELETE+INSERT to change a row — in-place UPDATE is rejected by the save-hook), then re-activate.
-5. **Activate.** Call `activate-dmversion` with the version id, then re-read the
-   `CalculationMatrixVersion`. Activation is confirmed when `StartDateTime` is set and `EndDateTime` is
-   null (there is no `Status` field on the version and no `ActiveVersionId` on the matrix). A 200 alone
-   is not proof — require the fresh read.
-5a. **Prove runtime materialization.** Call the live BRE lookup
-   `POST /connect/business-rules/decision-matrices/{Name}` with a representative input and confirm it
-   returns the expected output (not "there isn't any output for the specified input parameters"). An
-   Active window with a failing lookup means the rows did not materialize — revisit step 4.
-6. **Setup checkpoint fallback.** If `activate-dmversion` is rejected or the version never shows an
-   active window, stop at the Setup checkpoint: App Launcher → Business Rules Engine → Lookup Tables →
-   open the matrix → open the version → Save and Activate. Resume only after re-reading the active
-   window. Do not report an in-progress or draft matrix as active.
-
-## Idempotency and rollback
-
-- Reuse an exact-match matrix (same columns, same header/data types) and exact-match rows.
-- Do not create suffixed duplicates such as `IsSTPApplication2` automatically. On a shape mismatch,
-  stop and present the diff.
-- Rollback for rows added by this run is a targeted removal; do not delete a matrix that a feature or
-  OmniScript already depends on without explicit approval.
-
-## Output contract
-
-Return matrix Name, `CalculationMatrix` id (`0lI…`), `CalculationMatrixVersion` id (`0lN…`), active
-status (the version's `StartDateTime`/`EndDateTime` window), the verified column list (with
-header/data types), and the verified row set. These IDs are the handoff back to the calling feature
-sibling.
-
-## Definition of done
-
-The requested matrix exists exactly once as a `CalculationMatrix`, carries the exact columns and rows
-supplied by the feature sibling, its version reads active (StartDateTime set, EndDateTime null) on a
-fresh read, **and a live BRE lookup against the matrix returns the expected output** (proving the rows
-materialized into the runtime index). A matrix that is Active but whose lookup returns "no output for the
-specified input" is NOT done. A manual activation checkpoint left incomplete means this sibling is
-partial.

package/skills/fsc-digital-origination-bre-disclosures-consent-configure/SKILL.md

@@ -1,106 +0,0 @@
----
-name: fsc-digital-origination-bre-disclosures-consent-configure
-parent: "digital-origination-bre-setup"
-purpose: "Set up disclosure and consent for a lending product via a decision matrix, a data use purpose, and an authorization form."
-description: "Set up Disclosures and Consent for Digital Lending: a Business Rules Engine decision matrix that matches a lending product and applicant type to the data use purpose that defines why consent and disclosure are collected, plus the supporting home loan product, Data Use Purpose record, and locale-scoped Authorization Form. Drives the shared decision-matrix-foundation sibling for the matrix, and handles the Data Use Purpose and Authorization Form objects through standard sObject REST with describe-first discovery. Never invents disclosure text, products, or applicant types."
-metadata:
-  version: "1.0"
----
-
-# Digital Origination disclosure and consent
-
-Automate which disclosure-and-consent applies to a lending application. A decision matrix matches the
-lending product and applicant type to a **Data Use Purpose** record (the reason consent and disclosure
-are collected); an **Authorization Form** holds the locale-scoped text the applicant sees. This sibling
-owns the consent matrix and its supporting records. It does not create OmniScripts or document types.
-
-Source: Salesforce Help "Disclosure and Consent for Digital Lending" and its use-case example. Concept:
-*disclosure* is information the institution must share with a customer; *consent* is the permission the
-customer grants the institution to act on their behalf.
-
-## Required inputs
-
-- Target-org alias and acting admin.
-- The lending Product (create or reuse) and the applicant type (the example uses `Primary Applicant`).
-- The Data Use Purpose definition — the business reason for collecting consent/disclosure.
-- The disclosure-and-consent text and its locale (the example uses English).
-
-Help-article values are examples, never customer defaults. A missing product, purpose, or text is a
-user decision, not something to infer.
-
-## Decision matrix contract
-
-Drive nested `decision-matrix-foundation` to create and activate a decision matrix with:
-
-| Column header (apiName) | columnType | dataType |
-|---|---|---|
-| `ProductId` | `Input` | `Text` |
-| `ApplicantType` | `Input` | `Text` |
-| `Level` | `Input` | `Text` |
-| `DataUsePurpose` | `Output` | `Text` |
-
-Use the exact `CalculationMatrixColumn` enum tokens (`Input`/`Output`, `Text`); do not submit English
-labels. The `DataUsePurpose` output cell holds the activated Data Use Purpose Id.
-
-## Supporting records (sObject REST, describe-first)
-
-The Data Use Purpose and Authorization Form objects have no dedicated corpus SOR. Handle them through
-standard sObject REST, describing each object first and binding only to field API names the describe
-returns. Never guess a field name from a UI label. Org-verified objects on a Digital Lending org:
-`DataUsePurpose` (`0ZW`, has `IsActive`), `AuthorizationForm` (`0cI`, has `DefaultAuthFormTextId`,
-`EffectiveFromDate`/`EffectiveToDate`), `AuthorizationFormText` (`0cN`, has `Locale`/`LocaleSelection`
-picklists — English is `en_US` — plus `IsActive` and `DetailAuthorizationFormText`), and the
-`AuthorizationFormDataUse` junction (`0cM`, links `AuthorizationFormId` + `DataUsePurposeId`).
-
-**Order matters — each step gates the next (org-verified):**
-
-1. **Product.** Reuse an existing lending product or create one (`Product2`) with the admin-approved
-   Name, Product Code, and Active = true. Capture its Id.
-2. **Data Use Purpose.** Query for an existing record matching the approved purpose before creating
-   one. Create it with the approved definition (do not activate it yet — activation fails until it is
-   linked to an Authorization Form). Capture its Id.
-3. **Authorization Form.** Create the `AuthorizationForm`.
-4. **Authorization Form Text.** Create an `AuthorizationFormText` with `Locale`/`LocaleSelection` =
-   `en_US`, `IsActive` = true, and the approved disclosure-and-consent text in
-   `DetailAuthorizationFormText`.
-5. **Set the form's default text.** Update the `AuthorizationForm.DefaultAuthFormTextId` to the text
-   created in step 4. The next step fails ("Authorization Form doesn't have default text assigned") if
-   this is skipped.
-6. **Link form to purpose.** Create the `AuthorizationFormDataUse` junction referencing the form and the
-   Data Use Purpose.
-7. **Activate the Data Use Purpose** (`IsActive` = true) and confirm with a fresh read. This fails
-   ("must be associated with an Authorization Form") if the junction in step 6 is missing.
-
-If describe shows either object is not present in the target org, stop and report it as a blocker
-(missing feature/package artifact) rather than deploying an ad-hoc custom object.
-
-## Matrix row
-
-After the supporting records exist and the Data Use Purpose is active, hand the row to
-`decision-matrix-foundation`:
-
-- `ProductId` = the created/reused Product Id
-- `ApplicantType` = the approved applicant type (example: `Primary Applicant`)
-- `Level` = the application-form product level (example: `ApplicationFormProduct`)
-- `DataUsePurpose` = the activated Data Use Purpose Id
-
-Then activate the matrix through `decision-matrix-foundation` and confirm Active on a fresh read.
-
-## Idempotency and rollback
-
-- Reuse an exact-match product, purpose, form, and matrix row rather than creating duplicates.
-- Do not silently overwrite differing disclosure text or a differing purpose; present current vs
-  requested and ask.
-- Rollback removes only records created by this run, and only after confirming no active matrix row or
-  application depends on them.
-
-## Output contract
-
-Return the Product Id, Data Use Purpose Id and active status, Authorization Form Id and locale, the
-matrix Name/ID/version with its verified row, and the activation evidence.
-
-## Definition of done
-
-The consent decision matrix is Active with the linking row, the Data Use Purpose is active, and the
-Authorization Form exists with the English locale and is linked to the purpose. Any missing object or
-unresolved checkpoint is reported; a partial run is never reported as complete.

package/skills/fsc-digital-origination-bre-document-upload-configure/SKILL.md

@@ -1,96 +0,0 @@
----
-name: fsc-digital-origination-bre-document-upload-configure
-parent: "digital-origination-bre-setup"
-purpose: "Set up the document-upload decision matrix that maps a lending product and applicant type to the document types an applicant must upload."
-description: "Set up Document Upload for Digital Lending: a Business Rules Engine decision matrix that determines which document types an applicant must upload based on the lending product, applicant type, and level, returning a document type label. Drives the shared decision-matrix-foundation sibling for the matrix, and reuses the approved Document Type and Document Category entity SORs for the supporting metadata. Resolves and reuses existing document types by API name, and never invents products, applicant types, or document types."
-metadata:
-  version: "1.0"
----
-
-# Digital Origination document upload
-
-Determine which document types an applicant must upload for a lending application. A decision matrix
-matches the lending product, applicant type, and level to a document type label. This sibling owns the
-document-upload matrix and its supporting document-type metadata. It does not create consent records or
-OmniScripts.
-
-Source: Salesforce Help "Create a Decision Matrix for Digital Lending" (document upload). The example
-matches a home loan product and applicant type to the document types required for the application.
-
-## Required inputs
-
-- Target-org alias and acting admin.
-- The lending Product (create or reuse).
-- The applicant type (the example uses `Primary Applicant`) and level (example: `ApplicationFormProduct`).
-- The Document Type(s) an applicant must upload, with their exact API names.
-
-Help-article values are examples, never customer defaults.
-
-## Decision matrix contract
-
-Drive nested `decision-matrix-foundation` to create and activate a decision matrix (the example names it
-`LendingDocumentTypes`) with:
-
-| Column header (apiName) | columnType | dataType |
-|---|---|---|
-| `productId` | `Input` | `Text` |
-| `applicantType` | `Input` | `Text` |
-| `level` | `Input` | `Text` |
-| `docTypeLabel` | `Output` | `Text` |
-
-Use the exact `CalculationMatrixColumn` enum tokens (`Input`/`Output`, `Text`); do not submit English
-labels.
-
-## Supporting metadata (reuse Document Type / Document Category entity SORs)
-
-Reuse the approved entity SORs rather than deploying custom objects (find each with `discover`, then
-`describe` it for its operations):
-
-- The **Document Type** entity SOR — `describe`, `list`, `get-by-id`, `create`, `update`.
-- The **Document Category** entity SOR — same operations, for the category the type belongs to.
-- The **Document Category Document Type** entity SOR — the junction linking a category to a type, when
-  the org models that relationship.
-
-1. **Product.** Reuse or create the lending `Product2` (Name, Product Code, Family/Type, Active) and
-   capture its Id.
-2. **Document Type.** Query `DocumentType` (`list` / by name) for an existing type matching the required
-   document. If present, capture its **API name** and reuse it. If absent, `create` it with the approved
-   values, and create/link its `DocumentCategory` and `DocumentCategoryDocumentType` where the org
-   requires the category relationship. Save each Document Type's API name for the matrix row.
-
-Do not invent a document type from a UI label; resolve the API name from the create/describe response.
-
-**If the `DocumentType` sObject is not present on the org** (org-observed: not all Digital Lending orgs
-have it), the matrix still builds — `docTypeLabel` is a free `Text` output column, so populate it with
-the intended label string and report the missing `DocumentType` object as a supporting-metadata gap
-rather than deploying a custom object.
-
-## Matrix row
-
-Hand the row to `decision-matrix-foundation` after the product and document type(s) exist:
-
-- `productId` = the created/reused Product Id
-- `applicantType` = the approved applicant type (example: `Primary Applicant`)
-- `level` = the level (example: `ApplicationFormProduct`)
-- `docTypeLabel` = the Document Type API name saved above
-
-Add one row per required product / applicant-type / document-type combination. Then activate the matrix
-through `decision-matrix-foundation` and confirm Active on a fresh read.
-
-## Idempotency and rollback
-
-- Reuse an exact-match product, document type, and matrix row rather than creating duplicates.
-- Do not silently overwrite a differing document type; present current vs requested and ask.
-- Rollback removes only records created by this run, and only after confirming no active matrix row
-  depends on them. Never auto-delete a shared Document Type or Category.
-
-## Output contract
-
-Return the Product Id, the Document Type API name(s) and IDs (with any Category / junction IDs), and the
-matrix Name/ID/version with its verified row(s) and activation evidence.
-
-## Definition of done
-
-The document-upload decision matrix is Active with the intended row(s), and every referenced Document
-Type exists and is linked through the row. Any missing metadata or unresolved checkpoint is reported; a
-partial run is never reported as complete.