@salesforce/afv-skills 1.65.0 → 1.66.0

package/skills/industries-integrated-care-management-configure/SKILL.md

@@ -1,168 +0,0 @@
----
-name: industries-integrated-care-management-configure
-description: "Use this skill when users want to setup for Integrated Care Management (Health Cloud). Trigger when users mention integrated, care, management, settings, integrated care management settings."
-metadata:
-  version: "1.0"
-  accessCheck: "Industries.userCanAccessSetup"
----
-
-# Managing Integrated Care Management Settings
-
-## When to Use This Skill
-
-Setup for Integrated Care Management (Health Cloud). Two complementary paths. (1) Industries AdminSetup framework: GET /connect/industries/adminSetup/{fileName} discovers access-filtered configurations[].steps[] with action.name values, and POST /connect/industries/executeAdminSetupStepAction invokes them (paramKeys/paramValues parallel arrays for the parameterized variant); reads gate on Industries AccessSetup. (2) Direct org-preference toggles applied in a STRICT order — Enhanced Care Plans (CarePlansPreference) FIRST because it provisions the ICM Console app, then Integrated Care Management (Automatic Sharing for Goal Assignment Records), Automatic Sharing for Care Task Records, Care Gap Detection, and optionally MCG. Each toggle is enabled by deploying a MINIMAL IndustriesSettings via the file-based Metadata-CRUD surface (one enable* field) and read back via a Tooling IndustriesSettings query of the matching Is*Enabled field. The internal CarePlanBenefitSettings / IntegratedCareManagement / CareManagement controllers behind the /headless dispatcher document the underlying handlers but are internal-gated (POST-only, not customer-reachable).
-
-## Workflow
-
-Enable ICM in strict order. Enhanced Care Plans (enableCarePlansPreference) MUST succeed first — it provisions the ICM Console app that the later toggles depend on. Enable each toggle by deploying a MINIMAL IndustriesSettings via the file-based Metadata-CRUD surface (one enable* field per toggle; a full retrieve→deploy fails on feature-coupled prefs), then verify with a Tooling IndustriesSettings read of the matching Is*Enabled field before advancing to the next. Toggle 2 (Integrated Care Management / goal-assignment record sharing) is backed internally by the Integrated Care Management setup operations.handleToggleIntegratedCareManagement; toggles 3-5 (Care Task record sharing, Care Gap Detection, MCG) by the generic care-management operation.setPreference(orgPref, value) — these controllers run behind the internal H360 /headless dispatcher and are documented as controller_method but are not a customer transport; MCG is optional. Alternatively drive the same settings through the AdminSetup framework: call get-admin-setup-data first to discover valid action.name values, then execute-admin-setup-step-action (no params) or parameterized-execute-admin-setup-step-action.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- User must have Industries AccessSetup access (check: `View Setup permission`)
-- The org must have Health Cloud with Care Management provisioned; ICM is a Health Cloud Care Management capability. (check: `Health Cloud provisioned`)
-- The running user needs Industries setup access (View Setup / AccessSetup) to read and write these Care Management preferences. (check: `Care Management setup access`)
-- Enhanced Care Plans (enableCarePlansPreference) must be enabled before the Integrated Care Management master toggle — enabling it provisions the ICM Console app the later toggles depend on. (check: `Enhanced Care Plans before ICM master`)
-
-## Verification Checklist
-
-After every write operation, confirm the effect by re-reading state:
-
-- After `parameterized-execute-admin-setup-step-action`: call `verify-parameterized-execute-admin-setup-step-action` (`GET /connect/industries/adminSetup/{fileName}`)
-- After `execute-admin-setup-step-action`: call `verify-execute-admin-setup-step-action` (`GET /connect/industries/adminSetup/{fileName}`)
-- After (write): call `verify-enable-care-plans-preference`
-- After (write): call `verify-enable-integrated-care-management`
-- After (write): call `verify-enable-care-task-sharing`
-- After (write): call `verify-enable-care-gap-detection`
-- After (write): call `verify-enable-mcg`
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `get-admin-setup-data` | read | proposed | `GET /connect/industries/adminSetup/{fileName}` | — |
-| `execute-admin-setup-step-action` | write | proposed | `PATCH /headless/invoke/platform/integrated-care-management-settings/execute-admin-setup-step-action` | — |
-| `parameterized-execute-admin-setup-step-action` | write | proposed | `PATCH /headless/invoke/platform/integrated-care-management-settings/parameterized-execute-admin-setup-step-action` | — |
-| `verify-parameterized-execute-admin-setup-step-action` | verify | proposed | `GET /connect/industries/adminSetup/{fileName}` | `parameterized-execute-admin-setup-step-action` |
-| `verify-execute-admin-setup-step-action` | verify | implemented | `GET /connect/industries/adminSetup/{fileName}` | `execute-admin-setup-step-action` |
-| `verify-enable-care-plans-preference` | verify | implemented | `IndustriesSettings.query` | — |
-| `verify-enable-integrated-care-management` | verify | implemented | `IndustriesSettings.query` | — |
-| `verify-enable-care-task-sharing` | verify | implemented | `IndustriesSettings.query` | — |
-| `verify-enable-care-gap-detection` | verify | implemented | `IndustriesSettings.query` | — |
-| `verify-enable-mcg` | verify | implemented | `IndustriesSettings.query` | — |
-
-### Read operations
-
-#### `get-admin-setup-data`
-
-Loads the wizard's group/step graph. fileName is a path parameter naming a JSON descriptor under setupConfig/; response (AdminSetupRepresentation) carries access-filtered configurations[].steps[].action.name (the actionName for execute paths) and per-step stepStatus.
-
-**Call:** `GET /connect/industries/adminSetup/{fileName}`   — status: `proposed`
-
-**Inputs:**
-
-- `fileName` *(`String`)*
-
-### Write operations
-
-#### `execute-admin-setup-step-action`
-
-Execute admin setup step action.
-
-**Call:** `PATCH /headless/invoke/platform/integrated-care-management-settings/execute-admin-setup-step-action`   — status: `proposed`
-
-**Inputs:**
-
-- `actionName` *(`String`)* — Name of the action.
-
-#### `parameterized-execute-admin-setup-step-action`
-
-Parameterized execute admin setup step action.
-
-**Call:** `PATCH /headless/invoke/platform/integrated-care-management-settings/parameterized-execute-admin-setup-step-action`   — status: `proposed`
-
-**Inputs:**
-
-- `actionName` *(`String`)* — Name of the action.
-- `params` *(`Map<String, String>`)* — Value for params.
-
-### Verify operations
-
-#### `verify-parameterized-execute-admin-setup-step-action`
-
-Re-fetch the wizard graph after a parameterized step action runs and confirm the affected step.stepStatus advanced. Match by configurations[].steps[].action.name = <actionName>.
-
-**Call:** `GET /connect/industries/adminSetup/{fileName}`   — status: `proposed`
-
-**Inputs:**
-
-- `fileName` *(`String`)* — Same fileName used in the original get-admin-setup-data call.
-
-**Depends on:** `parameterized-execute-admin-setup-step-action`
-
-#### `verify-execute-admin-setup-step-action`
-
-Verify the effect of execute-admin-setup-step-action by re-reading the AdminSetup configuration for the same fileName; the dispatched step's completion check reflects in the returned configurations[].steps[] state.
-
-**Call:** `GET /connect/industries/adminSetup/{fileName}`   — status: `implemented`
-
-**Depends on:** `execute-admin-setup-step-action`
-
-#### `verify-enable-care-plans-preference`
-
-Verify Enhanced Care Plans is on via a Tooling IndustriesSettings query of IsCarePlansPreferenceEnabled (field confirmed against a live HC org). The internal is-care-plan-preference-enabled dispatcher (GET /headless/invoke/platform/care-plan-settings/is-care-plan-preference-enabled) is POST-only and internal-gated — not a customer read surface — so Tooling is the read-back path.
-
-**Call:** `IndustriesSettings.query`   — status: `implemented`
-
-**Inputs:**
-
-- `q` *(`String`)*
-
-#### `verify-enable-integrated-care-management`
-
-Verify the Integrated Care Management master preference is on via a Tooling IndustriesSettings query of IsIntegratedCareManagementSettingEnabled (field confirmed against a live HC org). The internal get-integrated-care-management-pref dispatcher (GET /headless/invoke/industries/industries-healthcare/integrated-care-management/get-integrated-care-management-pref) is POST-only and internal-gated — not a customer read surface — so Tooling is the read-back path.
-
-**Call:** `IndustriesSettings.query`   — status: `implemented`
-
-**Inputs:**
-
-- `q` *(`String`)*
-
-#### `verify-enable-care-task-sharing`
-
-Verify Care Task record sharing is enabled via a Tooling IndustriesSettings query of IsCareTaskSharingSettingEnabled (field confirmed against a live HC org). The internal generic get-preference dispatcher (GET /headless/invoke/industries/industries-healthcare/care-management/get-preference) is POST-only and internal-gated — not a customer read surface — so Tooling is the read-back path.
-
-**Call:** `IndustriesSettings.query`   — status: `implemented`
-
-**Inputs:**
-
-- `q` *(`String`)*
-
-#### `verify-enable-care-gap-detection`
-
-Verify Care Gap Detection is enabled via a Tooling IndustriesSettings query of IsCareGapPrefSettingEnabled (field confirmed against a live HC org). The internal generic get-preference dispatcher (GET /headless/invoke/industries/industries-healthcare/care-management/get-preference) is POST-only and internal-gated — not a customer read surface — so Tooling is the read-back path.
-
-**Call:** `IndustriesSettings.query`   — status: `implemented`
-
-**Inputs:**
-
-- `q` *(`String`)*
-
-#### `verify-enable-mcg`
-
-Verify the MCG preference state via a Tooling IndustriesSettings query of IsMcgSettingEnabled (field confirmed against a live HC org). The internal generic get-preference dispatcher (GET /headless/invoke/industries/industries-healthcare/care-management/get-preference) is POST-only and internal-gated — not a customer read surface — so Tooling is the read-back path.
-
-**Call:** `IndustriesSettings.query`   — status: `implemented`
-
-**Inputs:**
-
-- `q` *(`String`)*
-
-## Notes
-
-- **related_sors:** {'node': 'psc-lpi/CarePlanSettings', 'relationship': 'shared-capability', 'reason': 'Enhanced Care Plans is the first ICM sub-feature and is configured in depth by the Public Sector CarePlanSettings node (CarePlanBenefitSettingsController). ICM enables it first (enableCarePlansPreference) to provision the ICM Console; for the full Care Plans preference surface (group membership, benefit verification, etc.) consult that node.'}

package/skills/industries-object-enablement-configure/SKILL.md

@@ -1,86 +0,0 @@
----
-name: industries-object-enablement-configure
-description: "Use this skill when users want to manage Financial Services Cloud Compliant Data Sharing at the object level. Trigger when users mention object, enablement, settings, object enablement settings."
-metadata:
-  version: "1.0"
-  accessCheck: "IndustriesCompliantDataSharing.userCanManageObjectEnablementSettings"
----
-
-# Managing Object Enablement Settings
-
-## When to Use This Skill
-
-Manage Financial Services Cloud Compliant Data Sharing at the object level.
-See which objects support Compliant Data Sharing and whether it is turned on
-for each, turn it on or off per object, and control whether external community
-(site) users are allowed to be participants (an org-wide setting).
-
-Two operations:
-  - List the objects that support Compliant Data Sharing, with each object's
-    current settings. Only objects returned here can be updated.
-  - Update one object at a time: turn its Compliant Data Sharing on or off, or
-    change whether external community users can be participants.
-
-Good to know:
-  - The two settings are linked. Turning on external community-user
-    participation also turns on the object's Compliant Data Sharing if it
-    isn't already on; turning off an object's Compliant Data Sharing also
-    turns off external community-user participation.
-  - Some changes are rejected. You can't turn off an object's Compliant Data
-    Sharing while it still has participant roles, and you can't turn off
-    external community-user participation while active community users are
-    participants. The update response flags which rule blocked the change.
-  - The update response reflects the object's settings after the change, so no
-    separate read-back is needed.
-
-Managing these settings requires permission to manage Object Enablement
-Settings for Compliant Data Sharing.
-
-## Workflow
-
-Start by listing the objects and their current settings — this tells you which objects support Compliant Data Sharing and the current state of each. Only the objects returned here can be updated. To change a setting, call the update step with the object's parentEntityName from the list and the desired isEnabled value. By default this turns the object's Compliant Data Sharing on or off; to instead control whether external community (site) users can be participants, set isSiteUserParticipantsOrgPreference to true. The two settings are linked, so turning on external community-user participation also turns on the object's Compliant Data Sharing, and turning off an object's Compliant Data Sharing also turns off external community-user participation. The update response reflects the object's settings after the change, so you don't need to re-list to confirm. If a change is rejected, check the two flags on the response: one means the object still has participant roles (so its Compliant Data Sharing can't be turned off), the other means active community users are still participants (so external community-user participation can't be turned off).
-
-## Critical Constraints
-
-**Preconditions:**
-
-- (precondition) (check: `Manage Object Enablement Settings`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `getEntityPreferences_1` | read | implemented | `GET /headless/invoke/industries/industries-compliant-datasharing/entity-pref-selector/get-entity-preferences` | — |
-| `updateEntityPreference_2` | write | implemented | `PATCH /headless/invoke/industries/industries-compliant-datasharing/entity-pref-selector/update-entity-preference` | `getEntityPreferences_1` |
-
-### Read operations
-
-#### `getEntityPreferences_1`
-
-List the objects that support Compliant Data Sharing, along with each object's current settings. Only objects returned here can be updated in the next step. Each item includes parentEntityName (the object's API name — pass this to the update step), parentEntityLabel (the object's label), and three current-state flags: isParticipantEntityOrgPreferenceEnabled (whether Compliant Data Sharing is on for the object), isSiteUserParticipantsOrgPreferenceEnabled (whether external community (site) users are allowed to be participants — an org-wide setting), and registrationSupportsSiteUsers (whether the object supports external community-user participants). Objects are sorted by label, and a generic "Custom Object" entry always appears last.
-
-**Call:** `GET /headless/invoke/industries/industries-compliant-datasharing/entity-pref-selector/get-entity-preferences`   — status: `implemented`
-
-**Output:** A list of the objects that support Compliant Data Sharing. Each item has: parentEntityName (string — the object's API name; pass to the update step), parentEntityLabel (string — the object's label), isParticipantEntityOrgPreferenceEnabled (boolean — whether Compliant Data Sharing is on for the object), isSiteUserParticipantsOrgPreferenceEnabled (boolean — whether external community-user participation is on org-wide), and registrationSupportsSiteUsers (boolean — whether the object supports external community-user participants; always false on the trailing "Custom Object" entry).
-
-### Write operations
-
-#### `updateEntityPreference_2`
-
-Turn Compliant Data Sharing on or off for a single object, or change whether external community (site) users can be participants — one setting per call. Choose which setting to change with isSiteUserParticipantsOrgPreference: leave it false to change the object's Compliant Data Sharing (isEnabled), or set it true to change external community-user participation instead. The two settings are linked: turning on external community-user participation also turns on the object's Compliant Data Sharing if it isn't already on, and turning off an object's Compliant Data Sharing also turns off external community-user participation. Some changes can be rejected: you can't turn off an object's Compliant Data Sharing while it still has participant roles, and you can't turn off external community-user participation while active community users are participants. The response reports whether the change succeeded and reflects the object's updated setting.
-
-**Call:** `PATCH /headless/invoke/industries/industries-compliant-datasharing/entity-pref-selector/update-entity-preference`   — status: `implemented`
-
-**Inputs:**
-
-- `parentEntityName` *(`String`)*
-- `isEnabled` *(`boolean`)*
-- `isSiteUserParticipantsOrgPreference` *(`boolean`)*
-
-**Depends on:** `getEntityPreferences_1`
-
-**Output:** Reports the result for the object. Always includes parentEntityName (the object you updated) and isSuccess. On success, updatedEntityPreference holds the object's settings after the change (same shape as an item from the list step), so no separate read-back is needed. On failure, two flags explain a rejected change: isParticipantEntityOrgPreferenceDisableValidationError is true when turning off Compliant Data Sharing was blocked because the object still has participant roles, and isSiteUserParticipantsOrgPreferenceDisableValidationError is true when turning off external community-user participation was blocked because active community users are still participants. If neither flag is set on a failure, the change wasn't allowed — for example the object doesn't support Compliant Data Sharing, or it doesn't support external community-user participants.

package/skills/industries-tpm-system-processing-service-configure/SKILL.md

@@ -1,64 +0,0 @@
----
-name: industries-tpm-system-processing-service-configure
-description: "Use this skill when users want to register or check the org's Trade Promotion Management / Retail Execution processing-services tenant certificate. Trigger when users mention tpm, system, processing, service, tpm system processing service."
-metadata:
-  version: "1.0"
----
-
-# Managing Tpm System Processing Service
-
-## When to Use This Skill
-
-Register or check the org's Trade Promotion Management / Retail Execution processing-services tenant certificate. Read state via get-tenant-registration-state; register/update via update-tenant-certificate. Both route through the native Connect API at /connect/consumer-goods/tenant-registration — no Aura/headless-invoke leg required. Use view_url only for scenarios these two operations don't cover.
-
-## Verification Checklist
-
-After every write operation, confirm the effect by re-reading state:
-
-- After `update-tenant-certificate`: call `verify-update-tenant-certificate` (`GET /services/data/v67.0/connect/consumer-goods/tenant-registration`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `get-tenant-registration-state` | read | implemented | `GET /services/data/v67.0/connect/consumer-goods/tenant-registration` | — |
-| `update-tenant-certificate` | write | implemented | `PUT /services/data/v67.0/connect/consumer-goods/tenant-registration` | `get-tenant-registration-state` |
-| `verify-update-tenant-certificate` | verify | — | `GET /services/data/v67.0/connect/consumer-goods/tenant-registration` | `update-tenant-certificate` |
-
-### Read operations
-
-#### `get-tenant-registration-state`
-
-Check whether the org's Trade Promotion Management / Retail Execution processing-services tenant certificate is available and what the current registration state is. Native Connect API — no Aura round trip needed.
-
-**Call:** `GET /services/data/v67.0/connect/consumer-goods/tenant-registration`   — status: `implemented`
-
-**Output:** TenantCertificateStateRepresentation — isCertAvailable (boolean), state (string, e.g. "Registered").
-
-### Write operations
-
-#### `update-tenant-certificate`
-
-Registers/updates the org's processing-services tenant certificate for Trade Promotion Management. On Core this Connect resource is backed by an internal Aura controller method, but it is exposed as a native Connect REST endpoint and should be called directly rather than via the Aura/headless-invoke leg.
-
-**Call:** `PUT /services/data/v67.0/connect/consumer-goods/tenant-registration`   — status: `implemented`
-
-**Depends on:** `get-tenant-registration-state`
-
-**Output:** TenantCertificateUpdateStatusRepresentation — certificateUpdateStatus (string).
-
-**Notes:** no_request_body: Confirmed via live dispatch during factory-review testing on 2026-09-02 — the spec defines no requestBody/parameters and a bare PUT with no body returns 200 with certificateUpdateStatus = "Updated". The endpoint (re)issues/refreshes the org's own tenant cert server-side; there is no client-supplied input.; idempotent_when_already_registered: Calling PUT while state is already "Registered" still returns 200 Updated, and a follow-up GET shows state unchanged at "Registered" — safe to call repeatedly without a precondition check.
-
-### Verify operations
-
-#### `verify-update-tenant-certificate`
-
-Read back via get-tenant-registration-state to confirm state/isCertAvailable reflect the update just submitted.
-
-**Call:** `GET /services/data/v67.0/connect/consumer-goods/tenant-registration`
-
-**Depends on:** `update-tenant-certificate`

package/skills/integration-apex-settings-configure/SKILL.md

@@ -1,61 +0,0 @@
----
-name: integration-apex-settings-configure
-description: "Use this skill when users want to manage Apex org-wide settings. Trigger when users mention apex, settings, apex settings."
-metadata:
-  version: "1.0"
----
-
-# Managing Apex Settings
-
-## When to Use This Skill
-
-Manage Apex org-wide settings. Read current values via Tooling API SOQL (SELECT ... FROM ApexSettings LIMIT 1). Write changes via Metadata API deploy using sf project deploy with an ApexSettings XML file. Settings include: aggregate code coverage only, compile-on-deploy, parallel test execution, debug logs during deployment, default queueable delay, and security preference flags (Aura controller access checks, implicit with-sharing, approval lock/unlock, etc.). Note: dispatch cannot dispatch Metadata API writes; use sf CLI directly for updates.
-
-## Workflow
-
-{'overview': 'ApexSettings is a Visualforce-backed Setup page. There is no Aura controller or Connect API for this surface. Use Tooling API to read current settings and Metadata API (sf project deploy) to apply changes.', 'preferred_flow': '1. Read current settings via Tooling API SOQL (get_ApexSettings_config_1). 2. Determine which fields need changing. 3. Author an Apex.settings-meta.xml with the desired values. 4. Deploy via sf project deploy start --source-dir <dir> (update_ApexSettings_config_1).', 'caveats': ['XML field names in Apex.settings-meta.xml differ from Tooling API field names (e.g., enableAggregateCodeCoverageOnly vs IsAggregateCodeCoverageOnlyEnabled).', 'dispatch cannot dispatch Metadata API writes. The agent must shell out to sf CLI for the deploy step.', 'There is no programmatic read-back after Metadata API deploy; confirm success via the sf deploy exit code or a follow-up Tooling API query.']}
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Requires Modify All Data or Customize Application permission to deploy Apex org settings via Metadata API.
-- For Tooling API reads: API Enabled permission required.
-- For Metadata API writes: sf CLI must be authenticated against the target org.
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `get_ApexSettings_config_1` | read | — | `tooling.query.ApexSettings` | — |
-| `update_ApexSettings_config_1` | write | — | `metadata.deploy.ApexSettings` | — |
-
-### Read operations
-
-#### `get_ApexSettings_config_1`
-
-Read current Apex org settings via Tooling API SOQL. Execute: GET /services/data/v67.0/tooling/query?q=SELECT Id, DurableId, IsAggregateCodeCoverageOnlyEnabled, IsCompileOnDeployEnabled, IsDebugLogsDuringDeploymentEnabled, IsDisableParallelApexTestingEnabled, DefaultQueueableDelay, IsTestSetupSkipTestResultsEnabled, IsSecureNoArgConstructorPrefEnabled, IsAuraApexCtrlGuestUserAccessCheckPrefEnabled, IsApexAccessRightsPrefEnabled, IsApexCtrlImplicitWithSharingPrefEnabled, IsMngdCtrlActionAccessPrefEnabled, IsRestrictCommunityExecAnonEnabled, IsApexApprovalLockUnlockEnabled, IsApexPropertyGetterPrefEnabled, IsNonCertifiedApexMdCrudEnabled, IsAuraApexCtrlAuthUserAccessCheckPrefEnabled, IsGaplessTestAutoNumEnabled FROM ApexSettings LIMIT 1. Returns a single record (Id is always 000000000000000AAA).
-
-**Call:** `tooling.query.ApexSettings`
-
-### Write operations
-
-#### `update_ApexSettings_config_1`
-
-Modify Apex org settings via Metadata API deploy. Create a file at force-app/main/default/settings/Apex.settings-meta.xml with the desired settings, then deploy with: sf project deploy start --source-dir force-app.
-Example XML (include only fields you want to change):
-  <?xml version="1.0" encoding="UTF-8"?>
-  <ApexSettings xmlns="http://soap.sforce.com/2006/04/metadata">
-    <enableAggregateCodeCoverageOnly>false</enableAggregateCodeCoverageOnly>
-    <enableCompileOnDeploy>false</enableCompileOnDeploy>
-    <enableDisableParallelApexTesting>false</enableDisableParallelApexTesting>
-    <enableDebugDiagnostic>false</enableDebugDiagnostic>
-  </ApexSettings>
-
-Note: XML field names differ from Tooling API field names (e.g., enableAggregateCodeCoverageOnly vs IsAggregateCodeCoverageOnlyEnabled). dispatch cannot dispatch Metadata API operations (SOAP protocol); use sf CLI directly.
-
-**Call:** `metadata.deploy.ApexSettings`

package/skills/marketing-e360-email-archiving-configure/SKILL.md

@@ -1,73 +0,0 @@
----
-name: marketing-e360-email-archiving-configure
-description: "Use this skill when users want to setup for org-level 360 Email Archiving. Trigger when users mention e360email, archiving, e360email archiving."
-metadata:
-  version: "1.0"
-  accessCheck: "(Gater.EnableEmailArchiving) || (OrgPermissions.TrustedServiceArchiveAddon)"
----
-
-# Managing E360 Email Archiving
-
-## When to Use This Skill
-
-Setup for org-level 360 Email Archiving. Reads/writes two UDD org prefs (EmailArchivingEnabled, EmailArchiveOverrideAtIA) and surfaces the TrustedServiceArchiveAddon license flag (gates UI write-interactivity). Server invariants — archiving=false force-disables the IA override; IA-override=true is silently rejected (returns iaOverrideEnabled=false) when archiving is off. Three steps: read state, toggle archiving, toggle IA override. No public Connect/Tooling/Metadata path; these are internal provisioning prefs.
-
-## Workflow
-
-Read get-initial-load-config first to snapshot isArchivingEnabled, iaOverrideEnabled, and isTrustedServiceArchiveAddOnEnabled. Then mutate: update-email-archiving-enabled-pref toggles archiving (enabled=false ALSO force-disables the IA override server-side — expect iaOverrideEnabled=false in the echo); set-archive-override-at-ia-pref toggles the IA override but silently no-ops enabled=true while archiving is off. Both writes echo authoritative post-change state (success + isArchivingEnabled/iaOverrideEnabled), so the outcome is in-band — no blind write. DETECTION RULE: success=true does NOT prove the IA-override flip landed — set-archive-override-at-ia-pref returns success=true even on the silent-no-op branch, so check the echoed iaOverrideEnabled (not success); if it is still false after sending enabled=true, archiving is off (enable archiving first, then retry). Optionally re-read get-initial-load-config as a confirmation-of-commitment. NOTE: when isTrustedServiceArchiveAddOnEnabled is false the writes still execute but have no storage backend (no real archiving effect).
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Caller must satisfy View Email Archive access — the @ServiceComponentAccessGuard on the email archiving setup operation; gates all three steps. (check: `View Email Archive access`)
-- Org should have the TrustedServiceArchiveAddon Salesforce Archive add-on permission. When off, get-initial-load-config still succeeds and returns isTrustedServiceArchiveAddOnEnabled=false but the page renders a banner and the two write steps become non-interactive in the UI; programmatic writes still execute, but archiving has no underlying storage backend. (check: `OrgPermissions.TrustedServiceArchiveAddon`)
-- The EnableEmailArchiving feature gater must be on for the org. Off-gater orgs do not surface the setup page (compound expression in EngagementMessaging.accessChecks.xml line 179). (check: `Gater.EnableEmailArchiving`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `get-initial-load-config` | read | implemented | `GET /headless/invoke/platform/e360-email-archiving` | — |
-| `update-email-archiving-enabled-pref` | write | proposed | `PATCH /headless/invoke/platform/e360-email-archiving/update-email-archiving-enabled-pref` | — |
-| `set-archive-override-at-ia-pref` | write | proposed | `PATCH /headless/invoke/platform/e360-email-archiving/set-archive-override-at-iapref` | — |
-
-### Read operations
-
-#### `get-initial-load-config`
-
-Read archiving state. Returns success, isArchivingEnabled, iaOverrideEnabled, isTrustedServiceArchiveAddOnEnabled (license flag; when false the UI is read-only but programmatic writes still execute without storage backend).
-
-**Call:** `GET /headless/invoke/platform/e360-email-archiving`   — status: `implemented`
-
-**Output:** Object with success (boolean), isArchivingEnabled (boolean — current EmailArchivingEnabled pref), iaOverrideEnabled (boolean — current EmailArchiveOverrideAtIA pref), isTrustedServiceArchiveAddOnEnabled (boolean — TrustedServiceArchiveAddon org permission flag; when false the page is read-only).
-
-### Write operations
-
-#### `update-email-archiving-enabled-pref`
-
-Toggle EmailArchivingEnabled. Side effect — enabled=false also force-disables EmailArchiveOverrideAtIA. Returns success plus post-change isArchivingEnabled and iaOverrideEnabled.
-
-**Call:** `PATCH /headless/invoke/platform/e360-email-archiving/update-email-archiving-enabled-pref`   — status: `proposed`
-
-**Inputs:**
-
-- `enabled` *(`boolean`)* — Whether d is enabled.
-
-**Output:** Object with success (boolean), isArchivingEnabled (boolean — post-change EmailArchivingEnabled), iaOverrideEnabled (boolean — post-change EmailArchiveOverrideAtIA, force-disabled when enabled=false was sent).
-
-#### `set-archive-override-at-ia-pref`
-
-Toggle EmailArchiveOverrideAtIA. Server silent-no-ops enabled=true when archiving is off — returns success plus iaOverrideEnabled=false rather than flipping. Disabling (enabled=false) is always honored.
-
-**Call:** `PATCH /headless/invoke/platform/e360-email-archiving/set-archive-override-at-iapref`   — status: `proposed`
-
-**Inputs:**
-
-- `enabled` *(`boolean`)* — Whether d is enabled.
-
-**Output:** Object with success (boolean) and iaOverrideEnabled (boolean — post-change EmailArchiveOverrideAtIA, forced false when archiving was off). The success flag is true even on the silent-no-op branch (enabled=true while archiving off) — caller must check iaOverrideEnabled to detect rejection.