@salesforce/afv-skills 1.64.0 → 1.65.0

package/skills/experience-simple-record-home-configure/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: experience-simple-record-home-configure
+description: "Use this skill when users want to setup-page controller for Simple Record Home — three org-wide preferences (master enable; Related-List vs Activities-Timeline view; Multi-User Live Records), plus a composite `getInitData` read that returns the activities-view enum and the provisioning gates. Trigger when users mention simple, record, home, simple record home."
+metadata:
+  version: "1.0"
+---
+
+# Managing Simple Record Home
+
+## When to Use This Skill
+
+Setup-page controller for Simple Record Home — three org-wide preferences (master enable; Related-List vs Activities-Timeline view; Multi-User Live Records), plus a composite `getInitData` read that returns the activities-view enum and the provisioning gates. The canonical authoring surface differs per write: master-enable and related-list-view are declarative Metadata `RecordPageSettings` fields — prefer a Metadata deploy over the Aura toggle to persist them org-wide; Multi-User Live Records has no declarative equivalent, so its Aura toggle is canonical. All Aura steps stay dispatchable (and are the only surface on dispatcher-only orgs). See each step for the org-pref name, its `RecordPageSettings` field where one exists, the provisioning gate, and read-back guidance.
+
+## Verification Checklist
+
+After every write operation, confirm the effect by re-reading state:
+
+- After `handleSimpleRecordHomeToggle_1`: call `verify-handleSimpleRecordHomeToggle_1` (`GET /headless/invoke/platform/force/simple-record-home-setup-page/get-init-data`)
+- After `handleActivitiesToggle_1`: call `verify-handleActivitiesToggle_1` (`GET /headless/invoke/platform/force/simple-record-home-setup-page/get-init-data`)
+- After `handleMultiUserLiveRecordsToggle_1`: call `verify-handleMultiUserLiveRecordsToggle_1` (`GET /headless/invoke/platform/force/simple-record-home-setup-page/get-init-data`)
+
+## Operations Reference
+
+Operations grouped by purpose. Use these as the building blocks for the workflows above.
+
+### Summary
+
+| Operation | Purpose | Status | Call | Depends on |
+|-----------|---------|--------|------|------------|
+| `getInitData_1` | read | — | `GET /headless/invoke/platform/force/simple-record-home-setup-page/get-init-data` | — |
+| `handleSimpleRecordHomeToggle_1` | write | — | `PATCH /headless/invoke/platform/force/simple-record-home-setup-page/handle-simple-record-home-toggle` | — |
+| `handleActivitiesToggle_1` | write | — | `PATCH /headless/invoke/platform/force/simple-record-home-setup-page/handle-activities-toggle` | — |
+| `handleMultiUserLiveRecordsToggle_1` | write | — | `PATCH /headless/invoke/platform/force/simple-record-home-setup-page/handle-multi-user-live-records-toggle` | — |
+| `verify-handleSimpleRecordHomeToggle_1` | verify | — | `GET /headless/invoke/platform/force/simple-record-home-setup-page/get-init-data` | `handleSimpleRecordHomeToggle_1` |
+| `verify-handleActivitiesToggle_1` | verify | — | `GET /headless/invoke/platform/force/simple-record-home-setup-page/get-init-data` | `handleActivitiesToggle_1` |
+| `verify-handleMultiUserLiveRecordsToggle_1` | verify | — | `GET /headless/invoke/platform/force/simple-record-home-setup-page/get-init-data` | `handleMultiUserLiveRecordsToggle_1` |
+
+### Dependency graph
+
+```mermaid
+graph TD
+  getInitData_1["getInitData_1 (read)"]
+  handleSimpleRecordHomeToggle_1["handleSimpleRecordHomeToggle_1 (write)"]
+  handleActivitiesToggle_1["handleActivitiesToggle_1 (write)"]
+  handleMultiUserLiveRecordsToggle_1["handleMultiUserLiveRecordsToggle_1 (write)"]
+  verify_handleSimpleRecordHomeToggle_1["verify-handleSimpleRecordHomeToggle_1 (verify)"]
+  verify_handleActivitiesToggle_1["verify-handleActivitiesToggle_1 (verify)"]
+  verify_handleMultiUserLiveRecordsToggle_1["verify-handleMultiUserLiveRecordsToggle_1 (verify)"]
+  handleSimpleRecordHomeToggle_1 --> verify_handleSimpleRecordHomeToggle_1
+  handleActivitiesToggle_1 --> verify_handleActivitiesToggle_1
+  handleMultiUserLiveRecordsToggle_1 --> verify_handleMultiUserLiveRecordsToggle_1
+```
+
+### Read operations
+
+#### `getInitData_1`
+
+Reads the Simple Record Home Setup page state. Requires Customize Application; returns null otherwise. Observed body on a fresh (non-provisioned) org carries four fields: `isEacEnabled`, `isLexEnabled`, `recordHomeActivitiesDisplaySetting` (enum: `TIMELINE` | `RELATED_LIST`), and `recordHomeActivitiesDisplayOptions` (radio-option label list). Additional fields (`isSRHAllowed`, `isMultiUserLiveRecordsAllowed`, and the three persisted-preference booleans `isSimpleRecordHomeEnabled` / `isRelatedListEnabled` / `isMultiUserLiveRecordsEnabled`) are provisioning-conditional — they surface once SRH is enabled for the org. AURA-IS-CANONICAL — the composite response cannot be reconstructed from a raw persistence read.
+
+**Call:** `GET /headless/invoke/platform/force/simple-record-home-setup-page/get-init-data`
+
+### Write operations
+
+#### `handleSimpleRecordHomeToggle_1`
+
+PATCH the org-wide SRH master-enable preference (org-pref `SRHSimpleRecordHomeEnabled`). Requires Customize Application AND the `SRHSimpleRecordHomeAllowed` provisioning gate (surfaced as `isSRHAllowed` in `getInitData_1`). CANONICAL SURFACE: this preference maps to a declarative Metadata field — `RecordPageSettings.enableFullRecordView` — so to persist it org-wide, deploy `RecordPageSettings` via the Metadata API. This Aura toggle is NOT the canonical authoring surface — it stays callable (and is the only surface wired on dispatcher-only orgs), but the generic org-preference Connect endpoint (`PATCH /services/data/vXX/setup/org/preferences/{name}`) does NOT accept this pref (allowlist-gated → 404). The response body echoes the caller-supplied `toggleValue` rather than a persistence outcome — chain `verify-handleSimpleRecordHomeToggle_1` and read `isSimpleRecordHomeEnabled` for the authoritative read-back (absent on non-provisioned orgs).
+
+**Call:** `PATCH /headless/invoke/platform/force/simple-record-home-setup-page/handle-simple-record-home-toggle`
+
+#### `handleActivitiesToggle_1`
+
+Sets the Related-List vs Activities-Timeline preference (org-pref `SRHRelatedListViewEnabled`). `toggleValue: true` selects the Related-List view; `toggleValue: false` selects the Activities Timeline. Requires Customize Application and that Einstein Activity Capture is OFF (EAC forces Timeline; the call returns `false` while EAC is on). CANONICAL SURFACE: this preference maps to a declarative Metadata field — `RecordPageSettings.enableActivityRelatedList` — so deploy `RecordPageSettings` via the Metadata API to persist org config. This Aura toggle is NOT the canonical authoring surface (the generic org-preference Connect endpoint does not accept it — 404, allowlist-gated) but stays callable for driving the Setup page / dispatcher-only orgs. Request-body contract is permissive: a missing body, an unknown field, or a wrong-typed `toggleValue` all silently coerce to `false` and process as a write — construct the body carefully, no client-facing validation error surfaces. Chain `verify-handleActivitiesToggle_1` and read `recordHomeActivitiesDisplaySetting` (`TIMELINE` | `RELATED_LIST`) for the authoritative read-back.
+
+**Call:** `PATCH /headless/invoke/platform/force/simple-record-home-setup-page/handle-activities-toggle`
+
+#### `handleMultiUserLiveRecordsToggle_1`
+
+PATCH the multi-user-live-records org preference (org-pref `MultiUserLiveRecords`). Requires Customize Application AND the `isMultiUserLiveRecordsAllowed` provisioning gate (surfaced from `getInitData_1`; gated by `RecordInvalidationEnabled`). CANONICAL SURFACE: unlike the other two SRH writes, this preference has NO declarative/Metadata equivalent — it is not exposed as a `RecordPageSettings` field, and the generic org-preference Connect endpoint does not accept it (404, allowlist-gated). This Aura toggle is therefore the canonical programmatic surface for this preference. The response body echoes the caller-supplied `toggleValue` rather than a persistence outcome — chain `verify-handleMultiUserLiveRecordsToggle_1` and read `isMultiUserLiveRecordsEnabled` for the authoritative read-back (absent on non-provisioned orgs).
+
+**Call:** `PATCH /headless/invoke/platform/force/simple-record-home-setup-page/handle-multi-user-live-records-toggle`
+
+### Verify operations
+
+#### `verify-handleSimpleRecordHomeToggle_1`
+
+Re-reads the Setup-page Model after `handleSimpleRecordHomeToggle_1` to confirm the master SRH preference persisted. Same underlying operation as `getInitData_1`; the persisted value surfaces as `isSimpleRecordHomeEnabled` in the response only once SRH is provisioned for the org.
+
+**Call:** `GET /headless/invoke/platform/force/simple-record-home-setup-page/get-init-data`
+
+**Depends on:** `handleSimpleRecordHomeToggle_1`
+
+#### `verify-handleActivitiesToggle_1`
+
+Re-reads the Setup-page Model after `handleActivitiesToggle_1` to confirm the activities-view preference persisted. The persisted value surfaces as `recordHomeActivitiesDisplaySetting` (`TIMELINE` | `RELATED_LIST`) — the enum is observable on every org (unlike the provisioning-conditional booleans).
+
+**Call:** `GET /headless/invoke/platform/force/simple-record-home-setup-page/get-init-data`
+
+**Depends on:** `handleActivitiesToggle_1`
+
+#### `verify-handleMultiUserLiveRecordsToggle_1`
+
+Re-reads the Setup-page Model after `handleMultiUserLiveRecordsToggle_1` to confirm the multi-user-live-records preference persisted. The persisted value surfaces as `isMultiUserLiveRecordsEnabled` in the response only once SRH is provisioned; a non-provisioned org will not surface this field.
+
+**Call:** `GET /headless/invoke/platform/force/simple-record-home-setup-page/get-init-data`
+
+**Depends on:** `handleMultiUserLiveRecordsToggle_1`
+
+## Notes
+
+- **factory_gaps:** {'kind': 'extractor_bug', 'step_id': 'getInitData_1', 'observed': 'The base SOR emitted `GET /headless/invoke/platform/simple-record-home/get-init-data`; a live probe returned "No controller mapping" on the target org.', 'correct': 'GET /headless/invoke/platform/force/simple-record-home-setup-page/get-init-data — matches the pattern the three PATCH write steps already use.', 'scope': "The same emit affects the spec's four path keys (all under the wrong prefix). SOR path + spec path keys corrected via overlays; source fix belongs in the pipeline-v2 emitter."}, {'kind': 'probe_environment', 'symptom': '`/headless/metadata` returns "No controller mapping" on the dev org — the Metadata-API deploy surface is not routed there.', 'impact': "The canonical `RecordPageSettings` deploy (enableFullRecordView / enableActivityRelatedList) could not be exercised live on this org; the org-pref → RecordPageSettings mapping was instead confirmed from the platform's canonical metadata definition.", 'disposition': 'Bucket-III coverage_gap RESOLVED (see `/notes/coverage_gap`). Canonical declarative surface confirmed via Core for two of the three writes; AURA-IS-CANONICAL overturned for those two and retained only for multi-user-live-records (no declarative equivalent) + the getInitData composite read.'}

package/skills/experience-static-resources-configure/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: experience-static-resources-configure
+description: "Use this skill when users want to tooling sObject CRUD for StaticResource (UDD setup entity; Data API does not expose setup-entity records). Trigger when users mention static, resources, static resources."
+metadata:
+  version: "1.0"
+---
+
+# Managing Static Resources
+
+## When to Use This Skill
+
+Tooling sObject CRUD for StaticResource (UDD setup entity; Data API does not expose setup-entity records). Holds binary or text assets (CSS, JS, images, archive bundles) addressable from Visualforce / LWC / Aura / community sites; CacheControl Public|Private gates cross-org/anonymous fetchability of the served URL. Tooling sObject is the canonical programmatic CRUD surface; Metadata API SOAP type StaticResource is the deploy/retrieve transport, not per-record CRUD. Image-only domain helpers under platform.interaction-builder (createImageStaticResource / getImageStaticResources) narrow content-type and orderBy. Customize Application user permission required to write.
+
+## Critical Constraints
+
+**Preconditions:**
+
+- Caller needs the Customize Application user permission to write StaticResource records (standard gate for setup-entity writes; Tooling sObject CRUD enforces it). (check: `PermissionsCustomizeApplication`)
+- API access on Tooling — UDD setup entity, Data API does not expose the StaticResource sObject.
+
+**Destructive operations — require explicit user confirmation:**
+
+- **`delete_StaticResource_1`** — Delete a StaticResource record by Id via the Tooling/sObject API. The {id} path parameter is the record Id.
+  - 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 |
+|-----------|---------|--------|------|------------|
+| `list_StaticResource_1` | read | — | `query.StaticResource` | — |
+| `get_StaticResource_1` | read | — | `sobjects/StaticResource/{id}` | — |
+| `create_StaticResource_1` | write | — | `sobjects/StaticResource` | — |
+| `update_StaticResource_1` | write | — | `sobjects/StaticResource/{id}` | — |
+| `delete_StaticResource_1` | delete | — | `sobjects/StaticResource/{id}` | — |
+
+### Read operations
+
+#### `list_StaticResource_1`
+
+SOQL list via Tooling. {q} is the SOQL string, e.g. SELECT Id, Name, NamespacePrefix, ContentType, BodyLength, CacheControl, Description FROM StaticResource.
+
+**Call:** `query.StaticResource`
+
+#### `get_StaticResource_1`
+
+GET single StaticResource by Id via Tooling sObject. Returns the record envelope plus FullName and Metadata (cacheControl, contentType, description — the deploy-shape mirror).
+
+**Call:** `sobjects/StaticResource/{id}`
+
+### Write operations
+
+#### `create_StaticResource_1`
+
+POST new StaticResource via Tooling sObject — Name, Body (base64 binary/text), ContentType (MIME), CacheControl (Public|Private gates served-URL public fetchability), Description. Image-only alternate platform.interaction-builder.createImageStaticResource defaults cacheControl=PRIVATE and surfaces DuplicateDeveloperNameException.
+
+**Call:** `sobjects/StaticResource`
+
+#### `update_StaticResource_1`
+
+Update a StaticResource record by Id via the Tooling/sObject API. The {id} path parameter is the record Id; body fields replace existing values.
+
+**Call:** `sobjects/StaticResource/{id}`
+
+### Destructive operations
+
+#### `delete_StaticResource_1`
+
+Delete a StaticResource record by Id via the Tooling/sObject API. The {id} path parameter is the record Id.
+
+**Call:** `sobjects/StaticResource/{id}`

package/skills/field-service-data-capture-form-deployer-configure/SKILL.md

@@ -1,10 +1,8 @@
 ---
 name: field-service-data-capture-form-deployer-configure
 description: "Assemble a Data Capture Flow from a JSON spec and deploy it to a connected Field Service org via the Tooling Flow sObject (JSON Metadata, no XML). Use when given a data-capture spec JSON and asked to build or deploy a DataCaptureFlow."
-user-invocable: false
 metadata:
   version: "1.0"
-  domains: ["Field Service"]
 ---
 
 # Build a Data Capture Form (Field Service Mobile)
@@ -178,3 +176,26 @@ This skill has **no executable scripts**. Auth checks, record reads, the `Dynami
 - **`fs-data-capture-reference`** (sibling library skill) — reference manual for hand-authoring patterns, prohibited patterns + exact deploy errors, visual polish HTML, supporting CustomObject/PermissionSet/CustomTab deploy. Read this when diagnosing a deploy error or extending the JSON field mappings.
 - **`fs-data-capture-form-designer`** — produces the spec this skill consumes (from prose or an image/PDF).
 - **`fs-data-capture-form-editor`** — patches an already-deployed flow in the org. Uses the same Tooling `Flow` JSON round-trip (GET Metadata → edit → PATCH) this skill uses to create.
+
+<!-- skill-validate: ignore-start -->
+<!-- codey:operations start -->
+## Operations Reference
+
+Operations this skill uses — routing and dependency reference.
+
+| Operation | Purpose | Status | Call | Depends on |
+|-----------|---------|--------|------|------------|
+| `check-org-auth` | verify | — | `GET /services/data/v67.0/query` | — |
+| `check-flow-name-collision` | read | — | `GET /services/data/v67.0/tooling/query` | `check-org-auth` |
+| `verify-flow-deployed` | verify | — | `GET /services/data/v67.0/tooling/query` | `deploy-flow-metadata-json` |
+| `attach-ddc-to-parent` | write | — | `POST /services/data/v67.0/sobjects/DynamicDataCapture` | `verify-flow-deployed` |
+| `verify-ddc-attached` | verify | — | `GET /services/data/v67.0/query` | `attach-ddc-to-parent` |
+| `verify-parent-object-sharing-model` | verify | — | `GET /services/data/v67.0/tooling/query` | `verify-ddc-attached` |
+| `toggle-fss-sharing-flags` | write | — | `PATCH /headless/invoke/platform/field-service-operations-setup-page/save-field-service-settings-config` | `verify-parent-object-sharing-model` |
+| `verify-fss-sharing-flags` | verify | — | `GET /services/data/v67.0/tooling/query` | `toggle-fss-sharing-flags` |
+| `list-workorder-layouts-by-profile` | read | — | `GET /services/data/v67.0/tooling/query` | `verify-fss-sharing-flags` |
+| `rollback-detach-ddc` | write | — | `DELETE /services/data/v67.0/sobjects/DynamicDataCapture/{id}` | — |
+| `deploy-flow-metadata-json` | write | — | `POST /services/data/v67.0/tooling/sobjects/Flow` | `check-flow-name-collision` |
+| `patch-layout-add-ddc-related-list` | read | — | `GET /services/data/v67.0/tooling/sobjects/Layout/{id}` | `list-workorder-layouts-by-profile` |
+<!-- codey:operations end -->
+<!-- skill-validate: ignore-end -->

package/skills/field-service-data-capture-form-designer-configure/SKILL.md

@@ -1,10 +1,8 @@
 ---
 name: field-service-data-capture-form-designer-configure
-description: "Design a Field Service Mobile Data Capture Flow from either a natural-language description OR a PDF/image of an existing paper form. Extracts field labels, types, required-state, and section structure into an intermediate JSON spec, confirms the plan with the user, then hands off to fs-data-capture-form-deployer for compile + deploy. Handles both input modes in one skill — prose ('build a Field Service form for asset inspection', 'make a DataCaptureFlow that asks the technician to…', 'create an inventory transfer form') and visual sources ('convert this PDF to a Data Capture Flow', 'make a Field Service form from this image', 'turn this paper form into a DataCaptureFlow'). Detects the input mode automatically from a .pdf/.png/.jpg/.jpeg path, else extracts from the prose. Do NOT use this skill to patch an already-deployed flow — that's fs-data-capture-form-editor."
-user-invocable: false
+description: "Design a Field Service Mobile Data Capture Flow from either a natural-language description OR a PDF/image of an existing paper form. Extracts field labels, types, required-state, and section structure into an intermediate JSON spec, confirms the plan with the user, then hands off to `fs-data-capture-form-deployer` for compile + deploy. Handles both input modes in one skill — prose (\"build a Field Service form for asset inspection that captures…\", \"make a DataCaptureFlow that asks the technician to…\", \"create an inventory transfer form with…\") and visual sources (\"convert this PDF to a Data Capture Flow\", \"make a Field Service form from this image\", \"turn this paper form into a DataCaptureFlow\"). Detects the input mode automatically: if the user supplies a `.pdf`, `.png`, `.jpg`, or `.jpeg` path, extract from the visual source; otherwise extract from the prose. Do NOT use this skill to patch an already-deployed flow — that's `fs-data-capture-form-editor`."
 metadata:
   version: "1.0"
-  domains: ["Field Service"]
 ---
 
 # Design a Data Capture Form (from prose or from an image / PDF)
@@ -108,3 +106,15 @@ After a successful deploy, the flow exists but is invisible from the Forms tab o
 
 - `reference/extraction-from-prompt.md` — prose-evidence rules for picking field types from user descriptions, screen grouping, visibility rules, outcome-elicitation, validation checklist. Used in **prose mode**.
 - `reference/extraction-from-image.md` — control-evidence rules for picking field types from rendered widgets, repeater extraction rules, screen grouping, visibility rules, outcome-elicitation, validation checklist. Used in **image / PDF mode**.
+
+<!-- skill-validate: ignore-start -->
+<!-- codey:operations start -->
+## Operations Reference
+
+Operations this skill uses — routing and dependency reference.
+
+| Operation | Purpose | Status | Call | Depends on |
+|-----------|---------|--------|------|------------|
+| `handoff-to-deployer` | write | — | → `sfs-mobile-core-experience/fs-data-capture-form-deployer` | — |
+<!-- codey:operations end -->
+<!-- skill-validate: ignore-end -->

package/skills/field-service-mobile-branding-configure/SKILL.md

@@ -1,10 +1,8 @@
 ---
 name: field-service-mobile-branding-configure
-description: "Derive a Field Service mobile app color scheme from a brand source (URL, hex codes, brand-guide paste, or color description), validate WCAG AA contrast in both light and dark mode, and apply the 14-field scheme to the org-default FieldServiceMobileSettings record. Trigger phrases include 'brand the mobile app', 'apply branding to Field Service mobile', 'update the mobile app colors', 'use this brand guide for the app', 'set the color scheme for the mobile app'. Do NOT use this skill for Dispatcher console / Gantt branding, Experience Cloud BrandingSet records, or scheduling policy colors — out of scope."
-user-invocable: false
+description: "Derive a Field Service mobile app color scheme from a brand source (URL, hex codes, brand-guide paste, or color description), validate WCAG AA contrast in both light and dark mode, and apply the 14-field scheme to the org-default `FieldServiceMobileSettings` record. Trigger phrases include \"brand the mobile app\", \"apply branding to Field Service mobile\", \"update the mobile app colors\", \"use this brand guide for the app\", \"set the color scheme for the mobile app\". Do NOT use this skill for Dispatcher console / Gantt branding (`FSLQA__GanttPalette__c`), Experience Cloud `BrandingSet` records, or scheduling policy colors — out of scope."
 metadata:
   version: "1.0"
-  domains: ["Field Service"]
 ---
 
 # Field Service Mobile Branding
@@ -131,3 +129,19 @@ Contrast validation and scheme derivation are performed by the agent inline (see
 
 - `configure-field-service-mobile` — page layouts, permissions, and `FieldServiceSettings` toggles. This skill defers branding to here, and this skill defers structural mobile config to it.
 - `fs-data-capture-form-deployer` — generates and deploys Data Capture Flow metadata.
+
+<!-- skill-validate: ignore-start -->
+<!-- codey:operations start -->
+## Operations Reference
+
+Operations this skill uses — routing and dependency reference.
+
+| Operation | Purpose | Status | Call | Depends on |
+|-----------|---------|--------|------|------------|
+| `check-org-auth` | verify | — | `GET /services/data/v63.0/query` | — |
+| `describe-fsms-object` | verify | — | `GET /services/data/v63.0/sobjects/FieldServiceMobileSettings/describe` | `check-org-auth` |
+| `query-default-fsms-record` | read | — | `GET /services/data/v63.0/query` | `describe-fsms-object` |
+| `apply-fsms-scheme` | write | — | `PATCH /services/data/v63.0/sobjects/FieldServiceMobileSettings/{id}` | `query-default-fsms-record` |
+| `verify-fsms-scheme` | verify | — | `GET /services/data/v63.0/sobjects/FieldServiceMobileSettings/{id}` | `apply-fsms-scheme` |
+<!-- codey:operations end -->
+<!-- skill-validate: ignore-end -->