@salesforce/afv-skills 1.65.0 → 1.65.1

package/skills/fsc-digital-origination-product-setup-coordinate/SKILL.md

@@ -1,248 +0,0 @@
----
-name: fsc-digital-origination-product-setup-coordinate
-description: "Guided admin setup of the product-catalog data slice of Financial Services Cloud (FSC) Digital Lending — permission-set assignment, catalog + category/subcategory creation, Home Loan product creation, LoanTerm picklist values, MinLoanAmount / MaxLoanAmount / LoanTerm / OfferValidPeriod / OmniScriptName attribute definitions, Home Loans product classification with attribute assignment and default values, product-to- classification binding, and product-to-category assignment. Triggers on \"set up digital lending product catalog\", \"create digital lending catalog\", \"configure digital lending products\", \"create home loan product in FSC\", \"assign product classification for lending\", \"configure loan term attributes\", \"set up loan origination products\". This SKILL is the product-catalog slice only — initial setup (Discovery Framework + KYC + Digital Origination + Import/Export + Sample Templates + Manage User Access) is a prereq slice owned by the sibling digital-origination-initial-setup child."
-metadata:
-  version: "1.0"
----
-
-# digital-origination-product-setup
-
-Guide admin through product-catalog data creation for FSC Digital Lending: catalog,
-categories/subcategories, Home Loan product, LoanTerm picklist, five product
-attributes, Home Loans product classification with attributes + defaults, and
-category/classification assignments — in strict order the Salesforce Help doc prescribes.
-
-Source: [Create Catalogs and Products for Digital Lending](https://help.salesforce.com/s/articleView?id=ind.fsc_lending_catalogs_products.htm&type=5)
-(13 child articles). Every field name, default value, and step below is verbatim from that
-doc.
-
-## Scope & definition of done — READ THIS FIRST
-
-**This SKILL is one slice of a larger Digital Lending setup journey.** Slices:
-
-1. **Prereq slice — initial setup** (Discovery Framework, Know Your Customer, Digital Origination feature, Import or Export, Sample Templates, Manage User Access). Owned by sibling child: [`../digital-origination-initial-setup/SKILL.md`](../digital-origination-initial-setup/SKILL.md). MUST be complete before this SKILL runs.
-2. **THIS SKILL — product-catalog setup** (Acts 1–5 below).
-3. **Future slices** — data-mapper wiring, CPQ Fetch API integration, FlexCard config, pricing-engine wiring, GitHub sample-data loader path. Not covered here.
-
-**"Set up Digital Lending product catalog" / "Configure Digital Lending products" with no
-narrowing qualifier means running Acts 1–5 end-to-end.** Reporting done after just the
-catalog is a defect. "Out of scope" notes are NOT stop signals — call them out, then
-finish every non-blocked step.
-
-**End state.** Home Loan product visible on Product List FlexCard with LoanTerm /
-MinLoanAmount / MaxLoanAmount / OmniScriptName / OfferValidPeriod attributes populated,
-Based On = Home Loans classification, assigned to Home Loans category. Classification
-holds the five attributes with defaults MinLoanAmount=1000, MaxLoanAmount=100000,
-OmniScriptName=ApplicantIntakeSecured (Home Loan is a secured product; use ApplicantIntake
-for an unsecured loan), OfferValidPeriod=30.
-
-## Mandatory pre-write plan — state this before your FIRST write
-
-Before touching the org, restate to the admin:
-
-1. Target org alias (confirm).
-2. Prereq check — initial setup complete? Delegate to sibling initial-setup child if not.
-3. Perm-set check — which of the three required perm sets (DL, PCM Designer, PCM Viewer) are already assigned vs missing.
-4. Which acts you'll run (default: all 5). Route narrower asks per Entry Point table below.
-5. Split-deploy plan — one act at a time; re-read after each write; ground final report in Tooling reads.
-
-Do NOT proceed until the admin confirms.
-
-## Supported utterances
-
-- "Set up Digital Lending product catalog" / "Configure Digital Lending products"
-- "Create Digital Lending catalog and products"
-- "Create home loan product for Digital Lending"
-- "Assign product classification for lending"
-- "Configure loan term picklist / attributes for Digital Lending"
-- "Set up loan origination products in FSC"
-
-## Session state (track across the conversation)
-
-- `target_org_alias` — org being configured; confirmed before any write.
-- `prereq_initial_setup_verified` — did sibling initial-setup child's Definition of done pass.
-- `perm_sets_missing` — surfaced to admin; nothing assigned until confirmed.
-- `catalog_name`, `catalog_code`, `catalog_effective_start`, `catalog_effective_end`.
-- `category_names` — categories/subcategories (help-doc example: Home Loans).
-- `product_names` — products created (help-doc example: Home Loan).
-- `picklist_values_created` — LoanTerm 180/240/360 Months.
-- `attribute_defs_created` — MinLoanAmount, LoanTerm, MaxLoanAmount, OfferValidPeriod, OmniScriptName.
-- `classification_name` — e.g. Home Loans.
-- `classification_defaults_set` — MinLoanAmount=1000, MaxLoanAmount=100000, OmniScriptName=ApplicantIntake|ApplicantIntakeSecured, OfferValidPeriod=30.
-- `product_based_on_set`, `product_assigned_to_category`.
-- `considerations_surfaced` — Act 5 items acknowledged.
-
-## Entry point — route on the admin's actual ask
-
-| Admin ask signal | Where to start | What to run |
-|---|---|---|
-| "Set up Digital Lending product catalog" (unqualified) | Act 1 | Acts 1–5 in order |
-| "I already have perms — start with the catalog" | Act 2 | Verify Act 1 gate, then Acts 2–5 |
-| "Just create the catalog and categories" | Act 2 | Act 2 only; note remaining acts blocked |
-| "Create the Home Loan product and its attributes" | Act 3 | Verify Acts 1–2 gate, then Act 3 |
-| "Just define the attributes / picklist" | [`source/skills/act3-product-and-attributes/SKILL.md`](source/skills/act3-product-and-attributes/SKILL.md) | Act 3 sub-steps only |
-| "Set up the Home Loans product classification" | Act 4 | Verify Acts 1–3 gate, then Act 4 |
-| "Considerations / limits for DL catalog" | Act 5 | Read-only summary from [`source/references/considerations-and-limits.md`](source/references/considerations-and-limits.md) |
-| "Configure secured loan product (auto/home)" | Act 4 | Same as unsecured, but OmniScriptName default = ApplicantIntakeSecured |
-
-## Prerequisites
-
-### A. External — validate only (do not attempt to fix)
-
-- **Edition:** Lightning Experience — Professional, Enterprise, or Unlimited.
-- **License:** Financial Services Cloud with Digital Lending entitlement.
-- **Admin access** to the org.
-- **Initial setup complete** — delegate to [`../digital-origination-initial-setup/SKILL.md`](../digital-origination-initial-setup/SKILL.md). If any Step (Discovery Framework, KYC, Digital Origination, Import/Export, Sample Templates, Manage User Access) is missing, STOP and route the admin to that SKILL first.
-
-### B. Automatable — permission sets (Act 1)
-
-See [`source/references/permission-sets.md`](source/references/permission-sets.md) for the full matrix.
-
-**Policy: check → report → confirm → THEN assign. Never auto-assign.** Present the missing
-list with what each perm set unlocks. Assign only the ones the admin confirms.
-`DUPLICATE_VALUE` on assignment = already assigned = success, not an error.
-
-## Transport & deploy discipline
-
-1. **Dispatcher fallback.** Prefer typed APIs. When missing, fall back to `dispatch` with the raw route.
-2. **Dry-run first.** For every write, state the operationId + payload before invoking.
-3. **Split deploy per act.** One act at a time. Do not batch across acts.
-4. **Re-read verify.** After each write, re-read the record via Tooling / Query and confirm.
-5. **Ground final report in reads.** Never claim done from write success alone — read back.
-6. **Config ≠ data.** PCM records (catalog, category, product, picklist, attribute, classification) are DATA, not metadata. Do NOT MDAPI-deploy them. Use the PCM REST/Query APIs.
-
-## Setup journey — 5 acts
-
-Each act delegates to a sub-skill under [`source/skills/`](source/skills/). Sub-skills hold
-verbatim help-doc steps.
-
----
-
-### Act 1 — Permissions
-
-Assign Product Catalog Management Designer + Digital Lending + PCM Viewer perm sets to
-the users who configure Digital Lending.
-
-Delegate: [`source/skills/act1-permissions/SKILL.md`](source/skills/act1-permissions/SKILL.md)
-
-**End state.** All required perm sets assigned to the admin + any additional users the
-admin identifies.
-
----
-
-### Act 2 — Catalog + Categories/Subcategories
-
-Create the Digital Lending catalog (Sales type, effective dates, unique code). Under it,
-create the Home Loans category. Optionally create subcategories.
-
-Delegate: [`source/skills/act2-catalog-and-categories/SKILL.md`](source/skills/act2-catalog-and-categories/SKILL.md)
-
-**End state.** Catalog exists with name / description / unique code / effective start-end /
-type=Sales. At least one category (e.g. Home Loans) exists under the catalog.
-
----
-
-### Act 3 — Product + Attribute Picklist + Attribute Definitions
-
-Create the Home Loan product. Populate the LoanTerm attribute picklist (180 Months / 240
-Months / 360 Months). Define the five product attributes: MinLoanAmount, LoanTerm,
-MaxLoanAmount, OfferValidPeriod, OmniScriptName.
-
-Delegate: [`source/skills/act3-product-and-attributes/SKILL.md`](source/skills/act3-product-and-attributes/SKILL.md)
-
-**End state.** Home Loan product exists. LoanTerm picklist has three values. Five
-attribute definitions exist. See [`source/references/attributes-and-defaults.md`](source/references/attributes-and-defaults.md)
-for field-by-field detail.
-
----
-
-### Act 4 — Classification + Assignment
-
-Create the Home Loans product classification. Assign the five attributes and set
-defaults (MinLoanAmount=1000, MaxLoanAmount=100000, OmniScriptName=ApplicantIntakeSecured
-for the secured Home Loan — ApplicantIntake for an unsecured loan, OfferValidPeriod=30). Set the Home Loan
-product's Based On = Home Loans. Assign the product to the Home Loans category.
-
-Delegate: [`source/skills/act4-classification-and-assignment/SKILL.md`](source/skills/act4-classification-and-assignment/SKILL.md)
-
-**End state.** Classification exists with five attributes + defaults. Product's Based On
-points to classification. Product appears under Home Loans category.
-
----
-
-### Act 5 — Considerations & limits
-
-Surface the Salesforce Help considerations to the admin. Not a write step — an alignment
-step. Especially: 100-product FlexCard cap, no pagination, name/image/description dynamic
-from product, MinLoanAmount/MaxLoanAmount type=currency, LoanTerm=picklist in months,
-DigitalLendingTransFormProductInfo Data Mapper Transform must be updated if custom
-attributes are added beyond the five.
-
-Delegate: [`source/skills/act5-considerations/SKILL.md`](source/skills/act5-considerations/SKILL.md)
-Reference: [`source/references/considerations-and-limits.md`](source/references/considerations-and-limits.md)
-
-**End state.** Admin has acknowledged each consideration.
-
----
-
-## Definition of done (the whole skill)
-
-- Prereq initial setup verified via sibling initial-setup child.
-- Perm sets confirmed + assigned (Act 1).
-- Catalog + at least one category exist (Act 2).
-- Home Loan product + LoanTerm picklist (180/240/360) + five attribute definitions exist (Act 3).
-- Home Loans classification exists with five attributes + defaults set correctly for secured vs unsecured (Act 4).
-- Product Based On = Home Loans, product assigned to Home Loans category (Act 4).
-- Considerations surfaced (Act 5).
-- Final report grounded in Tooling reads, not just write responses.
-
-## Out of scope / deferred
-
-- **Initial setup** — prereq slice owned by sibling child ([`../digital-origination-initial-setup/SKILL.md`](../digital-origination-initial-setup/SKILL.md)).
-- **DigitalLendingTransFormProductInfo Data Mapper Transform** updates for custom attributes — referenced (Act 5) but not covered.
-- **CPQ Fetch product detail API integration**, Product List Page FlexCard, pricing-engine wiring.
-- **GitHub sample-data loader path** — alternate to hand-creating records.
-- **Other loan-product variants** beyond flagging OmniScriptName=ApplicantIntakeSecured.
-
-## Companion references
-
-- Prereq initial-setup child: [`../digital-origination-initial-setup/SKILL.md`](../digital-origination-initial-setup/SKILL.md)
-- Salesforce Help parent: [Create Catalogs and Products for Digital Lending](https://help.salesforce.com/s/articleView?id=ind.fsc_lending_catalogs_products.htm&type=5)
-- Salesforce Help: Product Catalog Management
-- Salesforce Help: Product Classifications
-- Salesforce Help: Dynamic Attributes
-- Salesforce Help: OmniScripts
-- Internal architecture: [`source/PLAN.md`](source/PLAN.md)
-
-<!-- skill-validate: ignore-start -->
-<!-- codey:operations start -->
-## Operations Reference
-
-Operations this skill uses — routing and dependency reference.
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `act1-query-permsets` | read | — | `GET /services/data/v63.0/query` | — |
-| `act1-query-existing-assignments` | read | — | `GET /services/data/v63.0/query` | `act1-query-permsets` |
-| `act1-assign-permset` | write | — | `POST /services/data/v63.0/sobjects/PermissionSetAssignment` | `act1-query-existing-assignments` |
-| `act2-create-catalog` | write | — | `POST /services/data/v63.0/sobjects/ProductCatalog` | — |
-| `act2-create-category` | write | — | `POST /services/data/v63.0/sobjects/ProductCategory` | `act2-create-catalog` |
-| `act2-create-subcategory` | write | — | `POST /services/data/v63.0/sobjects/ProductCategory` | `act2-create-category` |
-| `act3-create-product` | write | — | `POST /services/data/v63.0/sobjects/Product2` | — |
-| `act3-create-picklist` | write | — | `POST /services/data/v63.0/sobjects/AttributePicklist` | — |
-| `act3-create-picklist-value` | write | — | `POST /services/data/v63.0/sobjects/AttributePicklistValue` | `act3-create-picklist` |
-| `act3-activate-picklist` | write | — | `PATCH /services/data/v63.0/sobjects/AttributePicklist/{Id}` | `act3-create-picklist-value` |
-| `act3-create-attribute-def` | write | — | `POST /services/data/v63.0/sobjects/AttributeDefinition` | `act3-activate-picklist` |
-| `act3-activate-attribute-def` | write | — | `PATCH /services/data/v63.0/sobjects/AttributeDefinition/{Id}` | `act3-create-attribute-def` |
-| `act4-create-classification` | write | — | `POST /services/data/v63.0/sobjects/ProductClassification` | — |
-| `act4-activate-classification` | write | — | `PATCH /services/data/v63.0/sobjects/ProductClassification/{Id}` | `act4-create-classification` |
-| `act4-assign-attr-to-classification` | write | — | `POST /services/data/v63.0/sobjects/ProductClassificationAttr` | `act4-activate-classification`, `act3-activate-attribute-def` |
-| `act4-bind-product-basedon` | write | — | `PATCH /services/data/v63.0/sobjects/Product2/{Id}` | `act3-create-product`, `act4-activate-classification` |
-| `act4-assign-product-to-category` | write | — | `POST /services/data/v63.0/sobjects/ProductCategoryProduct` | `act3-create-product`, `act2-create-category` |
-| `delegate-digital-origination-product-setup-act1-permissions` | delegate | — | → `fsc-mandalorians/digital-origination-product-setup-act1-permissions` | — |
-| `delegate-digital-origination-product-setup-act2-catalog-and-categories` | delegate | — | → `fsc-mandalorians/digital-origination-product-setup-act2-catalog-and-categories` | — |
-| `delegate-digital-origination-product-setup-act3-product-and-attributes` | delegate | — | → `fsc-mandalorians/digital-origination-product-setup-act3-product-and-attributes` | — |
-| `delegate-digital-origination-product-setup-act4-classification-and-assignment` | delegate | — | → `fsc-mandalorians/digital-origination-product-setup-act4-classification-and-assignment` | — |
-| `delegate-digital-origination-product-setup-act5-considerations` | delegate | — | → `fsc-mandalorians/digital-origination-product-setup-act5-considerations` | — |
-<!-- codey:operations end -->
-<!-- skill-validate: ignore-end -->

package/skills/fsc-digital-origination-sample-data-create/SKILL.md

@@ -1,206 +0,0 @@
----
-name: fsc-digital-origination-sample-data-create
-description: "Create a minimal, clearly-tagged set of sample records so an admin can SEE the Digital Origination (Digital Lending) setup working end to end — the record graph the sibling `digital-origination-demo-run` skill drives to demonstrate Stage Management, the Business Rules Engine decision matrices, and pricing. Stands up one loan application (an ApplicationForm + ApplicationFormProduct seeded at the first stage + an ApplicationFormProductProposal with a loan amount / term / credit score, plus the PartyProfile participant records CDS grants access to) so a live stage transition, a BRE lookup, and a price simulation all have real inputs. Every record it creates is tagged with a shared run marker (a `DL_Test_` prefix where the Name is writable, and the run tag in a Description / external-id field where it is not) so the demo can find them and the teardown can delete exactly them. \"Create Digital Origination sample data\", \"make some test records to try the setup\", \"seed demo loan data\", \"give me records to test stage management / pricing / the BREs\", or \"set up sample data so I can see it work\" route here. Idempotent and resumable — it queries by the run marker first and creates only the records that are missing. This skill WRITES only the sample transactional records; it never re-runs any of the six setup acts. Digital Origination is the renamed Digital Lending feature; the underlying objects, org preferences, and APIs still carry the DigitalLending name."
-metadata:
-  version: "1.0"
----
-
-# Digital Origination — sample data setup
-
-Create the **smallest record graph that proves the setup works**, so an admin who just finished the
-six-act Digital Origination build can watch a real loan application move through the machinery they
-configured. This skill only creates transactional sample records; it does not enable features, assign
-permission sets, or re-run any setup act — those are done by the time this runs.
-
-Its output is consumed by the sibling `digital-origination-demo-run` skill, which drives these records
-to demonstrate Stage Management (the headline — a live, record-observable stage transition), the
-Business Rules Engine decision matrices, and pricing.
-
-## ⚠️ Naming: Digital Origination IS Digital Lending (read first)
-
-Digital Origination is the renamed Digital Lending feature. The customer-facing labels say "Digital
-Origination," but the objects and APIs you write against here — `ApplicationForm`,
-`ApplicationFormProduct`, `ApplicationFormProductProposal`, `PartyProfile`, the CDS participant records,
-the `LendingProductConfigContext` pricing context — still carry the `DigitalLending` lineage. Use the
-API names against the org; say "Digital Origination" to the admin.
-
-## Prerequisites (verify, do not fix here)
-
-This skill assumes the setup is already done. Verify — and if a prerequisite is missing, report it and
-stop rather than trying to create data on an unconfigured org:
-
-1. **Digital Origination Initial Setup is complete** — `ApplicationForm`, `ApplicationFormProduct`, and
-   `PartyProfile` are in use (Act 1).
-2. **A Home Loan product exists** (Act 2) — its `Product2` id is the `ProductId` the sample
-   `ApplicationFormProduct` and the price simulation reference. Query it by name; never invent a product id.
-3. **Stage Management is set up** (Act 6) — the `Digital_Lending_Stage_Management` `StageDefinition`
-   (`1DL…`) is active on `ApplicationFormProduct` / `Stage`, its `StageValue`s (`1DE…`) exist, and its
-   transitions + the CDS Flow are in place. The demo needs the seeded record's initial `Stage` to be a
-   real `StageValue`.
-4. **Target org alias and acting admin are resolved** (passed down from the orchestrator; do not
-   re-resolve or hardcode).
-
-If this skill is invoked standalone and any of the above is missing, report exactly which one and route
-back to the owning act — do not fabricate the missing artifact.
-
-## The run marker (how every sample record is tagged)
-
-**Every record this skill creates carries one shared, discoverable marker so the demo can find them and
-the teardown can delete exactly them — and nothing else.** Resolve the marker once at the start of the
-run and thread it through every write:
-
-- **`run_tag`** — a single short token for this batch, e.g. `DLTEST` plus a per-run suffix
-  (`DLTEST_<suffix>`). Do not use a timestamp you fabricate — derive the suffix from an org fact you
-  already read (for example the acting admin's short id) or ask the orchestrator to supply it, so the
-  value is stable across a resumed run.
-- **Where the marker lives per object:**
-  - Where the object's `Name` is **writable**, prefix it: `DL_Test_<thing>_<run_tag>` (e.g. a
-    participant `PartyProfile` name).
-  - Where `Name` is **not writable** — notably **`ApplicationForm` (`Name` is not writable, auto-assigned;
-    `UsageType` is required on create)** — put the `run_tag` in a writable free-text field instead. On
-    `ApplicationForm` that field is **`Title`**. Record which field carries the marker for each object so
-    the demo and teardown query the right field.
-  - **Observed live (fsc-dop7):** `ApplicationForm.Title` **is writable and accepts the marker cleanly
-    (201)** — it is the run-marker carrier for the parent application. `ApplicationForm` has **no
-    `Description` / `ApplicationSummary` / `Purpose` column** — a POST naming any of them fails
-    `400 INVALID_FIELD` (column-absence, not FLS), so do not use them. `UsageType` is **business-rule
-    required** even though `describe.nillable=true` (an empty POST fails `400 INVALID_INPUT: Select a usage
-    type`) — always send `UsageType='LoanOrigination'`. Discover the graph with
-    `WHERE Title LIKE 'DLTEST_%'`.
-
-**Read before write.** Before creating anything, query for records already carrying this `run_tag` and
-create only the ones missing. A re-run must be a no-op on what already exists (idempotent + resumable) —
-this matters because a full seed is a handful of sequential sObject writes and a partial/timed-out run
-must be safe to resume.
-
-## The sample record graph (minimal — one application, enough inputs for all three demos)
-
-Create exactly this graph. It is deliberately minimal: **one** loan application, seeded so a single
-stage transition, one BRE lookup per matrix, and one price simulation all have the inputs they need.
-
-```text
-ApplicationForm (UsageType='LoanOrigination', run_tag in Title)
- └─ ApplicationFormProduct  (ProductId = the Act-2 Home Loan product; Stage = the first StageValue.Value, e.g. Intake)
-     └─ ApplicationFormProductProposal (Amount, Term, InterestRate — the pricing + eligibility inputs)
-PartyProfile participant records (banker, underwriter, applicant) — the subjects CDS grants/revokes access to
-```
-
-### 1 — `ApplicationForm` (the parent application)
-
-- `POST /services/data/v<apiVersion>/sobjects/ApplicationForm` with **`UsageType = 'LoanOrigination'`
-  (business-rule required on create)** and the `run_tag` in **`Title`** (writable; verified live). Do
-  **not** set `Name` (not writable, auto-assigned) and do **not** send `Description` / `ApplicationSummary`
-  / `Purpose` — `ApplicationForm` has no such column and the POST fails `400 INVALID_FIELD`.
-- Re-read to capture the id (`13X…`).
-
-### 2 — `ApplicationFormProduct` (the record Stage Management acts on)
-
-- `POST … /sobjects/ApplicationFormProduct` with `ApplicationFormId` = the parent, `ProductId` = the
-  **queried** Home Loan `Product2` id (never a guessed id), and **`Stage` = the `StageValue.Value`
-  of the first stage** on the active stage definition (e.g. `Intake` — the identifier column is `Value`,
-  not `MasterLabel` / `DeveloperName` / `ApiName`). Carry the `run_tag` in a writable free-text field.
-- **Describe the object first** to confirm which fields (`Stage`, `Name`, a description field) are
-  writable on this org before choosing where the marker lives; do not assume.
-- Re-read to capture the id (`13Z…`) and confirm `Stage` read back as the seeded starting stage. This id
-  is the one the demo will `PATCH` to trigger a transition.
-
-### 3 — `ApplicationFormProductProposal` (the pricing + eligibility inputs)
-
-- `POST … /sobjects/ApplicationFormProductProposal` with `ApplicationFormProductId` = the AFP, and the
-  loan terms the downstream demos key on: `Amount`, `Term`, and the interest/credit input. **The interest
-  field is `InterestRate`** (verified live — `AFPPInterestRate` fails `400 INVALID_FIELD`; `InterestRate`
-  returns 201). Use the **documented example values** from the pricing and BRE siblings (e.g. the
-  credit-score tier and term the matrices were built around), so the BRE lookups and the price sim return
-  a real decision rather than an empty result.
-- These are the values the `simulationInputVariablesWithData` helper will serialize for the price
-  simulation and that the BRE decision matrices key on. Do not fabricate values that no matrix row or
-  rate tier covers — pick example inputs the setup's matrices/rates actually have a row for, so the demo
-  shows a hit, not a miss.
-
-#### Credit-score scenario inputs (seed one documented value — our data)
-
-The `IsSTPApplication` matrix and the qualification floor are keyed on a **credit score**, and it is what
-makes one application demonstrate a *different outcome* than another. **Verified live on fsc-dop7: the
-credit score lives on `PartyProfile.CreditScore` (the applicant participant), NOT on the proposal** — the
-proposal has no credit-score field (its createable numerics are `Amount` / `Term` / `InterestRate`). So
-seed the credit input on the **applicant `PartyProfile`** to one of these **documented scenario values**
-(never an arbitrary number) so the demo's BRE lookup lands on a known decision. The STP cutoff is a
-**configured matrix row, not a fixed constant** — on fsc-dop7 the live matrix flipped at **740** (probed:
-739 → `false`, 740 → `true`), and the minimum qualifying score is **620**. Treat 740 as this org's proven
-value, not a universal one; on another org, probe the matrix to confirm the boundary:
-
-| Scenario | Credit score to seed | `IsSTPApplication` decision | Meaning |
-|---|---|---|---|
-| Golden path (manual) | **680** | `IsSTP = false` | Qualifies (≥620) but below the STP cutoff → manual underwriting |
-| STP auto-approve | **780** | `IsSTP = true` | At/above the STP cutoff (740 on fsc-dop7) → straight-through auto-approval |
-| Disqualification | **590** | `IsSTP = false` | Below the 620 minimum → does not qualify |
-
-Default to the **golden-path 680** for the single seeded application unless the admin/orchestrator asks
-for a specific scenario. Record which scenario value was seeded in the hand-off so `digital-origination-demo-run`
-knows which decision to expect from the `IsSTPApplication` lookup. To demonstrate a *different* scenario,
-re-seed the applicant `PartyProfile`'s `CreditScore` to that row's value (or update the existing party) —
-one application graph is enough; the outcome is driven by the credit input, not by seeding multiple graphs.
-
-### 4 — Participant records (`PartyProfile` + roles) for CDS
-
-- Create the minimal participant `PartyProfile` records for the **banker**, **underwriter**, and
-  **applicant** roles — the subjects Compliant Data Sharing grants or revokes access to as the stage
-  changes. Name them with the `DL_Test_` prefix + `run_tag` where `Name` is writable.
-- These must line up with the participant roles/groups the Stage Management CDS setup created
-  (`Agent_Group`, `Underwriter_Group`, and the applicant role) so that when the demo moves the stage,
-  there is a real participant whose access visibly changes. **Reuse** the existing participant roles by
-  their exact API names — do not create new roles here; only create the sample party records that fill
-  them.
-
-## Verify & report (what "done" means for this skill)
-
-Re-read every created record and report the graph back with ids, so the demo has a verified handle on
-each:
-
-- `ApplicationForm` id + the field carrying `run_tag`.
-- `ApplicationFormProduct` id + its current `Stage` (must read back as the seeded starting stage).
-- `ApplicationFormProductProposal` id + the `Amount` / `Term` / credit input it carries.
-- The participant `PartyProfile` ids and which role each fills.
-- The single `run_tag` value — this is the handle the demo and teardown use.
-
-Report faithfully: if a record could not be created (a field is not writable on this org, a required
-lookup is missing), say which one and why, and report a **partial** seed — never claim the graph exists
-when it does not. A partial seed still hands back whatever was created so the demo can run what it can.
-
-## Idempotency & safety
-
-- **Read before write; reuse by `run_tag`.** A re-run creates only the missing records; an existing
-  tagged graph is a no-op.
-- **Resumable.** Query the tagged graph first each run so a timed-out or interrupted seed resumes cleanly
-  (a handful of sequential sObject writes; keep the create loop query-first).
-- **Never fabricate ids or product references.** The `ProductId` and the participant role API names are
-  queried from the org; the loan/credit inputs come from the documented example values the setup was
-  built around.
-- **This skill only creates the sample transactional records.** It never enables a feature, assigns a
-  permission set, or re-runs a setup act.
-
-## Hand-off to the demo
-
-On success, hand `digital-origination-demo-run` the resolved handle: the `run_tag`, the
-`ApplicationFormProduct` id (the transition target), the current `Stage`, the proposal inputs
-(**including which credit-score scenario value was seeded — 680 / 780 / 590 — and its expected
-`IsSTPApplication` decision**), and the participant ids. The demo drives these; the teardown (owned by
-the demo) deletes everything carrying the `run_tag`.
-
-<!-- skill-validate: ignore-start -->
-<!-- codey:operations start -->
-## Operations Reference
-
-Operations this skill uses — routing and dependency reference.
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `verify-prerequisites` | read | — | `GET /services/data/v63.0/query` | — |
-| `resolve-run-tag-and-check-existing` | read | — | `GET /services/data/v63.0/query` | `verify-prerequisites` |
-| `create-application-form` | write | — | `POST /services/data/v63.0/sobjects/ApplicationForm` | `resolve-run-tag-and-check-existing` |
-| `create-application-form-product` | write | — | `POST /services/data/v63.0/sobjects/ApplicationFormProduct` | `create-application-form` |
-| `create-application-form-product-proposal` | write | — | `POST /services/data/v63.0/sobjects/ApplicationFormProductProposal` | `create-application-form-product` |
-| `create-participant-party-profiles` | write | — | `POST /services/data/v63.0/sobjects/PartyProfile` | `create-application-form-product-proposal` |
-| `verify-sample-data-graph` | verify | — | `GET /services/data/v63.0/query` | `create-participant-party-profiles` |
-<!-- codey:operations end -->
-<!-- skill-validate: ignore-end -->

package/skills/fsc-document-checklist-settings-configure/SKILL.md

@@ -1,57 +0,0 @@
----
-name: fsc-document-checklist-settings-configure
-description: "Use this skill when users want to toggle four FSC org prefs allowlisted by DOCUMENT_CHECKLIST_PREF enum: deleteDCIWithFiles, dciCustomSharing, dciOptimizedSharing, dciAI. Trigger when users mention document, checklist, settings, document checklist settings."
-metadata:
-  version: "1.0"
----
-
-# Managing Document Checklist Settings
-
-## When to Use This Skill
-
-Toggle four FSC org prefs allowlisted by DOCUMENT_CHECKLIST_PREF enum: deleteDCIWithFiles, dciCustomSharing, dciOptimizedSharing, dciAI. Read returns all four as Map<String,Boolean>; write sets one by name (unknown names silently no-op). Requires admin + View Setup. Setup UI exposes only 2 of 4 toggles; agent drives all 4 programmatically. AURA-IS-CANONICAL: Metadata API + Tooling sObject DocumentChecklistSettings carry only 2 of 4 prefs in v66+ WSDLs; substituting drops dciOptimizedSharing + dciAI writes/reads.
-
-## Workflow
-
-Two-step read/write of the four DOCUMENT_CHECKLIST_PREF org prefs (deleteDCIWithFiles, dciCustomSharing, dciOptimizedSharing, dciAI). getDocumentChecklistPrefs returns all four as a Map<String,Boolean>; savePref sets one by name (pref matches the enum case-insensitively) and returns void. Critical: savePref responds 200/success even when the write does NOT take — an unknown pref name is a silent no-op, and an allowlisted pref whose underlying feature is not entitled is also silently ignored. Never treat the 200 as confirmation; always re-read via getDocumentChecklistPrefs to verify the toggle actually persisted. Observed against a live org: deleteDCIWithFiles, dciCustomSharing, and dciOptimizedSharing each toggled and read back correctly, but dciAI accepted the call and stayed false — it is gated by a dependent AI entitlement that this org lacks, so in orgs without that entitlement dciAI cannot be enabled here. The Setup UI surfaces only 2 of the 4 toggles; the agent can drive the rest programmatically, subject to that per-pref entitlement gate. Requires admin + View Setup (checkAccess throws 'noAccess' otherwise) and the org must have the FSC / Document Checklist surface available.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Caller must be an admin user with View Setup permission. Controller's checkAccess() throws AuraHandledException 'noAccess' otherwise. (check: `setupUtil.hasViewSetup() && administrator access`)
-- Document Checklist feature must be available in the org (FSC product surface). The controller lives in ui-document-checklist-components; orgs without FSC entitlement do not surface this Setup page.
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `getDocumentChecklistPrefs_1` | read | implemented | `GET /headless/invoke/platform/document-checklist-settings` | — |
-| `savePref_2` | write | implemented | `PATCH /headless/invoke/platform/document-checklist-settings/save-pref` | `getDocumentChecklistPrefs_1` |
-
-### Read operations
-
-#### `getDocumentChecklistPrefs_1`
-
-Read all four DocumentChecklist prefs as Map<String,Boolean> keyed by prefName: deleteDCIWithFiles, dciCustomSharing, dciOptimizedSharing, dciAI. AURA-IS-CANONICAL — Metadata/Tooling cover only 2 of 4 fields.
-
-**Call:** `GET /headless/invoke/platform/document-checklist-settings`   — status: `implemented`
-
-### Write operations
-
-#### `savePref_2`
-
-Toggle one allowlisted pref by name. `pref` case-insensitively matches DOCUMENT_CHECKLIST_PREF; unknown silently no-ops. Returns void. AURA-IS-CANONICAL — Metadata/Tooling drop dciOptimizedSharing + dciAI writes.
-
-**Call:** `PATCH /headless/invoke/platform/document-checklist-settings/save-pref`   — status: `implemented`
-
-**Inputs:**
-
-- `pref` *(`String`)*
-- `enabled` *(`boolean`)*
-
-**Depends on:** `getDocumentChecklistPrefs_1`