@salesforce/afv-skills 1.65.0 → 1.65.1

package/skills/fsc-stage-management-decision-matrices-create/SKILL.md

@@ -1,107 +0,0 @@
----
-name: fsc-stage-management-decision-matrices-create
-parent: "digital-origination-stage-management-setup"
-purpose: "Create and activate the three stage-management decision matrices that map an application form product stage to CDS access, applicant visible status, and application form stage."
-description: "Create and activate the three Business Rules Engine decision matrices that drive Compliant Data Sharing for Stage Management: HomeLoan_CDS_Config (stage to participant access levels), AFPStage_To_ApplicantVisibleStatus (stage to the applicant-facing visible status), and AFPStage_To_AFStage (application form product stage to the parent application form stage). All three are Standard decision matrices keyed on the ApplicationFormProductStage input with Text columns. Reuses the shared digital-origination-bre-setup decision-matrix-foundation machinery (a CalculationMatrix sObject with Type set to Standard, MD5-hash rows, and activate-dmversion). Never invents the customer's stage values or access policy."
-metadata:
-  version: "1.0"
----
-
-# Digital Origination Stage Management — decision matrices
-
-Build the three decision matrices the CDS Apex reads on every stage transition. Each is keyed on the new
-`ApplicationFormProductStage` value and returns the decisions that drive access and status. This sibling
-owns the three matrices' column and row contracts; it delegates the actual create/populate/activate
-mechanics to the shared decision-matrix foundation.
-
-Source: Salesforce Help "Create Decision Matrix for Digital Lending" (stage management). Prerequisite:
-Business Rules Engine is set up and Context Service is enabled (the `permissions` sibling confirms this).
-
-## Reuse the shared foundation — do not re-derive the mechanics
-
-These are the same Business Rules Engine decision matrices `digital-origination-bre-setup` builds. Delegate
-the create/columns/rows/activate lifecycle to the shared sibling SOR
-`fsc-mandalorians/digital-origination-bre-setup-decision-matrix-foundation`, which owns the org-verified
-recipe:
-
-- The matrix is a **`CalculationMatrix`** sObject (key prefix `0lI`), **not** `DecisionMatrixDefinition`.
-- Immediately after insert, PATCH **`Type = "Standard"`** — a null `Type` makes the derived version
-  `MatrixType` null and the runtime lookup throws "Unsupported Matrix type null" (surfaced as "no output
-  for the specified input").
-- Columns via the BRE Taurus Connect API (`post-decision-matrix-columns`), which auto-creates version 1.
-  All columns here are `Text` — no `NumberRange` banding is needed.
-- Rows by direct `CalculationMatrixRow` sObject insert with the engine's MD5-hash `Name` (over the input
-  columns only), into a draft version (`IsEnabled=false`).
-- Activate via `activate-dmversion`, then prove with a live
-  `POST /connect/business-rules/decision-matrices/{Name}` lookup that returns the expected output.
-
-Pass each matrix's exact Name, its column contract, and its rows to the foundation sibling. All three
-matrices share the single input column `ApplicationFormProductStage` (`Input`, `Text`).
-
-## Matrix 1 — `HomeLoan_CDS_Config`
-
-Maps a stage to the participant access each side gets. Columns:
-
-| Column (apiName) | columnType | dataType |
-|---|---|---|
-| `ApplicationFormProductStage` | `Input` | `Text` |
-| `Underwriter_Access` | `Output` | `Text` |
-| `Applicant_Agent_Access` | `Output` | `Text` |
-
-Rows: one per stage the admin defined. Each output cell is a comma-separated list of participant-role API
-names (must match the roles the `compliant-data-sharing` sibling created), e.g. `Applicant_Agent_Access`
-= `ApplicationFormRW, ApplicationFormProductRW, PartyProfileRW` and `Underwriter_Access` =
-`ApplicationFormNoAccess, ApplicationFormProductNoAccess, PartyProfileNoAccess` at Intake. The article's
-example (bankers RW / underwriters NoAccess at Intake; the reverse at Contract Generation; underwriters
-NoAccess at Auto Approved/Auto Rejected) is illustrative — use the admin's approved access policy.
-
-## Matrix 2 — `AFPStage_To_ApplicantVisibleStatus`
-
-Maps a stage to the applicant-facing status shown on the record. Columns:
-
-| Column (apiName) | columnType | dataType |
-|---|---|---|
-| `ApplicationFormProductStage` | `Input` | `Text` |
-| `ApplicantVisibleStatus` | `Output` | `Text` |
-
-Rows map each stage to its applicant-visible label (article examples: Book to Core → Loan Booked; the
-Rejected stages → Rejected; the Approved stages → Approved; In Review → In Review; Submitted →
-Submitted). Use the admin's values.
-
-## Matrix 3 — `AFPStage_To_AFStage`
-
-Maps the application-form-product stage to the parent application-form stage. Columns:
-
-| Column (apiName) | columnType | dataType |
-|---|---|---|
-| `ApplicationFormProductStage` | `Input` | `Text` |
-| `ApplicationFormStage` | `Output` | `Text` |
-
-Rows roll product stages up to the coarser form stages (article examples: Signature Complete / Awaiting
-Signature / Contract Generation → Closing; the Approved/Rejected stages → Decision; Need More Info / In
-Review / Submitted → Submitted; Intake → Intake; Book to Core → Book to Core). Use the admin's values.
-
-## Ordering and idempotency
-
-- The input token in every row's `InputData` is the stage string (`{"ApplicationFormProductStage":"Intake"}`);
-  the MD5-hash `Name` is computed over that input column only (delegated to the foundation sibling).
-- Build all three matrices; each is independent but all share the same input column name.
-- Reuse an exact-match matrix (same Name, columns, and rows) rather than creating a duplicate. On a shape
-  mismatch, present the diff and stop.
-- The output tokens must line up with the artifacts they name — the role lists in `HomeLoan_CDS_Config`
-  must be roles the `compliant-data-sharing` sibling created, and the stage/status values must match the
-  `ApplicationFormProduct.Stage` picklist and the applicant-status field. Cross-check before activating.
-
-## Output contract
-
-For each of the three matrices return the Name, `CalculationMatrix` Id (`0lI…`),
-`CalculationMatrixVersion` Id (`0lN…`), the active window (StartDateTime set, EndDateTime null), the
-verified columns and rows, and a live BRE lookup result proving the matrix evaluates for a representative
-stage.
-
-## Definition of done
-
-All three matrices (`HomeLoan_CDS_Config`, `AFPStage_To_ApplicantVisibleStatus`, `AFPStage_To_AFStage`)
-exist as `CalculationMatrix` records with `Type="Standard"`, carry the admin's stage rows, read active on
-a fresh read, and each returns its expected output from a live BRE lookup. A matrix that is Active but
-whose lookup returns "no output" is NOT done. A partial run is never reported as complete.

package/skills/fsc-stage-management-definition-assignments-create/SKILL.md

@@ -1,189 +0,0 @@
----
-name: fsc-stage-management-definition-assignments-create
-parent: "digital-origination-stage-management-setup"
-purpose: "Create and activate a Stage Definition Assignment rule group that binds the reference object (+ optional record type) to the active default stage definition, with optional priority-ordered criteria rules that route records to different definitions."
-description: "REQUIRED final step of the Digital Lending stage-management journey. After the stage definition and transitions are active, always create and activate a StgAssignmentRuleGrp that binds the reference object (ApplicationFormProduct) — optionally scoped to a record type — to the active StageDefinition as its default, so record-to-definition resolution runs through the assignment layer rather than an implicit direct binding. Do it directly; do not ask whether it is needed and do not skip it. When the admin supplies a multi-definition routing spec, additionally add the priority-ordered criteria rules that route matching records to a different definition. Authored against the IndustriesStageAssignmentDefinition StageAssignmentSetupController Aura ops and org-verified end-to-end on a live org. Never invents the customer's routing rules; never overwrites a pre-existing group that already points at a different definition."
-metadata:
-  version: "1.0"
----
-
-# Digital Origination Stage Management — stage definition assignments
-
-Assign **which** stage definition governs a record. A *Stage Definition Assignment* is a rule group
-(`StgAssignmentRuleGrp`) that binds a reference object (optionally scoped to a record type) to a
-**default** stage definition, plus optional priority-ordered **criteria rules** (`StgAssignmentRule`)
-that route records to a *different* definition when their field values match. It is the runtime
-dispatcher that sits in front of the `StageDefinition`(s) for the same object.
-
-> **This step is REQUIRED and runs as the final step of the Digital Lending journey.** Create and
-> activate the assignment group directly — do not ask whether it is needed and do not skip it. In the
-> single-definition case the group binds `ApplicationFormProduct` to the one active `StageDefinition`
-> (the case the other six siblings build); this is additive and does not change how that definition
-> behaves — activating a group never modifies the underlying `StageDefinition` (org-verified). When the
-> admin has supplied a multi-definition routing spec, the same step also adds the criteria rules that
-> route matching records to a different definition.
-
-Source: Salesforce Help "Stage Management for Digital Lending" (stage definition assignment sub-articles)
-and the corpus SOR `itsm-arka/IndustriesStageAssignmentDefinition` (`StageAssignmentSetupController`).
-
-## What this step does
-
-Run it as the final step, directly, every time the journey completes stage transitions:
-
-1. Bind the reference object (`ApplicationFormProduct`, plus a record type if the admin scoped one) to
-   the active `StageDefinition` as the group's **default**, then activate the group.
-2. If — and only if — the admin supplied a routing spec for **two or more** definitions competing on the
-   same object (+ record type), add the priority-ordered criteria rules from that spec. Absent a routing
-   spec, a single default definition is the correct, complete result.
-
-Do not gate this behind a "do you need it?" question. The only inputs you must not invent are the
-customer's criteria rules — apply the admin's routing spec if one was given, otherwise stop at the
-default-definition binding.
-
-## Feature gate — read-only, no customer enable lever
-
-Stage Definition Assignments are gated by the **`StageMgmtAssignGroup`** org permission, which Salesforce
-**auto-backfills** for any org already entitled to `IndustriesStageManagement`. Because Step 1 of this
-family turns Stage Management on, the gate is already `true` by the time this step runs — proceed and
-create directly. Read the current state only to confirm, and do NOT try to turn it on:
-
-- Call `StageManagementSetupController.fetchInitialStageManagementData` (the base controller) and read
-  **`isStageManagementAssignmentsEnabled`**; in the normal flow it is `true`.
-- `StageMgmtAssignGroup` is a **provisioned org permission** (owner ITSM Arka, `minApiVersion` 256). It is
-  **not** an org preference, **not** a Metadata `Settings` field, and **not** PermissionSet-grantable —
-  there is **no supported headless lever** to enable it. In the rare case it reads `false` (an org that is
-  not entitled to `IndustriesStageManagement`, which would already have blocked the earlier siblings),
-  report it as an **org-provisioning precondition/gap** — do not attempt to enable it and do not fabricate
-  a step for it. (Contrast `IndustriesStageMgmtPref`, which the `permissions` sibling *can* flip via the
-  OrgPreferences API — this perm is different.)
-
-## Prerequisites this step depends on
-
-- An **active** `StageDefinition` (`1DL…`) for the target reference object, from the `stage-definition` +
-  `stage-transitions` siblings. The assignment group's default (and each rule's target) references a real
-  definition **by its 18-char Id**, so the definition must exist first.
-- The reference object must be in the `supportedEntities` allowlist returned by
-  `fetchInitialStageManagementData` (ApplicationFormProduct is supported).
-- If scoping to a record type: the `ReferenceObjectRecordTypeId` (a `RecordType` Id) on that object.
-
-## Transport — Aura controller ops over `/headless/invoke` (dispatcher / MCP-dispatchable)
-
-Every operation below is a `StageAssignmentSetupController` Aura action resolved by the dispatcher. The
-wire call is `POST /services/data/vXX.0/headless/invoke` with an envelope
-{`"className": "...StageAssignmentSetupController", "action": "<op>", "params_schema": [ {name,type}… ],
-"body": { <param>: <value>… }`}; the response is `{status_code, body}` (unwrap the inner status). This is
-exactly what MCP `dispatch` builds, and it is org-verified over plain REST.
-
-**GOTCHA — `params_schema` is REQUIRED for every parameterized op.** A no-arg read
-(`fetchInitialStageManagementData`) resolves with just `{className, action}`, but create / update / delete
-MUST include `params_schema` listing every param, or the proxy returns
-`{errorCode: "NOT_IMPLEMENTED", message: "Controller not available"}` — which looks like "the op doesn't
-exist" but actually means "no method matched the (absent) arg schema". With `params_schema` present, the
-values go in `body` keyed by param name.
-
-| Op | action | Key params (all `body`, with `params_schema`) |
-|---|---|---|
-| Read feature flag + existing defs | `fetchInitialStageManagementData` (base controller) | none |
-| List supported entities | `fetchInitialStageManagementData` (assignment controller) | none |
-| Create rule group | `createStgAssignmentRuleGrp` | `name`, `devName`, `description`, `referenceObject`, `referenceObjectRecordTypeId`, `defaultStageDefinition` |
-| Activate / deactivate / edit group | `updateStgAssignmentRuleGrp` | `recordId`, `name`, `description`, `isActive` (Boolean), `defaultStageDef` |
-| Add criteria rules | `createStageAssignmentRuleCriteriaAndConditions` | `stgAssignmentRuleGrpId`, `stgAssignmentRuleRequests` (List) |
-| Edit criteria rules | `updateStageAssignmentRuleCriteriaAndConditions` | `stgAssignmentRuleGrpId`, `stgAssignmentRuleRequests` (List) |
-| Delete one rule entry | `deleteRuleEntry` | `stgAssignmentRuleGrpId`, `stgAssignmentRuleId` |
-| Delete the group | `deleteStgAssignmentRuleGrp` | `recordId` |
-
-**Field-value contract (org-verified — do not repeat these mistakes):**
-
-- **`defaultStageDefinition` (create) / `defaultStageDef` (update) is the StageDefinition *Id* (`1DL…`),
-  NOT its DeveloperName.** Passing the developer name returns
-  `CONTROLLER_ERROR "Stage Definition ID: id value of incorrect type: <devName>"` and creates nothing.
-  Note the param name differs between create (`defaultStageDefinition`) and update (`defaultStageDef`).
-- **A group is created INACTIVE** (`IsActive:false`). There is no activate flag on create; activation is a
-  separate `updateStgAssignmentRuleGrp {isActive:true}`. This is why create is inert until you explicitly
-  activate — and why create+delete is safe on a live org.
-- **Activating a group does NOT modify the underlying `StageDefinition`** (org-verified: the live
-  definition stayed active with an unchanged count while a group bound to it was activated). Activate only
-  after the group (and any intended criteria rules) is fully built.
-- **Read/verify via the Tooling API at v64.0+**, never the Data API and never v63.0. `StgAssignmentRuleGrp`
-  is a Tooling-family setup entity (`keyPrefix 1S9`, `minApiVersion` 256): a v63.0 SOQL/Tooling query
-  returns `sObject type 'StgAssignmentRuleGrp' is not supported` (a **version artifact**, not proof of
-  absence), and the plain Data API never supports it. Query at v64.0+:
-  `SELECT Id, DeveloperName, MasterLabel, ReferenceObject, ReferenceObjectRecordTypeId, StageDefinitionId, IsActive FROM StgAssignmentRuleGrp`.
-  The controller has no "list groups" op, so the Tooling query is the read/idempotency path.
-
-## Workflow
-
-### Step 1 — Preflight: confirm the feature and capture the active definition
-
-Read `isStageManagementAssignmentsEnabled` via the base `fetchInitialStageManagementData`. In the normal
-flow it is `true` (Step 1 of this family already turned Stage Management on, and the gate auto-backfills).
-Capture the active `StageDefinition` Id(s) (`1DL…`) for the target reference object — that Id is the
-group's default. Only in the rare `false` case (an org not entitled to Stage Management) report the
-`StageMgmtAssignGroup` provisioning precondition and stop; there is no headless enable path.
-
-### Step 2 — Resolve existing rule groups (idempotency)
-
-Tooling-query (v64.0+) `StgAssignmentRuleGrp` filtered on the target `ReferenceObject` (and
-`ReferenceObjectRecordTypeId` if scoped). If a matching group already exists with the intended default
-definition, reuse it — do not create a duplicate. If a group already exists but points at a *different*
-default definition, do not overwrite it — leave the existing (working) group in place and report the
-divergence in the output contract, since silently repointing it could break a routing setup already in
-use.
-
-### Step 3 — Create the rule group
-
-When no matching group exists, `createStgAssignmentRuleGrp` with `name`, `devName`, `description`,
-`referenceObject` (e.g. `ApplicationFormProduct`), `referenceObjectRecordTypeId` (a RecordType Id or
-`null`), and `defaultStageDefinition` = the StageDefinition **Id** (`1DL…`, not the developer name). The
-group is created inactive.
-
-### Step 4 — (Data-driven) Add priority-ordered criteria rules
-
-Add criteria rules when — and only when — the admin supplied a multi-definition routing spec (records must
-route to a *different* definition based on field values): call
-`createStageAssignmentRuleCriteriaAndConditions` with `stgAssignmentRuleGrpId` and a
-`stgAssignmentRuleRequests` list — each entry a rule with its target stage definition, priority, and
-field/value criteria + conditions (the rule that matches highest priority wins; unmatched records fall
-through to the group's default). Never invent the customer's criteria — apply only the admin's routing
-spec. Absent a routing spec, the default-definition binding alone is the complete result.
-
-### Step 5 — Activate the group (do this LAST)
-
-Once the group and any criteria rules are built, `updateStgAssignmentRuleGrp {recordId, isActive:true, …}`
-(carry `name`/`description`/`defaultStageDef` = the def **Id**). Verify the group reads `IsActive=true`,
-and re-confirm the target `StageDefinition`(s) are still active and unchanged.
-
-### Step 6 — Confirm
-
-Tooling-query the group back (v64.0+): `IsActive=true`, correct `ReferenceObject`,
-`ReferenceObjectRecordTypeId`, and `StageDefinitionId`; and each criteria rule present with its intended
-priority/target. Confirm the underlying `StageDefinition`(s) still read active with unchanged counts.
-
-## Idempotency and rollback
-
-- Reuse an existing group/rule that matches the admin's spec by reference object (+ record type); do not
-  duplicate. If a pre-existing group points at a different definition, leave it untouched and report it —
-  never silently overwrite a working routing setup.
-- Rollback removes only what this run created and only after confirming no active application depends on
-  the assignment routing: deactivate first (`updateStgAssignmentRuleGrp {isActive:false}`), then delete
-  the group via `deleteStgAssignmentRuleGrp {recordId}` (org-verified; the Tooling
-  `DELETE /services/data/v67.0/tooling/sobjects/StgAssignmentRuleGrp/{1S9id}` is an equivalent fallback).
-  Individual criteria rules are removed with `deleteRuleEntry {stgAssignmentRuleGrpId, stgAssignmentRuleId}`.
-
-## Output contract
-
-Return the created/reused rule group (Id, developer name, reference object, record type, default
-StageDefinition Id, active state), any criteria rules with their priorities and target definitions, and a
-fresh Tooling read confirming the group is active and bound — plus confirmation that the underlying
-`StageDefinition`(s) remain active and unchanged. If a pre-existing group pointed at a different
-definition and was left in place, report that divergence explicitly.
-
-## Definition of done
-
-`isStageManagementAssignmentsEnabled` is `true`; a `StgAssignmentRuleGrp` for the target reference object
-(+ record type) exists with the intended default StageDefinition **Id**, reads `IsActive=true` on a fresh
-Tooling query (v64.0+), and every referenced `StageDefinition` remains active; and, when the admin
-supplied a multi-definition routing spec, its criteria rules are present with their priorities and target
-definitions. In the rare case the feature reads `false`, this step stops at the provisioning precondition
-and reports it — it does not attempt to enable `StageMgmtAssignGroup`. A partial run (a created-but-inactive
-group, or a group missing an admin-specified rule) is never reported as complete.

package/skills/fsc-stage-management-definition-create/SKILL.md

@@ -1,108 +0,0 @@
----
-name: fsc-stage-management-definition-create
-parent: "digital-origination-stage-management-setup"
-purpose: "Create and activate the Digital Lending stage definition on the Application Form Product Stage field."
-description: "Create the stage definition that Stage Management for Digital Lending governs: a StageDefinition record (key prefix 1DL) named Digital Lending Stage Management, with Reference Object set to Application Form Product and Reference Object Field set to Stage. This is the definition the Stage Management Builder loads via its stateDefId parameter and that the stage transitions attach to. Reuses the corpus IndustriesStageDefinitions setup operations and the stage-management builder wizard SOR. Resolves an existing definition by exact name before creating one and confirms it with a fresh read."
-metadata:
-  version: "1.0"
----
-
-# Digital Origination Stage Management — stage definition
-
-Create the stage definition that restricts the `Stage` field on `ApplicationFormProduct`. This is the
-`StageDefinition` record (key prefix `1DL`) the Stage Management Builder opens via its `stateDefId`
-parameter (e.g. `builder_industries_stagemgmt/stageManagementBuilder.app?stateDefId=1DL...`). This sibling
-owns creating the definition shell **and its stage values (inactive)**; the `stage-transitions` sibling
-adds the transitions and rules and performs the **final activation** (activation only succeeds after
-≥1 transition exists — see that sibling).
-
-Source: Salesforce Help "Create a Stage Definition for Digital Lending".
-
-## Inputs
-
-- Target-org alias and acting admin.
-- Definition Name (the article uses `Digital Lending Stage Management`).
-- Reference Object = `ApplicationFormProduct`.
-- Reference Object Field = `Stage`.
-
-The `Stage` field must already carry the admin's picklist values (Intake, Submitted, In Review, the
-Approved/Rejected stages, Contract Generation, etc.) before transitions can reference them. Confirm the
-picklist is non-empty first.
-
-**`Intake` is the entry stage — always create it.** Every `ApplicationFormProduct` starts life at
-`Intake` (it is the seeded starting `Stage` on the sample record, and the first stage in the default
-flow), so an `Intake` `StageValue` MUST exist regardless of how the admin customizes the later stages.
-Create it first (the lowest-sequence `StageValue`); the `stage-transitions` sibling then defines the
-move out of it (`Intake → Submitted`) as the entry transition.
-
-## Naming note: StageDefinition vs StateDefinition
-
-The public/API entity is **`StageDefinition`** (key prefix `1DL`), but the builder app and its LWCs refer
-to it internally as **`StateDefinition`** — the URL parameter is `stateDefId` and the internal field is
-`definitionId`. They are the same record. Address it as a `StageDefinition` in queries; expect
-`stateDefId` in builder deep-links.
-
-## Reusable operations
-
-Use the **Industries Stage Definitions** setup SOR (find it with `discover`, then `describe` it),
-backed by the Stage Management setup controller via the Headless360 dispatcher:
-
-- `check-pick-list-non-empty` — confirm the `Stage` field on `ApplicationFormProduct` has picklist values
-  before creating the definition.
-- `fetch-all-stage-definition-versions` / `fetch-initial-stage-management-data` — resolve an existing
-  definition by name (reuse rather than duplicate).
-- `create-stage-mgmt-def-and-fetch-records` — create the stage definition (Name, Reference Object,
-  Reference Object Field) and read back the created record.
-- `update-stage-definition` / `update-stage-mgmt-def` — adjust the definition if it exists but differs.
-- `fetch-stage-values` — read the stage values the definition exposes.
-
-The builder wizard SOR `builders/fsc-rolex/ui-industries-stage-mgmt-components`
-(`wizard-ui-industries-stage-mgmt-components`) provides the builder-canvas operations
-(`util-create-stage-def-options`, `util-stage-def-modal`, `util-template-stage-def-modal`,
-`util-stage-mapping-body`) if the definition is created through the builder UI flow rather than the
-setup controller directly.
-
-## Workflow
-
-1. Confirm the `Stage` picklist on `ApplicationFormProduct` is non-empty (`check-pick-list-non-empty`).
-   If empty, stop and report a blocker — transitions need the stage values.
-2. Resolve an existing `Digital Lending Stage Management` definition by name. If found with the right
-   reference object and field, reuse it; on a mismatch, present the diff and stop.
-3. Create the definition with **Name (MasterLabel)** `Digital Lending Stage Management` and
-   **`DeveloperName` `Digital_Lending_Stage_Management` (REQUIRED — the create rejects a missing
-   developer name)**, Reference Object `ApplicationFormProduct`, Reference Object Field `Stage`
-   (`create-stage-mgmt-def-and-fetch-records`). That setup op pins `UsageType = STAGE_MANAGEMENT` for
-   you. The `StageDefinition` also accepts a direct sObject REST POST (org-verified) if the controller
-   op is unavailable — key prefix `1DL`; on the raw POST you MUST supply `DeveloperName` and set
-   `UsageType = 'STAGE_MANAGEMENT'` yourself. **Do NOT set `IsActive` at create — activation is the
-   last step and is owned by `stage-transitions` (it only succeeds after ≥1 transition exists).**
-4. **Create the `StageValue` records** — one per stage the admin defined — via direct sObject REST POST
-   to `StageValue`: `StageDefinitionId` (REQ, the `1DL…` id) + `Value` (the stage string, matching the
-   `ApplicationFormProduct.Stage` picklist). These `StageValue` ids (`1DE…`) are what the
-   `stage-transitions` sibling references as `FromStageValueId`/`ToStageValueId`, so they must exist
-   before transitions. (org-verified: 12 StageValues created this way on fsc-dop8.)
-5. Re-read the created `StageDefinition` and its `StageValue`s and confirm the Id (`1DL…`), reference
-   object, field, active status, and stage-value count.
-6. Hand the `StageDefinition` Id **and the `StageValue` id-per-stage map** to the `stage-transitions`
-   sibling.
-
-## Idempotency and rollback
-
-- Reuse an exact-match definition (same name, reference object, field); do not create a duplicate.
-- On a shape mismatch, present current vs requested and stop.
-- Do not delete a definition that already carries transitions or that an active application depends on
-  without explicit approval.
-
-## Output contract
-
-Return the `StageDefinition` Id (`1DL…`), Name, Reference Object, Reference Object Field, active status,
-and the created `StageValue` id-per-stage map (`1DE…` per stage string). The `StageDefinition` Id is the
-`stateDefId` for the builder deep-link; the `StageValue` map is the handoff to `stage-transitions`
-(source/target ids for each transition).
-
-## Definition of done
-
-The `Digital Lending Stage Management` stage definition exists exactly once as a `StageDefinition` on
-`ApplicationFormProduct` / `Stage`, reads back with the correct reference object and field on a fresh
-query, and a `StageValue` record exists for each of the admin's stages (fresh-read count matches). A
-manual builder checkpoint left incomplete means this sibling is partial.

package/skills/fsc-stage-management-permissions-assign/SKILL.md

@@ -1,143 +0,0 @@
----
-name: fsc-stage-management-permissions-assign
-parent: "digital-origination-stage-management-setup"
-purpose: "Assign the Stage Management and Digital Lending permission sets, turn on the Stage Management feature, and confirm Context Service is enabled."
-description: "Assign and verify the permission-set access required to configure and run Stage Management for Digital Lending, turn on the Stage Management feature, and confirm Context Service is enabled so the stage decision matrices can be evaluated. Handles the Digital Lending, Stage Management Design User, and Stage Management User access documented by the help articles. Reuses the approved PermSets SOR and standard assignment APIs, is idempotent on rerun, and never assigns access to inferred users or service accounts."
-metadata:
-  version: "1.0"
----
-
-# Digital Origination Stage Management permissions
-
-Prepare a specifically identified admin or runtime user for Stage Management, turn the feature on, and
-confirm Context Service is enabled so the stage decision matrices evaluate. This sibling manages access
-and two org-level enablements; it does not create matrices, records, CDS objects, or stage definitions.
-
-## Inputs
-
-- Explicit target-org alias
-- Explicit target user ID or username
-- Role: design-time admin (configure Stage Management), runtime user (progress records), or both
-
-Never select all active users. Never target Automated Process, integration, guest, or service users.
-
-## Required access matrix
-
-The help articles state the same permission surface. Resolve exact API names from the target org; labels
-can differ by release.
-
-| Role | Required product-supplied access |
-|---|---|
-| Set up Digital Lending | Digital Lending permission set |
-| Configure Stage Management (design time) | Stage Management Design User |
-| Run Stage Management for end users (runtime) | Stage Management User |
-
-Do not manufacture a custom replacement for a missing product-supplied set. Report a missing entitlement
-or package artifact as a blocker.
-
-## Reusable operations
-
-Use the **Permission Sets** entity SOR (find it with `discover`, then `describe` it for these operations):
-
-- `get-permission-set-details` — Tooling read of a permission set and its `Permissions*` fields.
-- `assign-users` — create `PermissionSetAssignment` using AssigneeId and PermissionSetId.
-- `unassign-users` — rollback an assignment created by this run.
-- `edit-assignment-expiration` — update an explicitly requested expiration.
-
-For any permission-set-license required by the selected sets, query and create
-`PermissionSetLicenseAssign` through standard sObject REST. Assign a missing license before its
-permission set.
-
-## Turn on Stage Management (headless — proven)
-
-The Stage Management feature is the org preference **`IndustriesStageMgmtPref`**, and it is set through
-the **generic Setup-Connect Org Preferences API** — there is no per-feature controller and no UI-only
-step. (The `IndustriesStageDefinitions` SOR's "no public setter" note is wrong; the toggle IS this
-generic OrgPreference, the same mechanism ITSM/CLM/Inventory settings use.)
-
-```text
-GET   /services/data/vXX.0/setup/org/preferences/IndustriesStageMgmtPref     -> {"isPreferenceEnabled": <bool>}
-PATCH /services/data/vXX.0/setup/org/preferences/IndustriesStageMgmtPref     body {"desiredState": true}   -> {"isPreferenceEnabled": true}
-```
-
-Enabling `IndustriesStageMgmtPref` provisions the eight Stage Management entities (`StageDefinition`,
-`StageValue`, `StageTransition`, `StageCriteria`, `StageCondition`, `StgFulfillmentStepDefGrp`,
-`StgFulfillmentStepDef`, `StgFulfillmentStepDpndDef`) into the org's data dictionary. Before it is on,
-those sObjects do not exist (`describe` 404s, absent from `EntityDefinition`) and `hasAccess` is false.
-
-**Steps:**
-
-1. GET the preference. If already `true`, skip (idempotent).
-2. PATCH `{"desiredState": true}` and confirm the response echoes `isPreferenceEnabled: true`.
-3. **Verify the feature actually provisioned** — do NOT trust the pref read-back alone. Call
-   `fetchInitialStageManagementData` (POST the dispatcher envelope, see below) and confirm
-   `hasAccess: true` and `ApplicationFormProduct` appears in `supportedEntities`. Optionally
-   `GET /sobjects/StageDefinition/describe` and confirm it returns `createable: true` instead of 404.
-
-Note on the dispatcher envelope for the Aura-backed reads/writes (`fetchInitialStageManagementData`,
-`create-stage-mgmt-def-and-fetch-records`, etc.): POST to the `/headless/invoke/...` path with body
-`{"className":"<className>","action":"<methodName>","params":{...}}`. The **fully-qualified** class name
-is required — a short name returns 501 "Controller not available". Do not hardcode it: take the exact
-`className` from the operation's route metadata (the resolved dispatch route for the op you are calling
-already carries it), so the envelope always matches the deployed controller.
-
-Enabling a feature is an org-wide change — report it and enable only after confirming the target org is
-the intended one. There is a companion pref `RulesReEvalForInactiveSD` (rules re-evaluation for inactive
-stage definitions) settable the same way if the admin wants it; leave it default unless asked.
-
-## Context Service enablement
-
-The stage decision matrices are Business Rules Engine decision matrices, which evaluate behind the
-Context Service feature family (`ContextResourceFamily`). When the gate is off, matrix evaluation returns
-HTTP 403 `FUNCTIONALITY_NOT_ENABLED`.
-
-Enable it headlessly via the Context Service Connect API — the `preferenceName` must be exactly
-`contextServiceEnabled`, and `uniqueIdentifier` is the 18-char Org Id:
-
-```text
-PUT /connect/contextservice/access/contextServiceEnabled/{orgId}  {"isEnabled":true}
-```
-
-If the family-level gate itself is not yet on, the PUT cannot reach the resource; stop at the Setup
-checkpoint **Context Service Settings → enable Context Definitions**
-(`/lightning/setup/ContextServiceSettings/home`) and resume after the admin confirms. Verify by calling
-the cheapest live endpoint (a decision-matrix read or a `GET /connect/context-definitions`) rather than
-trusting the preference read-back, which can lag.
-
-## Workflow
-
-1. Confirm org and target user. Query `User` and report username, profile, active state, and user type.
-2. Query `PermissionSet` by both `Name` and `Label` for every required access item. Capture Id,
-   LicenseId, NamespacePrefix, and IsOwnedByProfile.
-3. If more than one candidate matches, stop and ask; do not guess.
-4. Query any required `PermissionSetLicense` and existing `PermissionSetLicenseAssign`. Assign a missing
-   license before its permission set.
-5. Query existing `PermissionSetAssignment` records for the target user and candidate set IDs.
-6. Create only missing assignments. Treat `DUPLICATE_VALUE` as already assigned, then re-query.
-7. Re-read the assigned permission sets and assignments and verify each is attached to the intended user.
-8. Turn on Stage Management headlessly by PATCHing `IndustriesStageMgmtPref` to `desiredState:true`, then
-   verify the feature provisioned via `fetchInitialStageManagementData` (`hasAccess:true`) — not the pref
-   read-back alone.
-9. Confirm Context Service is enabled; if not, enable it as above and re-verify with a live endpoint.
-
-## Failure and rollback rules
-
-- Missing permission set or license: report the exact missing API/label and stop dependent steps.
-- License-limit failure: do not remove another user's license; report the limit.
-- Assignment failure: preserve successful pre-existing assignments; remove only assignments created by
-  this run and only when the user requests rollback.
-- Never edit a standard managed permission set.
-
-## Output contract
-
-Return a table with target user, role, permission-set API name/ID, license ID if applicable, prior
-state, action, and verified final state; the Stage Management feature enablement result; and the Context
-Service enablement result. Separate blockers from optional runtime-user access.
-
-## Definition of done
-
-Every required design-time or runtime assignment for the explicitly selected role is present and verified
-in fresh queries, Stage Management reads on (`IndustriesStageMgmtPref` enabled AND
-`fetchInitialStageManagementData` returns `hasAccess:true` with the eight entities provisioned), and
-Context Service reads enabled (or a Setup checkpoint is reported). No unrelated user or assignment was
-changed.