@salesforce/afv-skills 1.6.7 → 1.6.8

package/skills/generating-experience-lwr-site/docs/configure-content-view.md

@@ -1,233 +0,0 @@
-# Content Type: sfdc_cms__view
-
-**Use when** user explicitly requests creating a new page or editing an existing page.
-
-## Table of Contents
-
-- Purpose A: Generate New Views
-- Purpose B: Editing Existing Views
-
-## Purpose A: Generate New Views
-
-### Generation Guidelines
-
-**PAGE TYPES**: These guidelines supports two types of pages:
-
-1. **Custom Pages** - Single view pages for custom content (e.g., About Us). **Note**: Standard pages (e.g., Home, Login) come pre-built with the site and cannot be created.
-2. **Object Pages** - Requires 3 views: Detail, List, and Related List (e.g., Account, custom objects)
-
-### Core Principles
-
-1. **Route Association**: Views are referenced by routes via the `activeViewId` field.
-2. **CRITICAL**: The `viewType` MUST exactly match the `routeType` in the corresponding route.
-
-### Directory Structure (All Views)
-
-1. **Location**: Views must be created under: `digitalExperiences/site/[SITE_NAME]/sfdc_cms__view/[VIEW_NAME]/`
-2. **Required Files**:
-  - `_meta.json` - Metadata file defining the API name and type
-  - `content.json` - Content file defining the configuration and layout
-3. **Naming Convention**: Underscore-separated names, no "__c" suffix (About_Us, Account_Detail)
-
-### _meta.json Structure (All Views)
-
-The `_meta.json` file must contain:
-
-```json
-{
-  "apiName": "[VIEW_NAME]",
-  "type": "sfdc_cms__view",
-  "path": "views"
-}
-```
-
-**Rules**:
-
-- `apiName`: Must match directory name exactly. **No "__c" suffix**.
-- `type`: Always `"sfdc_cms__view"`
-- `path`: Always `"views"`
-
-### Theme Layout Type (All Views)
-
-The `contentBody.themeLayoutType` field specifies which theme layout to use for the view. There can only be one per view.
-
-- **Default**: `"Inner"` - Use this default if the user does not specify a layout OR if the lookup fails to find a matching layoutType
-- **Lookup**: To find valid values:
-    1. Navigate up from the current view directory to the site directory
-    2. Look in `sfdc_cms__theme/` (sibling directory to `sfdc_cms__view/`)
-    3. Find the theme directory (typically one per site)
-    4. Check `content.json` → `contentBody.layouts[]` for the layouts array
-
-- **Layout Name/ID Resolution**: If the user provides only a layout name or ID (e.g., "scopedHeaderAndFooter"), you must look up the corresponding `layoutType`:
-    1. Find the theme's `content.json` as described above
-    2. Locate the `contentBody.layouts` array containing `layoutId`/`layoutType` pairs
-    3. Match the user-provided name/ID against `layoutId` values
-    4. Use the corresponding `layoutType` value for `contentBody.themeLayoutType`
-    5. **Use ONLY the `layoutType` value** for `contentBody.themeLayoutType` - do NOT use the layoutId or user's provided name
-    6. **If no match is found, use the default `"Inner"`**
-
-### PART A: CUSTOM PAGES
-
-Use this section when creating single-view custom content pages.
-
-#### A.1. content.json Structure
-
-The `content.json` file must contain:
-
-```json
-{
-  "type": "sfdc_cms__view",
-  "title": "[DISPLAY_TITLE]",
-  "contentBody": {},
-  "urlName": "[URL_NAME]"
-}
-```
-
-**Field Definitions**:
-
-- `type`: Always `"sfdc_cms__view"`
-- `title`: Human-readable display title (e.g., About Us)
-- `contentBody`: Include all `required` properties from `schemaDefinition`. Use `examplesOfContentType` for reference.
-- `urlName`: Lowercase with hyphens (e.g., `about-us`)
-
-#### A.2. Component Structure
-
-**MUST** use `community_layout:sldsFlexibleLayout` as the root with exactly 2 regions (`content` and `sfdcHiddenRegion`), even if no components exist:
-
-```
-community_layout:sldsFlexibleLayout (root)
-├── content (region) — main page content
-└── sfdcHiddenRegion (region) — hidden region for SEO and metadata
-```
-
-**CRITICAL REQUIREMENTS**:
-
-- **Region names are fixed**: The region `name` field MUST be exactly `content` or `sfdcHiddenRegion`. Do NOT invent custom region names.
-- **sfdcHiddenRegion MUST contain seoAssistant**: The `sfdcHiddenRegion` region MUST ALWAYS include a `community_builder:seoAssistant` component in its `children` array.
-- **Components live in children**: All components are placed inside the `children` array of a region. Use an empty `children: []` array for `content` if no components exist.
-
-Each region requires: `id` (unique UUID), `name`, `title`, `type: "region"`, `children`. Do not add any other fields.
-
-#### A.3. Naming Conventions Summary
-
-| Field | Format | Example |
-|-|-|-|
-| Directory/apiName | Underscore-separated, no "__c" | `About_Us` |
-| title | Human-readable | `About Us` |
-| viewType | `custom-` + lowercase-hyphens | `custom-about-us` |
-| urlName | Lowercase-hyphens | `about-us` |
-
-#### A.4. Route Dependency
-
-The route's `activeViewId` must match the view's directory name exactly.
-
-#### A.5. Generation Checklist
-
-- [ ] Directory and `_meta.json` follow structure (see Directory Structure, _meta.json Structure)
-- [ ] `content.json` has all required fields (A.1)
-- [ ] Component structure correct with both regions (A.1)
-- [ ] **CRITICAL**: Complete all the UUID generation steps. see [handle-component-and-region-ids.md](docs/handle-component-and-region-ids.md)
-- [ ] `viewType` matches route's `routeType` (CRITICAL)
-
-### PART B: OBJECT PAGES
-
-Use this section when creating object pages that require Detail, List, and Related List views.
-
-#### B.1. Overview
-
-Object pages require **three views**: Detail, List, and Related List. All share the same object name.
-
-**Object Types & viewType Format**:
-
-| Object Type | Identifier | viewType Example |
-|-|-|-|
-| Standard (Account, Contact) | `keyPrefix` (3-char) | `detail-001`, `list-001`, `relatedlist-001` |
-| Custom (Test_Object__c) | API name with `__c` | `detail-Test_Object__c`, `list-Test_Object__c` |
-
-Obtain object information from the `objectList` MCP output from `sfdc_cms__route`:
-
-```json
-[
-   ["Label", "ApiName", "KeyPrefix", "IsCustom"]
-]
-```
-
-#### B.2. Required Views
-
-Create three directories under `sfdc_cms__view/`:
-
-- `[OBJECT_NAME]_Detail/`
-- `[OBJECT_NAME]_List/`
-- `[OBJECT_NAME]_Related_List/`
-
-#### B.3. content.json Structure
-
-```json
-{
-  "type": "sfdc_cms__view",
-  "title": "[OBJECT_NAME] [TYPE]",
-  "contentBody": {
-    "component": {},
-    "dataProviders": [],
-    "themeLayoutType": "[THEME_LAYOUT_TYPE]",
-    "viewType": "[PREFIX]-[IDENTIFIER]"
-  },
-  "urlName": "[OBJECT_NAME_LOWERCASE]-[TYPE]"
-}
-```
-
-**Field Definitions**:
-
-- `type`: Always `"sfdc_cms__view"`
-- `title`: Human-readable (e.g., "Account Detail")
-- `contentBody`: Include all `required` properties from `schemaDefinition`. Use `examplesOfContentType` for reference.
-- `contentBody.viewType`: **CRITICAL**: Must exactly match route's `routeType`
-- `urlName`: Lowercase with hyphens (e.g., `account-detail`)
-
-**Rules**:
-
-- Before any actions, *always* call `execute_metadata_action` to get the full schema and examples per the skill document.
-
-#### B.4. Component Structure
-
-Uses same structure as Part A.1 (Component Structure) with these SEO assistant differences:
-
-- **Detail View**: `pageTitle: "{!Record._Object}: {!Record._Title}"`
-- **List/Related List Views**: `recordId: "{!recordId}"` (no pageTitle)
-
-Default template includes one section with one empty column. `seedComponents` must be `[]` (not `null`).
-
-#### B.5. Naming Conventions Summary
-
-| Field | Detail | List | Related List |
-|-|-|-|-|
-| Directory/apiName | `[Object]_Detail` | `[Object]_List` | `[Object]_Related_List` |
-| title | `[Object] Detail` | `[Object] List` | `[Object] Related List` |
-| viewType (Standard) | `detail-[keyPrefix]` | `list-[keyPrefix]` | `relatedlist-[keyPrefix]` |
-| viewType (Custom) | `detail-[ApiName__c]` | `list-[ApiName__c]` | `relatedlist-[ApiName__c]` |
-| urlName | `[object]-detail` | `[object]-list` | `[object]-related-list` |
-
-#### B.6. Route Dependency
-
-The route's `activeViewId` must match the view's directory name exactly. The `viewType` must exactly match the route's `routeType`.
-
-#### B.7. Generation Checklist
-
-- [ ] Object type determined; identifier obtained (`keyPrefix` or API name with `__c`)
-- [ ] All three views created: **Detail**, **List**, and **Related List**, each with `_meta.json` and `content.json`
-- [ ] `viewType` matches route's `routeType` for all three views (CRITICAL)
-- [ ] Component structure correct with both regions (see A.1)
-- [ ] SEO assistant configured correctly per view type (B.4)
-- [ ] **CRITICAL**: Complete both UUID generation steps. see [handle-component-and-region-ids.md](docs/handle-component-and-region-ids.md)
-
-## Purpose B: Editing Existing Views
-
-Use this section when modifying existing views under the `sfdc_cms__view` directory.
-
-### Component Modifications
-
-When adding, removing, or configuring components in existing views, **always** refer to [handle-ui-components.md](docs/handle-ui-components.md) for placement hierarchy, component structure, column layout, and property configuration.
-
-### Theme Layout Type
-
-To change a view's theme layout, update `contentBody.themeLayoutType` in the view's `content.json`. See **Theme Layout Type (All Views)** for default and lookup details

package/skills/generating-experience-lwr-site/docs/configure-guest-sharing-rules.md

@@ -1,49 +0,0 @@
-# Guest User Sharing Rules (Public Sites Only)
-
-**Use when** the user asks to create or modify a guest sharing rule, mentions a username containing "Guest User" or "Site Guest User" (e.g. "ZenLease Site Guest User"), or wants to share object records with unauthenticated visitors.
-
-## Steps
-
-1. **Resolve the guest user identity**: If the user provides a username like "ZenLease Site Guest User", use it directly as the `<guestUser>` value (`CommunityNickname`). If a user ID is provided (e.g. `005AAC00003f8EP`), query the org to get the `CommunityNickname` first.
-2. **Check for existing file**: Look for `sharingRules/{ObjectName}.sharingRules-meta.xml` locally. If missing, retrieve it from the org before editing.
-3. **Generate the rule**: Follow the XML example and critical requirements below. Never use `sharingCriteriaRules` or `<role>`/`<group>` for guest rules.
-
-If `sharingRules` metadata is not available locally in `force-app/main/default/sharingRules`, retrieve it from the org before creating new rules.
-
-## Retrieve Full SharingRules Schema
-
-Use the metadata MCP tool with metadataType "SharingRules" to retrieve schema.
-
-## XML Example
-
-```xml
-<?xml version="1.0" encoding="UTF-8"?>
-<SharingRules xmlns="http://soap.sforce.com/2006/04/metadata">
-  <sharingGuestRules>
-    <fullName>ShareAccountsWithSiteGuest</fullName>
-    <accessLevel>Read</accessLevel>
-    <includeHVUOwnedRecords>false</includeHVUOwnedRecords>
-    <label>Share Accounts With Site Guest</label>
-    <sharedTo>
-      <guestUser>[site Guest User's CommunityNickanme]</guestUser>
-    </sharedTo>
-    <criteriaItems>
-      <field>Name</field>
-      <operation>notEqual</operation>
-      <value>null</value>
-    </criteriaItems>
-  </sharingGuestRules>
-</SharingRules>
-```
-
-## Critical Requirements
-
-1. **SharedTo Element**: Must use `<guestUser>{site Guest User's CommunityNickanme}</guestUser>` (not URL path prefix).
-2. **includeHVUOwnedRecords**: Required field. Set to `false` unless records owned by high-volume site users should be included.
-3. **One XML file per object**: Put all rules for a given object in one file. Do not create additional.
-
-## Common Mistakes
-
-- Using `<role>` or `<group>` instead of `<guestUser>` in sharedTo
-- Omitting the required `includeHVUOwnedRecords` field
-- Using `includeRecordsOwnedByAll` (that's for `sharingCriteriaRules`, not guest rules)

package/skills/generating-experience-lwr-site/docs/handle-component-and-region-ids.md

@@ -1,27 +0,0 @@
-# UUID Generation
-
-**Use when** handling IDs for components and regions of views. All component and region IDs in Experience Site content must be unique UUIDs.
-
-## Requirements
-
-1. **Format**: Lowercase UUID v4 (e.g., `5d56a22f-c1e8-40d3-92ec-6e10e71e36de`)
-2. **Uniqueness**: Must be unique across ALL `content.json` files in site (under `digitalExperiences/site/<SITE_NAME>/`)
-
-## For New content.json Files Only
-
-**Multistep Process (REQUIRED)**:
-
-- **CRITICAL**: Each step must be performed separately - do NOT combine steps into a single automated command or script
-- **Step 1**: Create files with descriptive placeholders for UUIDs (e.g., `UUID_CONTENT_REGION`, `UUID_HIDDEN_REGION`, `UUID_SEO_COMPONENT`)
-- **Step 2**: Count the total number of UUID placeholder occurrences in the generated file, then generate exactly that many UUIDs using:
-  - `node -e "console.log(Array.from({length: N}, () => require('crypto').randomUUID()).join('\n'))"` where N is the total count of placeholder occurrences. Present this command to the user for execution.
-- **Step 3**: Replace each placeholder occurrence sequentially with the generated UUIDs from the list, ensuring each occurrence gets a unique UUID from the list. Perform replacements one at a time or in small batches - do NOT automate this with scripts.
-- **Step 4**: Validate that all placeholders have been replaced - read the file and search for any remaining placeholder patterns (e.g., `UUID_`). The file is NOT valid until all placeholders are replaced with actual UUIDs.
-- **CRITICAL**: Every single placeholder occurrence must be replaced with a DIFFERENT UUID from the generated list, even if the placeholder name is repeated. For example, if you have 5 total placeholder occurrences, generate 5 UUIDs and replace each occurrence with the next UUID from the list.
-- **NEVER** write UUIDs inline during file creation - always use the multistep placeholder approach
-
-## For Editing Existing content.json Files
-
-- **CRITICAL**: Read file first and preserve all existing UUIDs exactly as-is
-- NEVER replace existing UUIDs with placeholders
-- For newly added components/regions only, follow the multistep placeholder process from step 3

package/skills/generating-experience-lwr-site/docs/handle-ui-components.md

@@ -1,215 +0,0 @@
-# UI Component Handling
-
-**Use when** adding/configuring components to be used in Experience site.
-
-## Component Insertion
-
-Insert custom Lightning Web Components (LWC) into views.
-
-### What is a Custom Component?
-
-Any LWC in `c` namespace (e.g., `c:heroBanner`). Distinct from OOTB components (e.g., `community_builder:htmlEditor`).
-
-### Prerequisites for Custom LWC
-
-**js-meta.xml Requirements**:
-
-- `<isExposed>true</isExposed>`
-- Targets: `lightningCommunity__Page`, `lightningCommunity__Default`
-
-**Property Type Constraints (MANDATORY GATE)**:
-
-1. **Supported**: String, Integer, Boolean, Color, Picklist
-2. **Unsupported**: Any other type → **STOP immediately**
-   - Do NOT delete, comment, or auto-correct
-   - Advise user to set up Custom Property Editor (CPE) or Custom Property Type
-3. **Type Mismatch**: `type="Number"` → change to `type="Integer"` in js-meta.xml
-
-**Do not proceed** until LWC files are compliant or user advised on CPE/CPT.
-
-### Placement Hierarchy
-
-**NEVER** place components directly in top-level regions. Must nest inside `community_layout:section` → column region.
-
-```
-community_layout:sldsFlexibleLayout (root)
-└── region (content/header/footer)
-    └── community_layout:section
-        └── region (column: col1/col2)
-            └── component(s)
-```
-
-### Column Width & Layout
-
-**12-unit grid**: Column widths sum to 12 per section.
-
-**Width Formats**:
-
-- Grid units: 8 + 4
-- Percentages: 66% + 33% → 8 + 4; 50% + 50% → 6 + 6
-- Ratios: 2:1 → 8 + 4; 1:1 → 6 + 6; equal thirds → 4 + 4 + 4
-
-**Layout Rules**:
-
-- One section = one horizontal row
-- Multiple rows = multiple sections (siblings)
-- Multiple components in column = vertical stack
-
-**Set width in** `sectionConfig` (JSON string attribute on section component).
-
-### sectionConfig Structure
-
-**Top-level** (when parsed):
-
-- `UUID`: Section ID (matches section component's `id`)
-- `columns`: Array of column definitions
-
-**Each column**:
-
-- `UUID`: Column ID (matches column region's `id`)
-- `columnKey`: Column identifier (e.g., `col1`, `col2`) - matches column region's `name`
-- `columnName`: Display name (e.g., "Column 1")
-- `columnWidth`: String from `"1"` to `"12"` (must sum to 12)
-- `seedComponents`: Array or `null` (typically `[]` or `null`)
-
-**Example** (serialized as JSON string in `sectionConfig` attribute):
-
-```json
-{
-  "UUID": "295e6a8b-fd94-485b-af9d-7ccf5b3048ee",
-  "columns": [
-    {
-      "UUID": "7e1f7e33-5ba8-4fef-8494-6ea3e90b22a0",
-      "columnKey": "col1",
-      "columnName": "Column 1",
-      "columnWidth": "12",
-      "seedComponents": null
-    }
-  ]
-}
-```
-
-### Named Region Creation
-In order to create a component with drag-n-droppable region/slot that can be used in Experience Builder sites and persist across views, there are multiple steps needed.
-
-Page layout components should add the lightningCommunity__Page_Layout target in js-meta.xml.
-Theme layout components should add the lightningCommunity__Theme_Layout target in js-meta.xml.
-Add lightningCommunity__Page as a target for page layouts and any component with slots that is not explicitly defined as a theme layout.
-
-The js file in LWC need to declare named slots:
-```js
-/**
- * @slot header
- * @slot footer
- */
-export default class YourComponentName extends LightningElement {}
-```
-
-Do not add any other comments in the declaration comment block. The named @slot annotations must be the last comments
-in the block before the class declaration.
-
-In html, named slots are needed. <slot name="header"> and <slot name="footer"> in the above example.
-
-For theme layout component, a <slot> with no name is the main content region, a slot with name is a sticky region that doesn't change from page to page that uses the same theme layout component.
-
-No need to declare target config properties for the slots/regions.
-See the example below for adding a component with named slots into a view.
-
-### Component Structure
-
-```json
-{
-  "id": "[UNIQUE_UUID]",
-  "type": "component",
-  "definition": "[NAMESPACE]:[COMPONENT_NAME]",
-  "attributes": {
-    "[ATTRIBUTE_NAME]": "[ATTRIBUTE_VALUE]"
-  }
-}
-```
-
-**Field Definitions**:
-
-- `id`: Unique UUID (see `handle-component-and-region-ids.md`)
-- `type`: Always `"component"`
-- `definition`:
-  - Custom LWC: `c:[componentName]` (e.g., `c:heroBanner`)
-  - OOTB: `[namespace]:[componentName]` (e.g., `community_builder:richTextEditor`)
-- `attributes`: Component properties
-  - **Omit if no attributes** (don't include empty object)
-  - Custom LWC: Only `@api` properties in `targetConfigs` (with `lightningCommunity__Default` target)
-  - OOTB: Only exposed schema properties
-
-### Complete Examples
-
-**Example 1: Overall structure**
-Correct nesting: `content` region → section → column region → components
-
-```json
-{
-  "type": "region",
-  "name": "content",
-  "children": [
-    {
-      "attributes": {
-        "sectionConfig": "{\"UUID\":\"295e6a8b-fd94-485b-af9d-7ccf5b3048ee\",\"columns\":[{\"UUID\":\"7e1f7e33-5ba8-4fef-8494-6ea3e90b22a0\",\"columnName\":\"Column 1\",\"columnKey\":\"col1\",\"columnWidth\":\"12\",\"seedComponents\":null}]}"
-      },
-      "children": [
-        {
-          "children": [
-            {
-              "definition": "c:testComponent",
-              "id": "2ae498bd-2871-487d-8fb1-b186376cee3b",
-              "type": "component"
-            },
-            {
-              "id": "7c7d3b6a-1e2f-4a33-9c1e-8b2a6d5f4e3b",
-              "type": "component",
-              "definition": "c:helloWorld",
-              "attributes": {
-                "title": "Hello"
-              }
-            }
-          ],
-          "id": "7e1f7e33-5ba8-4fef-8494-6ea3e90b22a0",
-          "name": "col1",
-          "title": "Column 1",
-          "type": "region"
-        }
-      ],
-      "definition": "community_layout:section",
-      "id": "295e6a8b-fd94-485b-af9d-7ccf5b3048ee",
-      "type": "component"
-    }
-  ]
-}
-```
-
-**CRITICAL**: Follow UUID generation process (`handle-component-and-region-ids.md`) when inserting components.
-
-**Example 2: Representing slots**
-If a component with slots (i.e. @slot annotation) is inserted, slots must appear as named regions.
-In this example the component threeColumn has 3 slots, named left, center, and right.
-```json
-{
-    "attributes" : { },
-    "children" : [ {
-    "id" : "4c6148c7-c07e-4245-ae50-ac07891046f2",
-    "name" : "left",
-    "title" : "left",
-    "type" : "region"
-    }, {
-    "id" : "f362e789-7f09-40b4-a59f-03f76ea73401",
-    "name" : "center",
-    "title" : "center",
-    "type" : "region"
-    }, {
-    "id" : "2678ddd4-a1a4-41c4-bf5a-1a3e55891eb2",
-    "name" : "right",
-    "title" : "right",
-    "type" : "region"
-    } ],
-    "definition" : "c:threeColumn",
-    "id" : "b9e517c5-90ac-49e9-91b7-3730512c95a3",
-    "type" : "component"
-}

package/skills/generating-experience-lwr-site/docs/update-site-urls.md

@@ -1,100 +0,0 @@
-# Updating Experience Site URLs
-
-Experience sites have a three-component architecture with two distinct URL patterns. Understanding this structure is critical when updating site URLs.
-
-## Architecture Overview
-
-Every Salesforce Experience Site consists of three components:
-
-1. **Network** (metadata: `Network`) - Network configuration
-2. **ChatterNetwork Site** (metadata: `CustomSite`) - Authentication endpoints and core site services  
-3. **ChatterNetworkPicasso Site** (metadata: `DigitalExperienceConfig` + `DigitalExperienceBundle`) - Customer-facing pages and content
-
-## URL Pattern
-
-These three components use **two different URLs**:
-
-- **Primary URL** (ChatterNetworkPicasso): Used for customer-facing pages
-  - Defined in: `DigitalExperienceConfig` → `<urlPathPrefix>`
-  - Example: `mysite`
-
-- **Secondary URL** (Network + CustomSite): Used for authentication endpoints and other services
-  - Defined in: `Network` → `<urlPathPrefix>` AND `CustomSite` → `<urlPathPrefix>`
-  - Example: `mysitevforcesite`
-  - **Must be synchronized** - both files must have identical values
-
-By default, Salesforce differentiates these URLs by appending `vforcesite` suffix to the Network/CustomSite URL.
-
-## URL Update Workflow
-
-When updating site URLs, follow this workflow:
-
-### Step 1: Discover All URL References
-
-Search for all occurrences of `urlPathPrefix` across the project metadata files.
-
-**For agents**: Use the `search_files` tool with these parameters:
-- path: `force-app/main/default`
-- regex: `urlPathPrefix`
-- file_pattern: `*.xml`
-
-**For humans**: Use your IDE's search functionality or command line tools:
-```bash
-# Using grep
-grep -r "urlPathPrefix" force-app/main/default --include="*.xml"
-
-# Using VS Code: Ctrl+Shift+F (Windows/Linux) or Cmd+Shift+F (Mac)
-# Search for: urlPathPrefix
-# Files to include: *.xml
-```
-
-### Step 2: Identify URL Groups
-
-Determine which files belong to which URL group:
-
-- **Primary URL Group**: `DigitalExperienceConfig`
-- **Secondary URL Group**: `Network` AND `CustomSite`
-
-### Step 3: Update URLs Consistently
-
-Update the `<urlPathPrefix>` value in each file:
-
-- **DigitalExperienceConfig**: Update to new primary URL
-- **Network**: Update to new secondary URL (typically primary URL + `vforcesite`)
-- **CustomSite**: Update to **same value as Network** (must be synchronized)
-
-### Step 4: Validate Naming Convention
-
-Ensure URL values follow best practices:
-- Use lowercase letters only
-- Avoid special characters except hyphens where appropriate
-- Keep URLs concise and meaningful
-
-### Step 5: Verify Consistency
-
-Before deploying, confirm:
-- [ ] Primary URL in `DigitalExperienceConfig` is set correctly
-- [ ] Secondary URL in `Network` matches `CustomSite` exactly
-- [ ] URLs are properly differentiated (typically via suffix)
-- [ ] All URL values follow naming conventions
-
-## Example URL Configuration
-
-```
-ChatterNetworkPicasso Site (Primary):
-  DigitalExperienceConfig: <urlPathPrefix>bestsupport</urlPathPrefix>
-
-Network + ChatterNetwork Site (Secondary):
-  Network:    <urlPathPrefix>bestsupportvforcesite</urlPathPrefix>
-  CustomSite: <urlPathPrefix>bestsupportvforcesite</urlPathPrefix>
-```
-
-## Common Pitfalls to Avoid
-
-❌ **Don't** update only one or two files - all three must be updated  
-❌ **Don't** use different values in Network and CustomSite  
-❌ **Don't** use the same URL for both Primary and Secondary groups  
-❌ **Don't** skip the discovery step with `search_files`  
-✅ **Do** use `search_files` to find all occurrences first  
-✅ **Do** maintain URL differentiation between the two groups  
-✅ **Do** follow lowercase naming conventions