@salesforce/afv-skills 1.65.0 → 1.65.1

package/skills/crm-analytics-operational-analytics-metadata-bridge-migrate/SKILL.md

@@ -1,233 +0,0 @@
----
-name: crm-analytics-operational-analytics-metadata-bridge-migrate
-description: "Use this skill when users want to oA->Tableau Next metadata bridge wizard. Trigger when users mention operational, analytics, metadata, bridge, operational analytics metadata bridge."
-metadata:
-  version: "1.0"
-  accessCheck: "Insights.userCanUseOaMetadataBridge"
----
-
-# Managing Operational Analytics Metadata Bridge
-
-## When to Use This Skill
-
-OA->Tableau Next metadata bridge wizard. Migrates legacy Operational
-Analytics report-based dashboards into Tableau Next semantic data
-models. Lists in-flight and completed AnalyticsInteropMigrDef records
-(filter source=Oa - the Crma variant belongs to a sibling admin
-surface), drills into one job by id, lists Tableau Next workspaces
-and the org's Data Cloud connection, fetches DLO field metadata, and
-atomically generates a target DMO plus DLO->DMO field mapping from a
-dloConfig payload. Bulk status poll returns modeling state for many
-DMOs in one call. First-class concepts: the migration-job source
-enum {Crma, Oa} scopes lookups; the status enum {None,
-DataObjectsAndFieldsDiscovered, OaReportTypesSelected,
-DataLakeObjectLineageSaved, DataModelObjectLineageSaved,
-CrmaDashboardsSelected, CrmaRecipesSelected, Completed, Failed}
-tracks wizard progress. Update paths on the migration-job record
-require echoing the current definitionVersion (optimistic locking).
-
-## Workflow
-
-Reads are independent (no ordering between get-active-interop-process,
-get-interop-migration-history, get-interop-migration-job-by-id,
-get-workspaces, get-connection-name, get-dlo-details,
-get-bulk-dmo-status, get-semantic-models-for-dataspace,
-get-all-semantic-model-api-names-for-dataspace). The atomic write
-generate-dmo-with-mapping is initiated with a dloConfig payload;
-verify-generate-dmo-with-mapping reads back via get-bulk-dmo-status
-using the new DMO's developer name to confirm the deploy reached a
-terminal modeling state.
-
-Workflow - a typical OA->Tableau Next migration: (1) list active jobs
-to check for an in-flight record; (2) list history for completed
-migrations context; (3) fetch workspaces + Data Cloud connection to
-populate wizard pickers; (4) fetch DLO field metadata for the source
-DLO; (5) optionally pre-check semantic-model name collisions via
-get-all-semantic-model-api-names-for-dataspace; (6) submit the
-dloConfig to generate-dmo-with-mapping (or the bulk variant for
-multiple DMOs in one transaction); (7) poll get-bulk-dmo-status until
-the target DMO reaches Completed.
-
-Out-of-band admin surface: POST /wave/interop/migration-jobs creates
-an AnalyticsInteropMigrDef record standalone (POST response body is
-7 fields: id, name, label, dataspaceApiName, definitionVersion:1,
-source, status; GET on the created id returns the full 9-field record
-including server-assigned createdDate and lastModifiedDate); PATCH
-updates one, requiring
-the caller to echo the current definitionVersion - server increments
-on write (optimistic locking); DELETE removes the record. These
-aren't part of the wizard's happy path but are the canonical Connect
-surface for admin tools that manage AnalyticsInteropMigrDef records
-directly.
-
-Access guard: every cached controller signature (releases 262 and
-264) gates all methods on Insights.userCanUseOaMetadataBridge. The
-legacy Analytics Metadata Bridge access appears in NO
-cached signature - the factory precondition originally named it in
-error (now corrected). Callers should gate on
-userCanUseOaMetadataBridge.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- User must have Insights UseOaMetadataBridge access (check: `Insights.userCanUseOaMetadataBridge`)
-
-## Verification Checklist
-
-After every write operation, confirm the effect by re-reading state:
-
-- After `generate-dmo-with-mapping`: call `verify-generate-dmo-with-mapping` (`GET /headless/invoke/platform/operational-analytics-metadata-bridge/get-bulk-dmostatus`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `get-active-interop-process` | read | proposed | `GET /services/data/v66.0/wave/interop/migration-jobs` | — |
-| `get-interop-migration-history` | read | proposed | `GET /services/data/v66.0/wave/interop/migration-jobs` | — |
-| `get-interop-migration-job-by-id` | read | proposed | `GET /services/data/v66.0/wave/interop/migration-jobs/{interopMigrationJobId}` | — |
-| `get-workspaces` | read | implemented | `GET /services/data/v66.0/tableau/workspaces` | — |
-| `get-connection-name` | read | proposed | `GET /services/data/v66.0/ssot/connections` | — |
-| `generate-dmo-with-mapping` | write | proposed | `PATCH /headless/invoke/platform/operational-analytics-metadata-bridge/generate-dmo-with-mapping` | — |
-| `get-dlo-details` | read | proposed | `GET /services/data/v66.0/ssot/data-lake-objects/{recordIdOrDeveloperName}` | — |
-| `get-bulk-dmo-status` | read | implemented | `GET /headless/invoke/platform/operational-analytics-metadata-bridge/get-bulk-dmostatus` | — |
-| `verify-generate-dmo-with-mapping` | verify | proposed | `GET /headless/invoke/platform/operational-analytics-metadata-bridge/get-bulk-dmostatus` | `generate-dmo-with-mapping` |
-| `get-semantic-models-for-dataspace` | read | proposed | `GET /headless/invoke/platform/operational-analytics-metadata-bridge/get-semantic-models-for-dataspace` | — |
-| `get-all-semantic-model-api-names-for-dataspace` | read | proposed | `GET /headless/invoke/platform/operational-analytics-metadata-bridge/get-all-semantic-model-api-names-for-dataspace` | — |
-| `generate-dmos-with-mapping-bulk` | write | proposed | `PATCH /headless/invoke/platform/operational-analytics-metadata-bridge/generate-dmos-with-mapping-bulk` | — |
-
-### Read operations
-
-#### `get-active-interop-process`
-
-List interop migration jobs filtered by source=Oa; caller selects the latest entry with status=Started to recover the active OA migration. Connect representation per the InteropMigrationJob schema.
-
-**Call:** `GET /services/data/v66.0/wave/interop/migration-jobs`   — status: `proposed`
-
-#### `get-interop-migration-history`
-
-List interop migration jobs filtered by source=Oa; caller filters to status=Completed and sorts by createdDate desc to recover the OA migration history.
-
-**Call:** `GET /services/data/v66.0/wave/interop/migration-jobs`   — status: `proposed`
-
-#### `get-interop-migration-job-by-id`
-
-Read one interop migration job by its record id; returns the InteropMigrationJob representation with id, dataspaceApiName, definitionVersion, status, source, errorInfo, and the per-source selection lineage fields.
-
-**Call:** `GET /services/data/v66.0/wave/interop/migration-jobs/{interopMigrationJobId}`   — status: `proposed`
-
-**Inputs:**
-
-- `jobId` *(`String`)*
-
-#### `get-workspaces`
-
-List Tableau Next workspaces visible to the running user, populating the OA bridge wizard's workspace picker. Optional limit/offset for pagination; returns workspaces array of {id, name, label}.
-
-**Call:** `GET /services/data/v66.0/tableau/workspaces`   — status: `implemented`
-
-#### `get-connection-name`
-
-List Data Cloud connection records. connectorType is a REQUIRED query parameter - a request without it returns 400 ILLEGAL_QUERY_PARAMETER_VALUE ("ConnectorType must be provided"). The OA bridge passes connectorType=SalesforceDotCom; the server returns only that connector's connection metadata (server-side filtered, not caller-side), recovering the running org's Data Cloud connection used by the wizard.
-
-**Call:** `GET /services/data/v66.0/ssot/connections`   — status: `proposed`
-
-#### `get-dlo-details`
-
-Read one Data Lake Object by record id or developer name; returns the DLO record with label, category, and field metadata used by the OA bridge wizard's mapping panel.
-
-**Call:** `GET /services/data/v66.0/ssot/data-lake-objects/{recordIdOrDeveloperName}`   — status: `proposed`
-
-**Inputs:**
-
-- `dloApiName` *(`String`)*
-
-#### `get-bulk-dmo-status`
-
-Bulk-poll modeling status; List<String> of DMO developer names -> name->status map. AURA-IS-CANONICAL - no Connect/Tooling endpoint accepts a name list; substitution forces N round-trips and loses batch semantics. FACTORY GAP (live-confirmed on epic-orgfarm): this route is currently UN-INVOKABLE via the dispatcher - a headless Aura GET whose only param is a List<String> query param returns 400 REQUEST_ERROR "Invalid request", because the invoke envelope's query_params is a string-valued map and cannot carry a list. No-param and single-String-param headless GETs on the same org return 200, isolating the failure to the List<String> query encoding. This also breaks the verify-generate-dmo-with-mapping read-back step.
-
-**Call:** `GET /headless/invoke/platform/operational-analytics-metadata-bridge/get-bulk-dmostatus`   — status: `implemented`
-
-**Inputs:**
-
-- `dmoDeveloperNames` *(`List<String>`)*
-
-#### `get-semantic-models-for-dataspace`
-
-List semantic data models scoped to one dataspace. The OA bridge wizard
-calls this to populate the DMO picker per dataspace before generating
-a new mapping. No public Connect / Tooling / Metadata alternative
-surfaces the dataspace-scoped list shape.
-
-**Call:** `GET /headless/invoke/platform/operational-analytics-metadata-bridge/get-semantic-models-for-dataspace`   — status: `proposed`
-
-**Inputs:**
-
-- `dataspaceApiName` *(`String`)* — API name of the target dataspace (default is `default`). Scopes the
-returned semantic-model list to only models defined in this dataspace.
-
-#### `get-all-semantic-model-api-names-for-dataspace`
-
-List semantic model api names in one dataspace. The OA bridge wizard
-uses this to check for duplicate name collisions before creating a
-new DMO in that dataspace. Lighter-weight than the full semantic-model
-list read; returns names only.
-
-**Call:** `GET /headless/invoke/platform/operational-analytics-metadata-bridge/get-all-semantic-model-api-names-for-dataspace`   — status: `proposed`
-
-**Inputs:**
-
-- `dataspaceApiName` *(`String`)* — API name of the target dataspace. Scopes the returned name list to
-models defined in this dataspace.
-
-### Write operations
-
-#### `generate-dmo-with-mapping`
-
-Atomic DLO->DMO materialization: resolve the source DLO, create the target custom DMO when missing, and apply the field mapping in one autoCommit multi-wrapper. AURA-IS-CANONICAL - chained cdp-connect-api calls would lose autoCommit atomicity across the CdpDataLakeObject/DataModelObject/Mapping/DataSpace wrappers. The dloConfig body map (live-verified against the controller's own validation errors on epic-orgfarm) requires: dloApiName (source DLO API name, e.g. "ProvisionedFeature__dll"); dloFieldNames (List<String> of source DLO field API names to carry - REQUIRED, "Data Lake Object information must include field names"); dmoDeveloperName (target DMO developer name; the controller appends "__dlm", so "ProvisionedFeature_OA" -> "ProvisionedFeature_OA__dlm"); dataspaceApiName (default "default"); and mappingFields (list of source->target field entries, per-entry shape {sourceFieldName, targetFieldName} - structurally accepted and reached the createDMO step on epic-orgfarm). NOTE: the harness-inferred key "dlmDeveloperName" is WRONG - the controller reads "dloApiName" and 500s ("Data Lake Object information must include API name") on the wrong key.
-
-**Call:** `PATCH /headless/invoke/platform/operational-analytics-metadata-bridge/generate-dmo-with-mapping`   — status: `proposed`
-
-**Inputs:**
-
-- `dloConfig` *(`Map<String, Object>`)* — Value for dlo config.
-
-#### `generate-dmos-with-mapping-bulk`
-
-Bulk variant of generate-dmo-with-mapping: accepts a list of dloConfig
-entries plus a correlationId and atomically creates all DMOs and their
-DLO field mappings in one call. AURA-IS-CANONICAL - the batch shape
-+ atomic autoCommit across multiple DLO/DMO/Mapping/DataSpace wrappers
-has no Connect/Tooling equivalent.
-
-**Call:** `PATCH /headless/invoke/platform/operational-analytics-metadata-bridge/generate-dmos-with-mapping-bulk`   — status: `proposed`
-
-**Inputs:**
-
-- `dloConfigs` *(`List<Map<String, Object>>`)* — List of per-DMO dloConfig entries; each entry follows the SAME generate-dmo-with-mapping dloConfig contract: dloApiName (source DLO API name, e.g. "ProvisionedFeature__dll"); dloFieldNames (List<String> of source DLO field API names to carry - REQUIRED); dmoDeveloperName (target DMO developer name; the controller appends "__dlm"); dataspaceApiName (default "default"); and mappingFields (per-entry {sourceFieldName, targetFieldName}). NOTE: the harness-inferred key "dlmDeveloperName" is WRONG - the controller reads "dloApiName" and 500s ("Data Lake Object information must include API name") on the wrong key, exactly as documented on the singular generate-dmo-with-mapping step. All entries are processed inside one autoCommit transaction; partial success is not surfaced.
-- `correlationId` *(`String`)* — Client-supplied correlation identifier for the bulk operation.
-Downstream progress tracking (via get-bulk-dmo-status) uses the
-resulting DMO developer names, not this id; supply a stable value
-per bulk submission for observability.
-
-### Verify operations
-
-#### `verify-generate-dmo-with-mapping`
-
-Read back via get-bulk-dmo-status with the new DMO developer name; the returned map's modeling-status entry confirms the deploy reached the platform.
-
-**Call:** `GET /headless/invoke/platform/operational-analytics-metadata-bridge/get-bulk-dmostatus`   — status: `proposed`
-
-**Inputs:**
-
-- `dmoDeveloperNames` *(`List<String>`)*
-
-**Depends on:** `generate-dmo-with-mapping`
-
-## Notes
-
-- **wire_contract_findings:** {'description': 'GET /wave/interop/migration-jobs?source=<invalid> returns 503 with\nerrorCode 239 ("The specified enum type has no constant with the\nspecified name: <value>"). Query-filter enum validation is\ncase-sensitive and rejects unknown values with a server-error shape\n(not a 400).', 'affected_step': 'get-active-interop-process'}, {'description': 'POST /wave/interop/migration-jobs body {source: <invalid>, ...}\nreturns 400 POST_BODY_PARSE_ERROR ("Invalid value for Invalid\ninteroperability migration source: <value>"). Body enum validation\nproduces a different error shape than the query-filter case above.', 'affected_step': 'get-active-interop-process'}, {'description': 'GET /wave/interop/migration-jobs/{invalid-id} returns 404 errorCode\n135 ("Failed to load AnalyticsInteropMigrDef for Id=<id>"). Distinct\nfrom the 118 mandatory-field code.', 'affected_step': 'get-interop-migration-job-by-id'}, {'description': 'PATCH /wave/interop/migration-jobs/{id} without definitionVersion in\nthe body returns 400 errorCode 118 ("definitionVersion is a\nmandatory field"). PATCH is not true partial merge - the caller\nmust fetch the current record and echo definitionVersion on every\nupdate. On success, the server increments definitionVersion by 1\n(optimistic-locking semantics; a stale echo will conflict).', 'affected_step': 'get-interop-migration-job-by-id'}, {'description': 'POST /wave/interop/migration-jobs body accepts a strict subset of\nthe response fields: only {source, dataspaceApiName, status} are\nwritable inputs. Including id, name, label, definitionVersion,\ncreatedDate, or lastModifiedDate in the request body returns 400\nJSON_PARSER_ERROR "Unrecognized field <field>" (short-circuits\nbefore enum validation). Server auto-assigns id, name, label\n(name defaults to AnalyticsInteropMigrDef_<random>; label mirrors\nname), definitionVersion (starts at 1), createdDate,\nlastModifiedDate.', 'affected_step': 'get-active-interop-process'}, {'description': 'PATCH /wave/interop/migration-jobs/{id} rejects `name` and `label`\nas unrecognized input fields (400 JSON_PARSER_ERROR). These are\nimmutable post-create - only `status`, `definitionVersion` (echo),\nand per-source selection lineage fields are mutable. Agents\ndriving update workflows should not attempt to rename records.', 'affected_step': 'get-interop-migration-job-by-id'}, {'description': 'PATCH body `status` field has a stricter accepted-value set than\nthe response schema exposes. Long-form values like\nDataObjectsAndFieldsDiscovered return 503 errorCode 239 ("No enum\nconstant AnalyticsInteropMigrDefStatusEnum.<abbrev>") where the\nserver has translated the input to an internal abbreviation\nbefore enum lookup. The short abbreviation itself (e.g., DOAFD)\nreturns 400 POST_BODY_PARSE_ERROR "Invalid value for status".\nConfirmed accepted: None. Agents should treat the write-side\nstatus enum as a distinct, less permissive set than the response\nschema - probe or use `get-interop-migration-job-by-id` to\ndiscover an accepted value before PATCH-transitioning state.', 'affected_step': 'get-interop-migration-job-by-id'}, {'description': 'definitionVersion does not increment strictly by +1 per successful\nPATCH. After POST (v1), a successful PATCH may return v3 or higher\neven when no prior successful PATCH occurred - validation-error\npaths (400/503) can still bump the internal version counter, or\nthe successful PATCH itself may bump by more than one. Agents MUST\nround-trip a GET after any successful write to recover the current\nversion before the next PATCH; do not assume +1 arithmetic.', 'affected_step': 'get-interop-migration-job-by-id'}

package/skills/crm-analytics-report-notifications-ui-configure/SKILL.md

@@ -1,184 +0,0 @@
----
-name: crm-analytics-report-notifications-ui-configure
-description: "Use this skill when users want to setup page for managing AnalyticNotification records—Lightning Report and Dashboard subscriptions scoped to the calling user. Trigger when users mention report, notifications, ui, report notifications ui."
-metadata:
-  version: "1.0"
-  accessCheck: "AnalyticsAccessCheck.CAN_SUBSCRIBE_REPORTS_RUN_AS_USER"
----
-
-# Managing Report Notifications Ui
-
-## When to Use This Skill
-
-Setup page for managing AnalyticNotification records—Lightning Report and Dashboard subscriptions scoped to the calling user. The page lists existing subscriptions and supports creating, updating, and deleting subscriptions.
-
-Programmatic CRUD operations are exposed through the SubscribeDialog Aura controller, mounted at /headless/invoke/analytics/analytics-home/subscribe-dialog/.
-
-Each record-scoped operation requires a `source` parameter ("Report" or "Dashboard") and either:
-- `recordId` — the target Report or Dashboard, or
-- `notificationId` — an existing subscription.
-
-Before performing subscription operations, call getReportSubscriptionUserPerms to determine permissions and gate flows involving Run As User and other-user recipients.
-
-The two setup_page steps—view and refresh—are navigation-canonical. No programmatic API replaces the Setup page UI itself.
-
-## Workflow
-
-{'canonical_sequence': ['read-report-subscription-user-perms', 'read-limits', 'read-notification-info', 'read-recipient-types', 'write-notification', 'update-notification', 'delete-unsubscribe-notification'], 'notes': "Always read perms + limits before write operations. Use read-notification-info to check existing state before create/update/delete. For updates, prefer update-notification over delete+create. The `source` parameter is always 'Report' or 'Dashboard' — no other values are accepted."}
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Reports & Dashboards is enabled in the org. Default in every Salesforce edition; included for completeness.
-- Caller has access to the Report or Dashboard identified by `recordId`. Subscription operations resolve recordId in the caller's sharing context; a record the caller cannot view will not be subscribable.
-- For run-as-user or other-user-recipient subscriptions, caller must hold the corresponding perm — read via read-report-subscription-user-perms (CAN_SUBSCRIBE_REPORTS_RUN_AS_USER / CAN_SUBSCRIBE_REPORT_TO_OTHER_USERS). (check: `AnalyticsAccessCheck.CAN_SUBSCRIBE_REPORTS_RUN_AS_USER`)
-
-**Destructive operations — require explicit user confirmation:**
-
-- **`delete-unsubscribe-notification`** — Delete the AnalyticNotification identified by `notificationId`. Throws IllegalArgumentException if the id does not resolve to AnalyticNotification entity type. Obtain `notificationId` from a prior read-notification-info call.
-  - Rollback: No automatic rollback.
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `view_ReportNotificationsUI_1` | read | — | `ReportNotificationsUI.view` | — |
-| `refresh_ReportNotificationsUI_1` | read | — | `ReportNotificationsUI.refresh` | — |
-| `read-notification-info` | read | — | `GET /headless/invoke/analytics/analytics-home/subscribe-dialog/get-notification-info` | — |
-| `read-report-subscription-user-perms` | read | — | `GET /headless/invoke/analytics/analytics-home/subscribe-dialog/get-report-subscription-user-perms` | — |
-| `write-notification` | write | — | `PATCH /headless/invoke/analytics/analytics-home/subscribe-dialog/create-notification` | `read-report-subscription-user-perms`, `read-limits` |
-| `delete-unsubscribe-notification` | delete | — | `PATCH /headless/invoke/analytics/analytics-home/subscribe-dialog/unsubscribe-notification` | `read-notification-info` |
-| `update-notification` | write | — | `PATCH /headless/invoke/analytics/analytics-home/subscribe-dialog/save-notification` | `read-notification-info`, `read-report-subscription-user-perms` |
-| `read-limits` | read | — | `GET /headless/invoke/analytics/analytics-home/subscribe-dialog/get-limits` | — |
-| `read-recipient-types` | read | — | `GET /headless/invoke/analytics/analytics-home/subscribe-dialog/get-recipient-types` | — |
-
-### Dependency graph
-
-```mermaid
-graph TD
-  view_ReportNotificationsUI_1["view_ReportNotificationsUI_1 (read)"]
-  refresh_ReportNotificationsUI_1["refresh_ReportNotificationsUI_1 (read)"]
-  read_notification_info["read-notification-info (read)"]
-  read_report_subscription_user_perms["read-report-subscription-user-perms (read)"]
-  write_notification["write-notification (write)"]
-  delete_unsubscribe_notification["delete-unsubscribe-notification (delete)"]
-  update_notification["update-notification (write)"]
-  read_limits["read-limits (read)"]
-  read_recipient_types["read-recipient-types (read)"]
-  read_report_subscription_user_perms --> write_notification
-  read_limits --> write_notification
-  read_notification_info --> delete_unsubscribe_notification
-  read_notification_info --> update_notification
-  read_report_subscription_user_perms --> update_notification
-```
-
-### Read operations
-
-#### `view_ReportNotificationsUI_1`
-
-Open the Subscriptions Setup page for manual review of the caller's Lightning report/dashboard subscriptions. NAVIGATION — no programmatic API navigates the page UI; manage subscription records via subscribe-dialog steps.
-
-**Call:** `ReportNotificationsUI.view`
-
-#### `refresh_ReportNotificationsUI_1`
-
-Reload the Subscriptions Setup page. NAVIGATION — no API analog; reissue the underlying subscribe-dialog reads (e.g. read-notification-info) to pick up record changes programmatically.
-
-**Call:** `ReportNotificationsUI.refresh`
-
-#### `read-notification-info`
-
-Read caller's AnalyticNotification (subscription) for `recordId` scoped to `source`. `recordId` must be a Report or Dashboard; `source` must be 'Report' or 'Dashboard' — passing neither raises IllegalArgumentException.
-
-**Call:** `GET /headless/invoke/analytics/analytics-home/subscribe-dialog/get-notification-info`
-
-**Inputs:**
-
-- `recordId` *(`String`)*
-- `source` *(`String`)*
-
-**Output:** AnalyticNotification record envelope. Returns the caller's subscription state for the recordId; absent/null when the user is not subscribed.
-
-#### `read-report-subscription-user-perms`
-
-Read caller's report-subscription perm flags. Returns `{runAsAccess, subscribeToOtherUsersAccess}` derived from AnalyticsAccessCheck.CAN_SUBSCRIBE_REPORTS_RUN_AS_USER and CAN_SUBSCRIBE_REPORT_TO_OTHER_USERS — gate before scripting create-notification with run-as-user or other-user recipients.
-
-**Call:** `GET /headless/invoke/analytics/analytics-home/subscribe-dialog/get-report-subscription-user-perms`
-
-**Output:** Returns `{runAsAccess: boolean, subscribeToOtherUsersAccess: boolean}` — the two perm bits that gate the dialog's run-as picker and other-user-recipient input.
-
-#### `read-limits`
-
-Read the org's subscription capacity limits for the given `source` ("Report" or "Dashboard"). Returns max subscriptions allowed and current count. Call before create-notification to pre-check capacity.
-
-**Call:** `GET /headless/invoke/analytics/analytics-home/subscribe-dialog/get-limits`
-
-**Inputs:**
-
-- `source` *(`String`)*
-
-**Output:** Returns subscription limit info for the source type — max allowed and current usage count.
-
-#### `read-recipient-types`
-
-Read available recipient types for the report/dashboard identified by `recordId`. Returns the list of valid recipient type options (e.g. User, Group) that can be used in the create-notification `data` payload.
-
-**Call:** `GET /headless/invoke/analytics/analytics-home/subscribe-dialog/get-recipient-types`
-
-**Inputs:**
-
-- `recordId` *(`String`)*
-
-**Output:** List of objects — each with type name and availability for the given record.
-
-### Write operations
-
-#### `write-notification`
-
-Create an AnalyticNotification (subscription) from serialized `data` payload encoding recipients, schedule, run-as user, and other subscription parameters. Call read-limits first to verify capacity, and read-recipient-types to discover valid recipient options for the data payload.
-
-**Call:** `PATCH /headless/invoke/analytics/analytics-home/subscribe-dialog/create-notification`
-
-**Inputs:**
-
-- `data` *(`String`)*
-
-**Depends on:** `read-report-subscription-user-perms`, `read-limits`
-
-**Output:** A JSON response from analytics direct-REST create — created AnalyticNotification record id and resolved schedule/recipients on success.
-
-#### `update-notification`
-
-Update an existing AnalyticNotification (subscription) identified by `notificationId`. The `data` payload encodes the same fields as create-notification (recipients, schedule, run-as user). Obtain `notificationId` from a prior read-notification-info call.
-
-**Call:** `PATCH /headless/invoke/analytics/analytics-home/subscribe-dialog/save-notification`
-
-**Inputs:**
-
-- `notificationId` *(`String`)*
-- `data` *(`String`)*
-
-**Depends on:** `read-notification-info`, `read-report-subscription-user-perms`
-
-**Output:** Returns the updated AnalyticNotification REST response body on success.
-
-### Destructive operations
-
-#### `delete-unsubscribe-notification`
-
-Delete the AnalyticNotification identified by `notificationId`. Throws IllegalArgumentException if the id does not resolve to AnalyticNotification entity type. Obtain `notificationId` from a prior read-notification-info call.
-
-**Call:** `PATCH /headless/invoke/analytics/analytics-home/subscribe-dialog/unsubscribe-notification`
-
-**Inputs:**
-
-- `notificationId` *(`String`)*
-
-**Depends on:** `read-notification-info`
-
-**Output:** Returns the analytics direct-REST delete response (typically empty/success on a successful unsubscribe).

package/skills/crm-analytics-sharing-inheritance-coverage-analyze/SKILL.md

@@ -1,167 +0,0 @@
----
-name: crm-analytics-sharing-inheritance-coverage-analyze
-description: "Use this skill when users want to setup page for CRM Analytics (Wave) Sharing Inheritance Coverage. Trigger when users mention insights, setup, sharing, inheritance, coverage, insights setup sharing inheritance coverage."
-metadata:
-  version: "1.0"
----
-
-# Managing Insights Setup Sharing Inheritance Coverage
-
-## When to Use This Skill
-
-Setup page for CRM Analytics (Wave) Sharing Inheritance Coverage. Reads org-level descriptor limits, lists sObjects/datasets eligible for sharing inheritance, submits user-coverage calculation jobs (CoverageJobStatusEnum: NotStarted/InProgress/Success/Failure), polls job status, and reads back per-object/per-user coverage. 6 of 9 steps substitute to public Connect API `/wave/security/coverage/*` (insights-connect-api); the 2 org-value getters (MED_VIS_DESCRIPTOR_LIMIT, WAVE_V_S_MAX_DESCRIPTORS) and the dataset→sharingSource resolver remain Aura-canonical.
-
-## Workflow
-
-Workflow: read get-elt-limit + get-query-limit (descriptor caps driving unsupportedRecords / userCountCoverageUnknown). Discover via get-eligible-objects + get-eligible-datasets; get-object-details for per-object detail. User coverage: post-user-coverage → poll get-coverage-job until Success/Failure → read get-user-coverage. get-dataset-sharing-source resolves dataset→sObject.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Setup page requires `Insights or analytics enabled && Insights enabled && OrgPreferences.WaveSharingInheritance && Insights Data Prep Editor` (per the setup-manifest access gate). None of the individual steps enforce this directly in the Aura controller — it's the page-level gate an admin/agent must satisfy before any of these operations are reachable at all, most notably the `WaveSharingInheritance` org preference and the `InsightsEltEditor` permission, neither of which is implied by a generic Insights/Wave license. (check: `InsightsSetupSharingInheritanceCoverage page access`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `get-elt-limit` | read | implemented | `GET /headless/invoke/platform/insights-setup-sharing-inheritance-coverage` | — |
-| `get-query-limit` | read | implemented | `GET /headless/invoke/platform/insights-setup-sharing-inheritance-coverage/get-query-limit` | — |
-| `get-coverage-job` | read | proposed | `GET /services/data/v66.0/wave/security/coverage/jobs/{jobId}` | `post-user-coverage` |
-| `get-eligible-objects` | read | proposed | `GET /services/data/v66.0/wave/security/coverage/objects` | — |
-| `get-eligible-datasets` | read | proposed | `GET /services/data/v66.0/wave/security/coverage/datasets` | — |
-| `post-user-coverage` | write | proposed | `POST /services/data/v66.0/wave/security/coverage/objects/{objectApiName}/users` | `get-eligible-objects` |
-| `get-user-coverage` | read | proposed | `GET /services/data/v66.0/wave/security/coverage/objects/{objectApiName}/users` | `post-user-coverage`, `get-coverage-job` |
-| `get-object-details` | read | implemented | `GET /services/data/v66.0/wave/security/coverage/objects/{objectApiName}` | `get-eligible-objects` |
-| `get-dataset-sharing-source` | read | proposed | `GET /headless/invoke/platform/insights-setup-sharing-inheritance-coverage/get-dataset-sharing-source` | `get-eligible-datasets` |
-
-### Dependency graph
-
-```mermaid
-graph TD
-  get_elt_limit["get-elt-limit (read)"]
-  get_query_limit["get-query-limit (read)"]
-  get_coverage_job["get-coverage-job (read)"]
-  get_eligible_objects["get-eligible-objects (read)"]
-  get_eligible_datasets["get-eligible-datasets (read)"]
-  post_user_coverage["post-user-coverage (write)"]
-  get_user_coverage["get-user-coverage (read)"]
-  get_object_details["get-object-details (read)"]
-  get_dataset_sharing_source["get-dataset-sharing-source (read)"]
-  post_user_coverage --> get_coverage_job
-  get_eligible_objects --> post_user_coverage
-  post_user_coverage --> get_user_coverage
-  get_coverage_job --> get_user_coverage
-  get_eligible_objects --> get_object_details
-  get_eligible_datasets --> get_dataset_sharing_source
-```
-
-### Read operations
-
-#### `get-elt-limit`
-
-Read `MED_VIS_DESCRIPTOR_LIMIT` org-value (integer): per-record descriptor cap gating medium-visibility sharing predicates. AURA-IS-CANONICAL — no public Connect/Tooling/Metadata/sObject surface exposes this org-value.
-
-**Call:** `GET /headless/invoke/platform/insights-setup-sharing-inheritance-coverage`   — status: `implemented`
-
-**Output:** Returns an integer — the medium-visibility descriptor limit per the spec's `SharingInheritanceCoveragePageAuraGeteltlimitRepresentation` (type: integer, format: int32).
-
-#### `get-query-limit`
-
-Read `WAVE_V_S_MAX_DESCRIPTORS` org-value (integer): per-user descriptor ceiling driving `userCountCoverageUnknown` in user-coverage results. AURA-IS-CANONICAL — no public surface exposes this org-value.
-
-**Call:** `GET /headless/invoke/platform/insights-setup-sharing-inheritance-coverage/get-query-limit`   — status: `implemented`
-
-**Output:** Returns an integer — the per-user max-descriptors ceiling per the spec's `SharingInheritanceCoveragePageAuraGetquerylimitRepresentation` (type: integer, format: int32).
-
-#### `get-coverage-job`
-
-Read sharing-inheritance coverage job status by jobId. Returns CoverageJobRepresentation: status (CoverageJobStatusEnum: NotStarted/InProgress/Success/Failure), target object AssetReference, message, userCoverage URL for the read-back.
-
-**Call:** `GET /services/data/v66.0/wave/security/coverage/jobs/{jobId}`   — status: `proposed`
-
-**Inputs:**
-
-- `JOB_ID` *(`String`)*
-
-**Depends on:** `post-user-coverage`
-
-**Output:** CoverageJobRepresentation: status (CoverageJobStatusEnum), object (AssetReference to the target sObject), message (string), userCoverage (ConnectUri to the get-user-coverage read-back).
-
-#### `get-eligible-objects`
-
-List sObjects whose access can be governed via sharing inheritance. Each ObjectCoverageRepresentation carries eligibleSharingSource, name, namespace, label, securityFields, url, and unsupportedRecords (records exceeding the medium-visibility descriptor limit).
-
-**Call:** `GET /services/data/v66.0/wave/security/coverage/objects`   — status: `proposed`
-
-**Output:** {objectsCovered: array of ObjectCoverageRepresentation}, where each row has eligibleSharingSource (boolean), name, namespace, label, securityFields (array), url (ConnectUri), unsupportedRecords (UnsupportedRecordCollectionRepresentation with values + count).
-
-#### `get-eligible-datasets`
-
-Get the org-wide dataset sharing-inheritance roll-up — total datasets, count whose sharing source is eligible, the resulting coverage percentage, a per-entity occurrence count, and asset references for the eligible datasets.
-
-**Call:** `GET /services/data/v66.0/wave/security/coverage/datasets`   — status: `proposed`
-
-**Output:** DatasetCoverageSummaryRepresentation: totalDatasets (integer), totalDatasetsCovered (integer), coveragePercentage (number), entityCount (object), datasetsCovered (array of AssetReferenceRepresentation).
-
-#### `get-user-coverage`
-
-Read user-coverage breakdown for the given sObject after the job completes: coveragePercentage, userCountCovered, userCountNotCovered, userCountCoverageUnknown (capped by WAVE_V_S_MAX_DESCRIPTORS), plus per-user usersNotCovered details.
-
-**Call:** `GET /services/data/v66.0/wave/security/coverage/objects/{objectApiName}/users`   — status: `proposed`
-
-**Inputs:**
-
-- `OBJECT_NAME_PARAM` *(`String`)*
-
-**Depends on:** `post-user-coverage`, `get-coverage-job`
-
-**Output:** UserCoverageRepresentation: object (AssetReference), coveragePercentage (number), userCountCovered (integer), userCountNotCovered (integer), userCountCoverageUnknown (integer), usersNotCovered (array of UserCoverageDetailRepresentation with id/name/descriptorCount/reason), coverageJob (AssetReference to the producing job).
-
-#### `get-object-details`
-
-Read sharing-inheritance detail for one sObject: eligibleSharingSource flag, name/namespace/label, securityFields, self-URL, and unsupportedRecords (records whose descriptor count exceeds the MED_VIS_DESCRIPTOR_LIMIT from get-elt-limit).
-
-**Call:** `GET /services/data/v66.0/wave/security/coverage/objects/{objectApiName}`   — status: `implemented`
-
-**Inputs:**
-
-- `OBJECT_NAME_PARAM` *(`String`)*
-
-**Depends on:** `get-eligible-objects`
-
-**Output:** ObjectCoverageRepresentation: eligibleSharingSource (boolean), name, namespace, label (strings), securityFields (array of string), url (ConnectUri), unsupportedRecords (UnsupportedRecordCollectionRepresentation with values + count).
-
-#### `get-dataset-sharing-source`
-
-Resolve a dataset (id or developer name) to its sharingSource sObject AssetReference. AURA-IS-CANONICAL: controller atomically resolves dataset → current version → sharingSource in one call; substituting splits into two round-trips losing atomicity.
-
-**Call:** `GET /headless/invoke/platform/insights-setup-sharing-inheritance-coverage/get-dataset-sharing-source`   — status: `proposed`
-
-**Inputs:**
-
-- `DATASET_ID_PARAM` *(`String`)*
-
-**Depends on:** `get-eligible-datasets`
-
-**Output:** AssetReferenceRepresentation: id (ID), name, label, description (strings), url (ConnectUri) — pointing at the source sObject the dataset inherits sharing from.
-
-### Write operations
-
-#### `post-user-coverage`
-
-Submit a sharing-inheritance user-coverage calculation for the given sObject. Returns CoverageJobRepresentation; the caller then polls get-coverage-job until status is Success or Failure, then reads get-user-coverage. Per the controller's own doc comment (SharingInheritanceCoveragePageAuraController.postUserCoverage), this endpoint "may throw an error when the report is run too often" (rate-limited) "and may also just throw a random error" — the controller's own guidance is to "make sure to handle the error code" rather than treat every thrown error as terminal; a caller/agent should be prepared to retry on failure rather than surfacing every error as a hard stop.
-
-**Call:** `POST /services/data/v66.0/wave/security/coverage/objects/{objectApiName}/users`   — status: `proposed`
-
-**Inputs:**
-
-- `OBJECT_NAME_PARAM` *(`String`)* — Value for the objec nam param field.
-
-**Depends on:** `get-eligible-objects`
-
-**Output:** CoverageJobRepresentation: status (CoverageJobStatusEnum, typically NotStarted or InProgress on submit), object (AssetReference), message, userCoverage (ConnectUri to the eventual read-back).

package/skills/crm-analytics-sonic-getting-started-configure/SKILL.md

@@ -1,55 +0,0 @@
----
-name: crm-analytics-sonic-getting-started-configure
-description: "Use this skill when users want to toggle Sonic (Data Pipelines / ELT) org prefs in Analytics Data Manager Setup. Trigger when users mention sonic, getting, started, sonic getting started."
-metadata:
-  version: "1.0"
-  accessCheck: "OrgPermissions.SonicLicensedOrg"
----
-
-# Querying Sonic Getting Started
-
-## When to Use This Skill
-
-Toggle Sonic (Data Pipelines / ELT) org prefs in Analytics Data Manager Setup. Step 1: master license, scoped by `appType` (`DataManager`→`ORG_PREFERENCE_SONIC_ENABLED`, `MulesoftDataPath`→`ORG_PREFERENCE_MDWENABLED`); atomic `BulkPrefOperation`, runs `SonicEnablementUtil.postSonicOrgPrefEnable` on enable. Step 2: one output-connector pref; controller enforces server-side allowlist (`amazonS3`, `snowflake`, `tableauHyper`, `salesforce`). Both gated on View Setup + `USER_PERMISSION_SONIC_CONSUMER`. Both AURA-IS-CANONICAL — no Connect/Tooling/Metadata/sObject equivalent; controller is value-add (atomic batch, post-enable hook, allowlist).
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Caller holds `View Setup` AND `SONIC_CONSUMER` user permissions (composed access guard `Pipeline Inspector setup access` = `UserPermissions.ViewSetup && UserPermissions.SonicConsumer`). Both controller methods throw `NoAccessException` when either is absent. (check: `Pipeline Inspector setup access`)
-- Org has the Sonic license — `OrgPermissions.SonicLicensedOrg` enabled. The connector toggles in `handleOutputConnectorPref` map every connector to `PermPrefEnabler.*.isAccessAllowed` against `ORG_PERMISSION_SONIC_LICENSED_ORG`; without the license the prefs cannot be flipped. (check: `OrgPermissions.SonicLicensedOrg`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `handleSonicPref_1` | read | implemented | `PATCH /headless/invoke/platform/sonic-getting-started/handle-sonic-pref` | — |
-| `handleOutputConnectorPref_2` | read | implemented | `PATCH /headless/invoke/platform/sonic-getting-started/handle-output-connector-pref` | — |
-
-### Read operations
-
-#### `handleSonicPref_1`
-
-Set master Sonic license org pref. Body: `value` (bool), `appType` (`DataManager`→`ORG_PREFERENCE_SONIC_ENABLED`, `MulesoftDataPath`→`ORG_PREFERENCE_MDWENABLED`); any other `appType` string (including `CdpDataManager`) is silently accepted but writes no pref — string-equality dispatch, not enum validation. Atomic `BulkPrefOperation`; on enable runs `SonicEnablementUtil.postSonicOrgPrefEnable` — NOT a narrow single-pref flip: it additionally enables `waveReplication`, `insightsIncrementalSync`, and `waveReplicationEnabled` org-wide via `InsightsUtilImpl.enableReplicationPermsAndPrefs` (confirmed against Core source + `SonicEnablementTest`'s own doc comment). AURA-IS-CANONICAL — atomic batch + this wider replication-enablement side effect not reconstructable from a generic pref-write.
-
-**Call:** `PATCH /headless/invoke/platform/sonic-getting-started/handle-sonic-pref`   — status: `implemented`
-
-**Inputs:**
-
-- `value` *(`boolean`)*
-- `appType` *(`String`)*
-
-#### `handleOutputConnectorPref_2`
-
-Toggle one Sonic output-connector pref. Body: `value` (bool), `connectorpref` (one of `amazonS3`, `snowflake`, `tableauHyper`, `salesforce`; controller switches on this against `PermPrefEnabler` constants, other values throw). AURA-IS-CANONICAL — substituting drops the server-enforced allowlist (contract-fidelity gate).
-
-**Call:** `PATCH /headless/invoke/platform/sonic-getting-started/handle-output-connector-pref`   — status: `implemented`
-
-**Inputs:**
-
-- `value` *(`boolean`)*
-- `connectorpref` *(`String`)*