npm - @salesforce/afv-skills - Versions diffs - 1.65.0 → 1.65.1 - Mend

@salesforce/afv-skills 1.65.0 → 1.65.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (349) hide show

package/skills/experience-navigation-menus-configure/SKILL.md DELETED Viewed

@@ -1,235 +0,0 @@
----
-name: experience-navigation-menus-configure
-description: "Use this skill when users want to manage Navigation Menus (App Manager) — this setup page lets administrators view, clone, and delete Lightning apps and navigation menus. Trigger when users mention navigation, menus, navigation menus."
-metadata:
-  version: "1.0"
----
-# Managing Navigation Menus
-## When to Use This Skill
-Manage Navigation Menus (App Manager) — this setup page lets administrators view, clone, and delete Lightning apps and navigation menus. It surfaces a list of apps via list views, allows inspecting individual app definitions, cloning an existing app as a starting point for a new one, and permanently removing apps. Use this SOR when a user needs to administer the set of Lightning apps available in their org, including deleting obsolete apps or cloning existing ones for customization.
-## Critical Constraints
-**Destructive operations — require explicit user confirmation:**
-- **`delete-app`** — Delete app.
-  - Rollback: No automatic rollback.
-## Verification Checklist
-After every write operation, confirm the effect by re-reading state:
-- After `update-app`: call `verify-update-app` (`GET /headless/invoke/platform/navigation-menus`)
-- After `delete-app`: call `verify-delete-app` (`GET /headless/invoke/platform/navigation-menus`)
-## Operations Reference
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-### Summary
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `create-app` | write | implemented | `PATCH /headless/invoke/platform/navigation-menus/create-app` | — |
-| `update-app` | write | implemented | `PATCH /headless/invoke/platform/navigation-menus/update-app` | — |
-| `verify-update-app` | verify | — | `GET /headless/invoke/platform/navigation-menus` | `update-app` |
-| `delete-app` | delete | implemented | `DELETE /headless/invoke/platform/navigation-menus/delete-app` | — |
-| `verify-delete-app` | verify | — | `GET /headless/invoke/platform/navigation-menus` | `delete-app` |
-| `verify-create-app` | read | implemented | `GET /headless/invoke/platform/navigation-menus` | — |
-| `get-cloned-app` | read | implemented | `GET /headless/invoke/platform/navigation-menus/get-cloned-app` | — |
-| `is-developer-name-unique` | read | implemented | `GET /headless/invoke/platform/navigation-menus/is-developer-name-unique` | — |
-| `upgrade-app` | write | implemented | `PATCH /headless/invoke/platform/navigation-menus/upgrade-app` | — |
-| `get-list-views` | read | implemented | `GET /headless/invoke/platform/navigation-menus/get-list-views` | — |
-| `ported-app-image-upload-controller-get-document-rendition-url` | — | implemented | `GET /headless/invoke/platform/nav-setup/app-image-upload/get-document-rendition-url` | — |
-| `ported-app-image-upload-controller-delete-document` | — | implemented | `DELETE /headless/invoke/platform/nav-setup/app-image-upload/delete-document` | `app-image-upload-controller-get-document-rendition-url` |
-| `ported-utility-bar-setup-controller-get-initialized-utility-bar-page` | — | implemented | `GET /headless/invoke/platform/nav-setup/utility-bar-setup/get-initialized-utility-bar-page` | — |
-| `ported-utility-bar-setup-controller-get-utility-bar-page` | — | implemented | `GET /headless/invoke/platform/nav-setup/utility-bar-setup/get-utility-bar-page` | — |
-| `ported-utility-bar-setup-controller-get-clone-utility-bar-page-node` | — | implemented | `GET /headless/invoke/platform/nav-setup/utility-bar-setup/get-clone-utility-bar-page-node` | `utility-bar-setup-controller-get-utility-bar-page` |
-### Dependency graph
-```mermaid
-graph TD
-  create_app["create-app (write)"]
-  update_app["update-app (write)"]
-  verify_update_app["verify-update-app (verify)"]
-  delete_app["delete-app (delete)"]
-  verify_delete_app["verify-delete-app (verify)"]
-  verify_create_app["verify-create-app (read)"]
-  get_cloned_app["get-cloned-app (read)"]
-  is_developer_name_unique["is-developer-name-unique (read)"]
-  upgrade_app["upgrade-app (write)"]
-  get_list_views["get-list-views (read)"]
-  ported_app_image_upload_controller_get_document_rendition_url["ported-app-image-upload-controller-get-document-rendition-url"]
-  ported_app_image_upload_controller_delete_document["ported-app-image-upload-controller-delete-document"]
-  ported_utility_bar_setup_controller_get_initialized_utility_bar_page["ported-utility-bar-setup-controller-get-initialized-utility-bar-page"]
-  ported_utility_bar_setup_controller_get_utility_bar_page["ported-utility-bar-setup-controller-get-utility-bar-page"]
-  ported_utility_bar_setup_controller_get_clone_utility_bar_page_node["ported-utility-bar-setup-controller-get-clone-utility-bar-page-node"]
-  update_app --> verify_update_app
-  delete_app --> verify_delete_app
-```
-### Read operations
-#### `verify-create-app`
-Get app.
-**Call:** `GET /headless/invoke/platform/navigation-menus`   — status: `implemented`
-**Inputs:**
-- `id` *(`String`)*
-#### `get-cloned-app`
-Get cloned app.
-**Call:** `GET /headless/invoke/platform/navigation-menus/get-cloned-app`   — status: `implemented`
-**Inputs:**
-- `id` *(`String`)*
-#### `is-developer-name-unique`
-Is developer name unique.
-**Call:** `GET /headless/invoke/platform/navigation-menus/is-developer-name-unique`   — status: `implemented`
-**Inputs:**
-- `developerName` *(`String`)*
-#### `get-list-views`
-Get list views.
-**Call:** `GET /headless/invoke/platform/navigation-menus/get-list-views`   — status: `implemented`
-### Write operations
-#### `create-app`
-Create app.
-**Call:** `PATCH /headless/invoke/platform/navigation-menus/create-app`   — status: `implemented`
-**Inputs:**
-- `model` *(`Map<String, Object>`)* — Value for model.
-- `quickSave` *(`Boolean`)* — Toggle the quick save preference on or off.
-- `utilityBarPage` *(`PageNode`)* — Value for utility bar page.
-  - schema: `#/components/schemas/PageNode`
-**Notes:** reject_on_attestation: Gate before autonomous invocation — writes app metadata and adds/removes the permission-set/profile rows that control which profiles can see the app, plus app-icon and Utility Bar configuration side effects. Permission-gated, but has zero live-validation evidence in this node's history and has no natural way to read back and confirm the result afterward. Not a confirmed bug — held pending live E2E confirmation and human attestation given the permission-set side effects.
-#### `update-app`
-Update app.
-**Call:** `PATCH /headless/invoke/platform/navigation-menus/update-app`   — status: `implemented`
-**Inputs:**
-- `model` *(`Map<String, Object>`)* — Value for model.
-- `utilityBarPage` *(`PageNode`)* — Value for utility bar page.
-  - schema: `#/components/schemas/PageNode`
-**Notes:** reject_on_attestation: Gate before autonomous invocation — same permission-set visibility and app-icon/Utility-Bar side effects as create-app. Permission-gated, has a chained follow-up read step that can confirm the result, but neither step has ever been live-validated. Held pending live E2E confirmation and human attestation.
-#### `upgrade-app`
-Upgrade app.
-**Call:** `PATCH /headless/invoke/platform/navigation-menus/upgrade-app`   — status: `implemented`
-**Inputs:**
-- `id` *(`String`)* — Value for the id field.
-- `label` *(`String`)* — Value for the label field.
-- `developerName` *(`String`)* — Name of the developer.
-- `preserveProfileSetting` *(`boolean`)* — Toggle the preserve profile setting preference on or off.
-**Notes:** reject_on_attestation: Two-sided mutation: creates a new app cloned from an existing app's metadata AND mutates the old app in place, plus copies permission-set assignments to the new app. No natural way to read back and confirm the result afterward. Never live-validated. Too high-blast-radius and hard-to-reverse for autonomous invocation without human attestation.
-### Verify operations
-#### `verify-update-app`
-Verify the effect of update-app: read back the current value via the companion read to confirm the write took effect.
-**Call:** `GET /headless/invoke/platform/navigation-menus`
-**Inputs:**
-- `id` *(`String`)*
-**Depends on:** `update-app`
-#### `verify-delete-app`
-Verify the effect of delete-app: read back the current value via the companion read to confirm the write took effect.
-**Call:** `GET /headless/invoke/platform/navigation-menus`
-**Inputs:**
-- `id` *(`String`)*
-**Depends on:** `delete-app`
-### Destructive operations
-#### `delete-app`
-Delete app.
-**Call:** `DELETE /headless/invoke/platform/navigation-menus/delete-app`   — status: `implemented`
-**Inputs:**
-- `id` *(`String`)*
-**Notes:** reject_on_attestation: Irreversible delete of an app with cascading removal of its per-profile visibility, its utility-bar configuration, and its icon asset. Permission-gated, but never live-validated — the same risk class this repo gates to reject_on_attestation even when a similar delete is proven sound elsewhere; here soundness is unconfirmed. Do not auto-invoke; require explicit human attestation per invocation.
-### Other operations
-#### `ported-app-image-upload-controller-get-document-rendition-url`
-Retrieve the rendition URL for a document that serves as the app's logo/icon. Used to display the current branding image in the app editor or preview.
-**Call:** `GET /headless/invoke/platform/nav-setup/app-image-upload/get-document-rendition-url`   — status: `implemented`
-#### `ported-app-image-upload-controller-delete-document`
-Delete the document record that stores the app's custom logo. After deletion the app reverts to the default Salesforce icon.
-**Call:** `DELETE /headless/invoke/platform/nav-setup/app-image-upload/delete-document`   — status: `implemented`
-**Depends on:** `app-image-upload-controller-get-document-rendition-url`
-**Notes:** reject_on_attestation: Irreversible delete of the file record backing the app's icon image. Defensively scoped — this step validates that the target record is actually the expected file-record type before deleting, so it cannot be redirected to delete an unrelated record — and permission-gated, but ported without ever receiving its own adoption review (unlike its sibling read step). Narrower blast radius than delete-app, but still an unreviewed irreversible delete; held to the same reject_on_attestation floor pending review.
-#### `ported-utility-bar-setup-controller-get-initialized-utility-bar-page`
-Fetch the fully initialized Utility Bar page model for a Lightning App, including available utility components and their default settings. Used when the admin first opens the Utility Bar panel in the app wizard.
-**Call:** `GET /headless/invoke/platform/nav-setup/utility-bar-setup/get-initialized-utility-bar-page`   — status: `implemented`
-#### `ported-utility-bar-setup-controller-get-utility-bar-page`
-Retrieve the current Utility Bar configuration for an app, listing the utility items already added and their property values. Used to render the existing utility bar layout in the editor.
-**Call:** `GET /headless/invoke/platform/nav-setup/utility-bar-setup/get-utility-bar-page`   — status: `implemented`
-#### `ported-utility-bar-setup-controller-get-clone-utility-bar-page-node`
-Obtain a cloned copy of a Utility Bar page node (a single utility item configuration) so the admin can duplicate an existing utility item within the same or a different app's utility bar.
-**Call:** `GET /headless/invoke/platform/nav-setup/utility-bar-setup/get-clone-utility-bar-page-node`   — status: `implemented`
-**Depends on:** `utility-bar-setup-controller-get-utility-bar-page`

package/skills/experience-notification-types-configure/SKILL.md DELETED Viewed

@@ -1,206 +0,0 @@
----
-name: experience-notification-types-configure
-description: "Use this skill when users want to notification Types Manager is the Setup page where admins configure per-type delivery channels (desktop, email, mobile, slack) for both standard system notifications and admin-defined custom notification types. Trigger when users mention notification, types, manager, notification types manager."
-metadata:
-  version: "1.0"
----
-# Managing Notification Types Manager
-## When to Use This Skill
-Notification Types Manager is the Setup page where admins configure per-type delivery
-channels (desktop, email, mobile, slack) for both standard system notifications and
-admin-defined custom notification types. The canonical wire surface is the
-Notifications Connect API at /services/data/v67.0/connect/notifications/* — it covers
-type enumeration, org-level setting reads, per-type updates, and resets. The Aura
-`getConfig` step returns the page-bootstrap wrapper (perm flags, feature gates, label
-bundles) and is kept only because the Connect API has no equivalent wrapper.
-Customer scenarios:
-- Enable email delivery for the standard "Approval Request" notification org-wide.
-- Roll out a new custom notification type to mobile + desktop only.
-- Audit which org-level notification settings deviate from default.
-- Reset a single type's settings to defaults (delete row → POST recreates with defaults
-  on next change).
-Variant axis: org-level (this SOR — POST/GET /settings/organization/...) vs user-level
-(NotificationsSettings node — /settings/user/*) vs app-level (per connected app —
-/app-settings/*). All three share the NotificationSettingsRepresentation shape but
-target different scopes.
-Required precondition: org has Notifications enabled
-(Notifications enabled); without it every Connect endpoint returns
-`403 FUNCTIONALITY_NOT_ENABLED [Notifications]`. The Aura controller mirrors the
-same gate via `setupUtil.hasViewSetup()` and the View Setup user permission.
-## Workflow
-Workflow: (1) `listNotificationTypes` to enumerate notificationTypeOrId values
-(use developerName or 18-char Id thereafter); (2) `getOrgSettingsCollection` to
-read current org-level toggles for every type; (3) `updateOrgSetting` to flip
-desktop/email/mobile/slack flags per type; (4) `getOrgSetting` to verify the write
-reflected; (5) `deleteOrgSetting` to revert to defaults. The `getConfig_1` page
-bootstrap is read only when the agent is mirroring page-load state for UI parity
-— for any read/write of actual settings, use the Connect API steps.
-## Critical Constraints
-**Preconditions:**
-- Org has Notifications feature enabled. Without it every Connect API endpoint returns 403 FUNCTIONALITY_NOT_ENABLED [Notifications]. (check: `org-access-check Notifications enabled`)
-- Caller has the View Setup user permission (Aura `getConfig` enforces via `setupUtil.hasViewSetup()`). (check: `user has View Setup`)
-**Destructive operations — require explicit user confirmation:**
-- **`deleteOrgSetting`** — Remove the explicit org-level setting for `notificationTypeOrId`. The next
-read returns the system default (typically all channels enabled for standard
-types). Use as rollback target for `updateOrgSetting` when the prior state
-was "no override".
-  - Rollback: No automatic rollback.
-## Verification Checklist
-After every write operation, confirm the effect by re-reading state:
-- After `listNotificationTypes`: call `getOrgSetting` (`GET /services/data/v67.0/connect/notifications/settings/organization/{notificationTypeOrId}`)
-## Operations Reference
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-### Summary
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `getConfig_1` | read | — | `GET /headless/invoke/platform/notification-types-manager/get-config` | — |
-| `listNotificationTypes` | read | — | `GET /services/data/v67.0/connect/notifications/types` | — |
-| `getOrgSettingsCollection` | read | — | `GET /services/data/v67.0/connect/notifications/settings/organization` | `listNotificationTypes` |
-| `getOrgSetting` | verify | — | `GET /services/data/v67.0/connect/notifications/settings/organization/{notificationTypeOrId}` | `listNotificationTypes` |
-| `updateOrgSetting` | write | — | `POST /services/data/v67.0/connect/notifications/settings/organization/{notificationTypeOrId}` | `listNotificationTypes` |
-| `deleteOrgSetting` | delete | — | `DELETE /services/data/v67.0/connect/notifications/settings/organization/{notificationTypeOrId}` | `listNotificationTypes` |
-### Dependency graph
-```mermaid
-graph TD
-  getConfig_1["getConfig_1 (read)"]
-  listNotificationTypes["listNotificationTypes (read)"]
-  getOrgSettingsCollection["getOrgSettingsCollection (read)"]
-  getOrgSetting["getOrgSetting (verify)"]
-  updateOrgSetting["updateOrgSetting (write)"]
-  deleteOrgSetting["deleteOrgSetting (delete)"]
-  listNotificationTypes --> getOrgSettingsCollection
-  listNotificationTypes --> getOrgSetting
-  listNotificationTypes --> updateOrgSetting
-  listNotificationTypes --> deleteOrgSetting
-```
-### Read operations
-#### `getConfig_1`
-Read the Notification Types Manager page-bootstrap wrapper
-(`NotificationTypesManagerConfig`) — perm flags, feature gates, label bundles for
-the Setup page. No public Connect / Tooling / Metadata / sObject alternative —
-Aura controller is canonical for this wrapper. Use the sibling Connect API steps
-for the actual notification-type settings.
-**Call:** `GET /headless/invoke/platform/notification-types-manager/get-config`
-**Output:** NotificationTypesManagerConfig wrapper carrying page-init state (perm flags,
-feature toggles, label-localization bundles). Schema is internal to the Aura
-controller (not surfaced through Connect); treat as opaque from an automation
-perspective.
-#### `listNotificationTypes`
-Enumerate all notification types (standard + custom). Returns
-NotificationTypeRepresentation rows carrying `apiName`, `id`, `label`,
-`namespace`, `actionGroups`. Use the returned `apiName` (preferred) or 18-char
-`id` as `notificationTypeOrId` on subsequent /settings/organization/* calls.
-**Call:** `GET /services/data/v67.0/connect/notifications/types`
-**Output:** `{notificationTypes: [{id, apiName, label, namespace, actionGroups}]}` —
-type catalog for the org.
-#### `getOrgSettingsCollection`
-Bulk read of every org-level notification setting in one call. Substitutes the
-Aura controller's `getStandardNotificationTypesSettings` +
-`getCustomNotificationTypesSettings` page-row reads with one typed Connect
-response. Use this as the canonical "current state" view before computing diffs
-for `updateOrgSetting`.
-**Call:** `GET /services/data/v67.0/connect/notifications/settings/organization`
-**Depends on:** `listNotificationTypes`
-**Output:** `{notificationSettings: [NotificationSettingsRepresentation]}` —
-each row: desktopEnabled, emailEnabled, mobileEnabled, slackEnabled,
-multiChannelSlackEnabled, notificationLabel, notificationTypeName,
-notificationTypeNamespace, notificationTypeOrId.
-### Write operations
-#### `updateOrgSetting`
-Flip the desktop / email / mobile / slack flag(s) for one notification type
-org-wide. Body keys (any subset; omitted keys preserve current state):
-desktopEnabled, emailEnabled, mobileEnabled, slackEnabled. Returns the
-post-update NotificationSettingsRepresentation echoing all four flags +
-metadata. Replaces the Aura `saveSettings(List<Map<String,Object>>)` batch with
-typed per-type writes.
-**Call:** `POST /services/data/v67.0/connect/notifications/settings/organization/{notificationTypeOrId}`
-**Inputs:**
-- `notificationTypeOrId` *(`String`)* — Notification type developerName or 18-char Id.
-- `desktopEnabled` *(`Boolean`)* — Enable desktop delivery.
-- `emailEnabled` *(`Boolean`)* — Enable email delivery.
-- `mobileEnabled` *(`Boolean`)* — Enable mobile (push) delivery.
-- `slackEnabled` *(`Boolean`)* — Enable Slack delivery (requires multiChannelSlackEnabled at org level).
-**Depends on:** `listNotificationTypes`
-**Rollback:** deleteOrgSetting
-### Verify operations
-#### `getOrgSetting`
-Read a single org-level notification setting by `notificationTypeOrId`
-(apiName preferred — e.g. `ApprovalRequest` — or 18-char Id). Use after
-`updateOrgSetting` to confirm the channel flags reflected.
-**Call:** `GET /services/data/v67.0/connect/notifications/settings/organization/{notificationTypeOrId}`
-**Inputs:**
-- `notificationTypeOrId` *(`String`)* — Notification type developerName (e.g. `ApprovalRequest`) or 18-char Id
-from `listNotificationTypes`.
-**Depends on:** `listNotificationTypes`
-**Output:** Single NotificationSettingsRepresentation: desktopEnabled, emailEnabled,
-mobileEnabled, slackEnabled, multiChannelSlackEnabled, notificationLabel,
-notificationTypeName, notificationTypeNamespace, notificationTypeOrId.
-### Destructive operations
-#### `deleteOrgSetting`
-Remove the explicit org-level setting for `notificationTypeOrId`. The next
-read returns the system default (typically all channels enabled for standard
-types). Use as rollback target for `updateOrgSetting` when the prior state
-was "no override".
-**Call:** `DELETE /services/data/v67.0/connect/notifications/settings/organization/{notificationTypeOrId}`
-**Inputs:**
-- `notificationTypeOrId` *(`String`)* — Notification type developerName or 18-char Id.
-**Depends on:** `listNotificationTypes`

package/skills/experience-notifications-configure/SKILL.md DELETED Viewed

@@ -1,75 +0,0 @@
----
-name: experience-notifications-configure
-description: "Use this skill when users want to use this skill to enable or disable in-app notifications and push notifications for the entire org in Lightning Experience and Salesforce mobile app. Trigger when users mention notifications, settings, notifications settings."
-metadata:
-  version: "1.0"
-  cliTools:
-  - tool:
-    - "sf"
-    semver: ">=2.0.0"
----
-# Managing Notifications Settings
-## When to Use This Skill
-Use this skill to enable or disable in-app notifications and push notifications for the entire org in Lightning Experience and Salesforce mobile app. Two settings available: (1) Enable in-app notifications checkbox, (2) Enable push notifications checkbox. Both are org-level settings that apply to all users.
-## Workflow
-The factory-synthesized Connect API operations (NotificationsSettings.getConfiguration / NotificationsSettings.updateConfiguration) do not exist. This page uses Metadata API for both reads and writes.
-Programmatic access via Metadata API:
-Field names verified via live org testing: enableNotifications (in-app notifications), enableMobileAppPushNotifications (push notifications).
-## Critical Constraints
-**Operational rules:**
-- READ: Retrieve the NotificationsSettings metadata type:
-- sf project retrieve start --metadata NotificationsSettings
-- Returns NotificationsSettings.settings-meta.xml with <enableNotifications> and <enableMobileAppPushNotifications>
-- WRITE: Deploy the NotificationsSettings metadata type:
-- Create a NotificationsSettings.settings-meta.xml file:
-  <NotificationsSettings xmlns="http://soap.sforce.com/2006/04/metadata">
-    <enableNotifications>true|false</enableNotifications>
-    <enableMobileAppPushNotifications>true|false</enableMobileAppPushNotifications>
-  </NotificationsSettings>
-- Deploy via: sf project deploy start --source-dir <dir> (requires SFDX project structure)
-## Operations Reference
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-### Summary
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `get_NotificationsSettings_config_1` | read | — | `sf project retrieve start` | — |
-| `update_NotificationsSettings_config_1` | write | — | `sf project deploy start` | — |
-### Read operations
-#### `get_NotificationsSettings_config_1`
-Read current org-level notification settings (in-app enabled, push enabled). Retrieve NotificationsSettings metadata type to get enableNotifications and enableMobileAppPushNotifications values.
-**Call:** `sf project retrieve start`
-### Write operations
-#### `update_NotificationsSettings_config_1`
-Update org-level notification settings (enable or disable in-app notifications and/or push notifications). Deploy NotificationsSettings metadata type with enableNotifications and/or enableMobileAppPushNotifications.
-**Call:** `sf project deploy start`
-**Inputs:**
-- `enableNotifications` — In-app notifications toggle (Lightning Experience + mobile app). Boolean field in NotificationsSettings metadata. Set to true to enable, false to disable.
-  - schema: `{'type': 'boolean'}`
-- `enableMobileAppPushNotifications` — Mobile push notifications toggle. Boolean field in NotificationsSettings metadata. Set to true to enable, false to disable.
-  - schema: `{'type': 'boolean'}`
-**Output:** Metadata deploy result. Success confirms the notification toggles were applied org-wide. Changes take effect immediately.