sfdx-hardis 6.0.6-beta202508141313.0 → 6.0.7-beta202508191748.0

package/oclif.manifest.json

@@ -3,7 +3,7 @@
     "hello:world": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Says hello to the world or a specified person.**\n\nThis is a simple command used for demonstration purposes. It outputs a greeting message to the console.\n\nKey functionalities:\n\n- **Customizable Greeting:** You can specify a name using the `--name` flag to personalize the greeting.\n- **Timestamp:** The greeting includes the current date.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Flag Parsing:** It parses the `--name` flag to get the recipient of the greeting.\n- **Date Retrieval:** It gets the current date using `new Date().toDateString()`.\n- **Console Output:** It constructs the greeting message using the provided name and the current date, and then logs it to the console using `this.log()`.\n",
+      "description": "\n## Command Behavior\n\n**Says hello to the world or a specified person.**\n\nThis is a simple command used for demonstration purposes. It outputs a greeting message to the console.\n\nKey functionalities:\n\n- **Customizable Greeting:** You can specify a name using the `--name` flag to personalize the greeting.\n- **Timestamp:** The greeting includes the current date.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Flag Parsing:** It parses the `--name` flag to get the recipient of the greeting.\n- **Date Retrieval:** It gets the current date using `new Date().toDateString()`.\n- **Console Output:** It constructs the greeting message using the provided name and the current date, and then logs it to the console using `this.log()`.\n</details>\n",
       "examples": [
         "Say hello to the world:\n<%= config.bin %> <%= command.id %>",
         "Say hello to someone you know:\n<%= config.bin %> <%= command.id %> --name Astro"
@@ -221,7 +221,7 @@
     "hardis:auth:login": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Authenticates to a Salesforce org, primarily designed for CI/CD workflows.**\n\nThis command facilitates secure and automated logins to Salesforce organizations within continuous integration and continuous delivery pipelines. It leverages pre-configured authentication details, ensuring that CI/CD processes can interact with Salesforce without manual intervention.\n\nKey aspects:\n\n- **Configuration-Driven:** It relies on authentication variables and files set up by dedicated configuration commands:\n  - For CI/CD repositories: [Configure Org CI Authentication](https://sfdx-hardis.cloudity.com/hardis/project/configure/auth/)\n  - For Monitoring repositories: [Configure Org Monitoring](https://sfdx-hardis.cloudity.com/hardis/org/configure/monitoring/)\n- **Technical Org Support:** Supports authentication to a 'technical org' (e.g., for calling Agentforce from another org) by utilizing the `SFDX_AUTH_URL_TECHNICAL_ORG` environment variable. If this variable is set, the command authenticates to this org with the alias `TECHNICAL_ORG`.\n\nTo obtain the `SFDX_AUTH_URL_TECHNICAL_ORG` value, you can run `sf org display --verbose --json` and copy the `sfdxAuthUrl` field from the output.\n\n## Technical explanations\n\nThe command's technical flow involves:\n\n- **Flag Parsing:** It parses command-line flags such as `instanceurl`, `devhub`, `scratchorg`, and `debug` to determine the authentication context.\n- **Authentication Hook:** It triggers an internal authentication hook (`this.config.runHook('auth', ...`)) which is responsible for executing the actual authentication logic based on the provided flags (e.g., whether it's a Dev Hub or a scratch org).\n- **Environment Variable Check:** It checks for the presence of `SFDX_AUTH_URL_TECHNICAL_ORG` or `TECHNICAL_ORG_ALIAS` environment variables.\n- **`authOrg` Utility:** If a technical org is configured, it calls the `authOrg` utility function to perform the authentication for that specific org, ensuring it's connected and available for subsequent operations.\n- **Salesforce CLI Integration:** It integrates with the Salesforce CLI's authentication mechanisms to establish and manage org connections.\n",
+      "description": "\n## Command Behavior\n\n**Authenticates to a Salesforce org, primarily designed for CI/CD workflows.**\n\nThis command facilitates secure and automated logins to Salesforce organizations within continuous integration and continuous delivery pipelines. It leverages pre-configured authentication details, ensuring that CI/CD processes can interact with Salesforce without manual intervention.\n\nKey aspects:\n\n- **Configuration-Driven:** It relies on authentication variables and files set up by dedicated configuration commands:\n  - For CI/CD repositories: [Configure Org CI Authentication](https://sfdx-hardis.cloudity.com/hardis/project/configure/auth/)\n  - For Monitoring repositories: [Configure Org Monitoring](https://sfdx-hardis.cloudity.com/hardis/org/configure/monitoring/)\n- **Technical Org Support:** Supports authentication to a 'technical org' (e.g., for calling Agentforce from another org) by utilizing the `SFDX_AUTH_URL_TECHNICAL_ORG` environment variable. If this variable is set, the command authenticates to this org with the alias `TECHNICAL_ORG`.\n\nTo obtain the `SFDX_AUTH_URL_TECHNICAL_ORG` value, you can run `sf org display --verbose --json` and copy the `sfdxAuthUrl` field from the output.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical flow involves:\n\n- **Flag Parsing:** It parses command-line flags such as `instanceurl`, `devhub`, `scratchorg`, and `debug` to determine the authentication context.\n- **Authentication Hook:** It triggers an internal authentication hook (`this.config.runHook('auth', ...`)) which is responsible for executing the actual authentication logic based on the provided flags (e.g., whether it's a Dev Hub or a scratch org).\n- **Environment Variable Check:** It checks for the presence of `SFDX_AUTH_URL_TECHNICAL_ORG` or `TECHNICAL_ORG_ALIAS` environment variables.\n- **`authOrg` Utility:** If a technical org is configured, it calls the `authOrg` utility function to perform the authentication for that specific org, ensuring it's connected and available for subsequent operations.\n- **Salesforce CLI Integration:** It integrates with the Salesforce CLI's authentication mechanisms to establish and manage org connections.\n</details>\n",
       "examples": [
         "$ sf hardis:auth:login",
         "CI=true sf hardis:auth:login"
@@ -316,7 +316,7 @@
     "hardis:doc:fieldusage": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Retrieves and displays the usage of custom fields within a Salesforce org, based on metadata dependencies.**\n\nThis command helps identify where custom fields are referenced across various metadata components in your Salesforce environment. It's particularly useful for impact analysis before making changes to fields, or for understanding the complexity and interconnectedness of your Salesforce customizations.\n\n- **Targeted sObjects:** You can specify a comma-separated list of sObjects (e.g., `Account,Contact`) to narrow down the analysis to relevant objects. If no sObjects are specified, it will analyze all customizable sObjects.\n- **Usage Details:** For each custom field, the command lists the metadata components (e.g., Apex Classes, Visualforce Pages, Flows, Reports) that reference it, along with their types and names.\n\n!['Find custom fields usage'](https://github.com/hardisgroupcom/sfdx-hardis/raw/main/docs/assets/images/doc-fieldusage.png)\n\n## Technical explanations\n\nThe command operates by querying Salesforce's Tooling API and Metadata Component Dependency API:\n\n- **sObject Retrieval:** It first queries `EntityDefinition` to get a list of customizable sObjects, optionally filtered by the user's input.\n- **Custom Field Identification:** For each identified sObject, it queries `CustomField` to retrieve all custom fields associated with it.\n- **Dependency Lookup:** The core of the command involves querying `MetadataComponentDependency` using the IDs of the custom fields. This API provides information about which other metadata components depend on the specified fields.\n- **Data Aggregation & Reporting:** The retrieved data is then processed and formatted into a tabular output, showing the sObject name, field name, field type, dependency type, and dependency name. The results are also generated into various report formats (e.g., CSV, JSON) for further analysis.\n- **SOQL Queries:** It uses `soqlQuery` and `soqlQueryTooling` utilities to execute SOQL queries against the Salesforce org.\n",
+      "description": "\n## Command Behavior\n\n**Retrieves and displays the usage of custom fields within a Salesforce org, based on metadata dependencies.**\n\nThis command helps identify where custom fields are referenced across various metadata components in your Salesforce environment. It's particularly useful for impact analysis before making changes to fields, or for understanding the complexity and interconnectedness of your Salesforce customizations.\n\n- **Targeted sObjects:** You can specify a comma-separated list of sObjects (e.g., `Account,Contact`) to narrow down the analysis to relevant objects. If no sObjects are specified, it will analyze all customizable sObjects.\n- **Usage Details:** For each custom field, the command lists the metadata components (e.g., Apex Classes, Visualforce Pages, Flows, Reports) that reference it, along with their types and names.\n\n!['Find custom fields usage'](https://github.com/hardisgroupcom/sfdx-hardis/raw/main/docs/assets/images/doc-fieldusage.png)\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command operates by querying Salesforce's Tooling API and Metadata Component Dependency API:\n\n- **sObject Retrieval:** It first queries `EntityDefinition` to get a list of customizable sObjects, optionally filtered by the user's input.\n- **Custom Field Identification:** For each identified sObject, it queries `CustomField` to retrieve all custom fields associated with it.\n- **Dependency Lookup:** The core of the command involves querying `MetadataComponentDependency` using the IDs of the custom fields. This API provides information about which other metadata components depend on the specified fields.\n- **Data Aggregation & Reporting:** The retrieved data is then processed and formatted into a tabular output, showing the sObject name, field name, field type, dependency type, and dependency name. The results are also generated into various report formats (e.g., CSV, JSON) for further analysis.\n- **SOQL Queries:** It uses `soqlQuery` and `soqlQueryTooling` utilities to execute SOQL queries against the Salesforce org.\n</details>\n",
       "examples": [
         "$ sf hardis:doc:fieldusage",
         "$ sf hardis:doc:fieldusage --sObjects Account,Contact,Opportunity",
@@ -392,7 +392,7 @@
     "hardis:doc:flow2markdown": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Generates comprehensive Markdown documentation from a Salesforce Flow metadata file.**\n\nThis command automates the creation of human-readable documentation for Salesforce Flows, making it easier to understand their logic and behavior. It can process a single Flow file or multiple Flow files, generating a Markdown file for each.\n\nKey features include:\n\n- **Detailed Flow Description:** Extracts and presents the Flow's structure, elements, and decision logic in a clear, organized Markdown format.\n- **AI-Powered Summarization (Optional):** If [AI integration](https://sfdx-hardis.cloudity.com/salesforce-ai-setup/) is configured, the documentation will include an AI-generated summary of the Flow's purpose and functionality.\n- **Mermaid Diagram Generation:** Integrates with Mermaid to visualize the Flow's structure, providing a graphical representation alongside the textual description.\n- **History Diff (Optional):** Can generate a Markdown file showing the historical differences of the Flow, useful for tracking changes over time.\n- **PDF Export (Optional):** Allows for the generation of the documentation in PDF format for easy sharing and archiving.\n- **Interactive File Selection:** If no input file is specified, the command interactively prompts the user to select Flow files.\n\n## Technical explanations\n\nThe command leverages several internal utilities and external libraries to achieve its functionality:\n\n- **Flow Metadata Parsing:** Reads and parses the XML content of Salesforce Flow metadata files (.flow-meta.xml).\n- **Markdown Generation:** Utilizes \texttt{generateFlowMarkdownFile} to transform the parsed Flow data into a structured Markdown format.\n- **Mermaid Integration:** Employs \texttt{generateMarkdownFileWithMermaid} to embed Mermaid diagrams within the Markdown output, which are then rendered by compatible Markdown viewers.\n- **AI Integration:** If enabled, it interacts with an AI service (via \texttt{describeWithAi} option) to generate a high-level summary of the Flow.\n- **Git History Analysis:** For the --with-history flag, it uses \texttt{generateHistoryDiffMarkdown} to analyze Git history and present changes to the Flow.\n- **File System Operations:** Uses \texttt{fs-extra} for file system operations like reading input files, creating output directories (e.g., \texttt{docs/flows/}), and writing Markdown and PDF files.\n- **Salesforce CLI Integration:** Uses \texttt{@salesforce/sf-plugins-core} for command-line parsing and \texttt{setConnectionVariables} for Salesforce organization context.\n- **WebSocket Communication:** Interacts with a WebSocket client (\texttt{WebSocketClient.requestOpenFile}) to open the generated Markdown file in a VS Code tab, enhancing user experience.\n",
+      "description": "\n## Command Behavior\n\n**Generates comprehensive Markdown documentation from a Salesforce Flow metadata file.**\n\nThis command automates the creation of human-readable documentation for Salesforce Flows, making it easier to understand their logic and behavior. It can process a single Flow file or multiple Flow files, generating a Markdown file for each.\n\nKey features include:\n\n- **Detailed Flow Description:** Extracts and presents the Flow's structure, elements, and decision logic in a clear, organized Markdown format.\n- **AI-Powered Summarization (Optional):** If [AI integration](https://sfdx-hardis.cloudity.com/salesforce-ai-setup/) is configured, the documentation will include an AI-generated summary of the Flow's purpose and functionality.\n- **Mermaid Diagram Generation:** Integrates with Mermaid to visualize the Flow's structure, providing a graphical representation alongside the textual description.\n- **History Diff (Optional):** Can generate a Markdown file showing the historical differences of the Flow, useful for tracking changes over time.\n- **PDF Export (Optional):** Allows for the generation of the documentation in PDF format for easy sharing and archiving.\n- **Interactive File Selection:** If no input file is specified, the command interactively prompts the user to select Flow files.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command leverages several internal utilities and external libraries to achieve its functionality:\n\n- **Flow Metadata Parsing:** Reads and parses the XML content of Salesforce Flow metadata files (.flow-meta.xml).\n- **Markdown Generation:** Utilizes \texttt{generateFlowMarkdownFile} to transform the parsed Flow data into a structured Markdown format.\n- **Mermaid Integration:** Employs \texttt{generateMarkdownFileWithMermaid} to embed Mermaid diagrams within the Markdown output, which are then rendered by compatible Markdown viewers.\n- **AI Integration:** If enabled, it interacts with an AI service (via \texttt{describeWithAi} option) to generate a high-level summary of the Flow.\n- **Git History Analysis:** For the --with-history flag, it uses \texttt{generateHistoryDiffMarkdown} to analyze Git history and present changes to the Flow.\n- **File System Operations:** Uses \texttt{fs-extra} for file system operations like reading input files, creating output directories (e.g., \texttt{docs/flows/}), and writing Markdown and PDF files.\n- **Salesforce CLI Integration:** Uses \texttt{@salesforce/sf-plugins-core} for command-line parsing and \texttt{setConnectionVariables} for Salesforce organization context.\n- **WebSocket Communication:** Interacts with a WebSocket client (\texttt{WebSocketClient.requestOpenFile}) to open the generated Markdown file in a VS Code tab, enhancing user experience.\n</details>\n",
       "examples": [
         "$ sf hardis:doc:flow2markdown",
         "$ sf hardis:doc:flow2markdown --inputfile force-app/main/default/flows/MyFlow.flow-meta.xml",
@@ -509,7 +509,7 @@
     "hardis:doc:mkdocs-to-cf": {
       "aliases": [],
       "args": {},
-      "description": "## Command Behavior**Generates MkDocs HTML pages and uploads them to Cloudflare as a static site, secured with Cloudflare Access.**This command automates the deployment of your project's documentation (built with MkDocs) to Cloudflare Pages, making it accessible and secure. It handles the entire process from HTML generation to Cloudflare configuration.Key operations performed:- **MkDocs HTML Generation:** Builds the MkDocs project into static HTML pages. It can use a locally installed `mkdocs-material` or a `mkdocs` Docker image.- **Cloudflare Pages Project Creation/Update:** Creates a new Cloudflare Pages project if one doesn't exist for your documentation, or updates an existing one.- **Cloudflare Access Policy Assignment:** Assigns a policy to restrict access to the deployed application, ensuring only authorized users can view your documentation.- **Cloudflare Access Application Setup:** Configures a Cloudflare Access application for the deployed site, integrating it with your Zero Trust policies.- **HTML Page Upload:** Deploys the generated HTML pages to Cloudflare Pages.- **Browser Opening (Non-CI):** Opens the newly deployed website in your default browser if the command is not run in a CI/CD environment.**Prerequisite:** The documentation must have been previously generated using `sf hardis:doc:project2markdown --with-history`.**Customization:** You can override default styles by customizing your `mkdocs.yml` file.More information can be found in the [Documentation section](https://sfdx-hardis.cloudity.com/salesforce-project-documentation/).**Environment Variables for Cloudflare Configuration:**| Variable                                  | Description                                                              | Default                               || :---------------------------------------- | :----------------------------------------------------------------------- | :------------------------------------: || `CLOUDFLARE_EMAIL`                        | Cloudflare account email                                                 | _Required_                            || `CLOUDFLARE_API_TOKEN`                    | Cloudflare API token                                                     | _Required_                            || `CLOUDFLARE_ACCOUNT_ID`                   | Cloudflare account ID                                                    | _Required_                            || `CLOUDFLARE_PROJECT_NAME`                 | Project name, also used for the site URL                                 | Built from Git branch name            || `CLOUDFLARE_DEFAULT_LOGIN_METHOD_TYPE`    | Cloudflare default login method type                                     | `onetimepin`                          || `CLOUDFLARE_DEFAULT_ACCESS_EMAIL_DOMAIN`  | Cloudflare default access email domain                                   | `@cloudity.com`                       || `CLOUDFLARE_EXTRA_ACCESS_POLICY_ID_LIST`  | Comma-separated list of additional policy IDs to assign to the application | _Optional_                            |## Technical explanationsThe command orchestrates interactions with MkDocs, Cloudflare APIs, and Git:- **MkDocs Integration:** It calls `generateMkDocsHTML()` to execute the MkDocs build process, which converts Markdown files into static HTML. It checks for the presence of `mkdocs.yml` to ensure it's a valid MkDocs project.- **Cloudflare API Interaction:** It uses the `cloudflare` npm package to interact with the Cloudflare API. This involves:  - **Authentication:** Initializes the Cloudflare client using `CLOUDFLARE_EMAIL`, `CLOUDFLARE_API_TOKEN`, and `CLOUDFLARE_ACCOUNT_ID` environment variables.  - **Pages Project Management:** Calls `client.pages.projects.get()` to check for an existing project and `client.pages.projects.create()` to create a new one if needed.  - **Access Policy Management:** Lists existing access policies (`client.zeroTrust.access.policies.list()`) and creates a new one (`client.zeroTrust.access.policies.create()`) if the required policy doesn't exist. It configures the policy with email domain restrictions and a default login method.  - **Access Application Management:** Lists existing access applications (`client.zeroTrust.access.applications.list()`) and creates a new one (`client.zeroTrust.access.applications.create()`) for the deployed site. It then updates the application to associate it with the created access policy.- **Git Integration:** Retrieves the current Git branch name using `getCurrentGitBranch()` to construct the Cloudflare project name and branch for deployment.- **Wrangler CLI:** Uses the `wrangler` CLI (Cloudflare's developer tool) to deploy the generated HTML pages to Cloudflare Pages via `wrangler pages deploy`.- **Environment Variable Management:** Reads various environment variables to configure Cloudflare settings and project names.- **Error Handling:** Includes checks for missing `mkdocs.yml` and Cloudflare environment variables, throwing `SfError` when necessary.",
+      "description": "## Command Behavior**Generates MkDocs HTML pages and uploads them to Cloudflare as a static site, secured with Cloudflare Access.**This command automates the deployment of your project's documentation (built with MkDocs) to Cloudflare Pages, making it accessible and secure. It handles the entire process from HTML generation to Cloudflare configuration.Key operations performed:- **MkDocs HTML Generation:** Builds the MkDocs project into static HTML pages. It can use a locally installed `mkdocs-material` or a `mkdocs` Docker image.- **Cloudflare Pages Project Creation/Update:** Creates a new Cloudflare Pages project if one doesn't exist for your documentation, or updates an existing one.- **Cloudflare Access Policy Assignment:** Assigns a policy to restrict access to the deployed application, ensuring only authorized users can view your documentation.- **Cloudflare Access Application Setup:** Configures a Cloudflare Access application for the deployed site, integrating it with your Zero Trust policies.- **HTML Page Upload:** Deploys the generated HTML pages to Cloudflare Pages.- **Browser Opening (Non-CI):** Opens the newly deployed website in your default browser if the command is not run in a CI/CD environment.**Prerequisite:** The documentation must have been previously generated using `sf hardis:doc:project2markdown --with-history`.**Customization:** You can override default styles by customizing your `mkdocs.yml` file.More information can be found in the [Documentation section](https://sfdx-hardis.cloudity.com/salesforce-project-documentation/).**Environment Variables for Cloudflare Configuration:**| Variable                                  | Description                                                              | Default                               || :---------------------------------------- | :----------------------------------------------------------------------- | :------------------------------------: || `CLOUDFLARE_EMAIL`                        | Cloudflare account email                                                 | _Required_                            || `CLOUDFLARE_API_TOKEN`                    | Cloudflare API token                                                     | _Required_                            || `CLOUDFLARE_ACCOUNT_ID`                   | Cloudflare account ID                                                    | _Required_                            || `CLOUDFLARE_PROJECT_NAME`                 | Project name, also used for the site URL                                 | Built from Git branch name            || `CLOUDFLARE_DEFAULT_LOGIN_METHOD_TYPE`    | Cloudflare default login method type                                     | `onetimepin`                          || `CLOUDFLARE_DEFAULT_ACCESS_EMAIL_DOMAIN`  | Cloudflare default access email domain                                   | `@cloudity.com`                       || `CLOUDFLARE_EXTRA_ACCESS_POLICY_ID_LIST`  | Comma-separated list of additional policy IDs to assign to the application | _Optional_                            |<details markdown=\"1\">\n<summary>Technical explanations</summary>The command orchestrates interactions with MkDocs, Cloudflare APIs, and Git:- **MkDocs Integration:** It calls `generateMkDocsHTML()` to execute the MkDocs build process, which converts Markdown files into static HTML. It checks for the presence of `mkdocs.yml` to ensure it's a valid MkDocs project.- **Cloudflare API Interaction:** It uses the `cloudflare` npm package to interact with the Cloudflare API. This involves:  - **Authentication:** Initializes the Cloudflare client using `CLOUDFLARE_EMAIL`, `CLOUDFLARE_API_TOKEN`, and `CLOUDFLARE_ACCOUNT_ID` environment variables.  - **Pages Project Management:** Calls `client.pages.projects.get()` to check for an existing project and `client.pages.projects.create()` to create a new one if needed.  - **Access Policy Management:** Lists existing access policies (`client.zeroTrust.access.policies.list()`) and creates a new one (`client.zeroTrust.access.policies.create()`) if the required policy doesn't exist. It configures the policy with email domain restrictions and a default login method.  - **Access Application Management:** Lists existing access applications (`client.zeroTrust.access.applications.list()`) and creates a new one (`client.zeroTrust.access.applications.create()`) for the deployed site. It then updates the application to associate it with the created access policy.- **Git Integration:** Retrieves the current Git branch name using `getCurrentGitBranch()` to construct the Cloudflare project name and branch for deployment.- **Wrangler CLI:** Uses the `wrangler` CLI (Cloudflare's developer tool) to deploy the generated HTML pages to Cloudflare Pages via `wrangler pages deploy`.- **Environment Variable Management:** Reads various environment variables to configure Cloudflare settings and project names.- **Error Handling:** Includes checks for missing `mkdocs.yml` and Cloudflare environment variables, throwing `SfError` when necessary.</details>\n",
       "examples": [
         "$ sf hardis:doc:mkdocs-to-cf"
       ],
@@ -581,7 +581,7 @@
     "hardis:doc:mkdocs-to-salesforce": {
       "aliases": [],
       "args": {},
-      "description": "## Command Behavior**Generates MkDocs HTML pages and deploys them to a Salesforce org as a static resource, Visualforce page, and Custom Tab.**This command provides a convenient way to host your project's documentation directly within Salesforce, making it easily accessible to users. It automates the entire process of converting your MkDocs project into a deployable Salesforce package.Key operations performed:- **MkDocs HTML Generation:** Builds the MkDocs project into static HTML pages. It can use a locally installed `mkdocs-material` or a `mkdocs` Docker image.- **Salesforce Metadata Creation:** Creates the necessary Salesforce metadata components:  - A **Static Resource** to store the generated HTML, CSS, and JavaScript files.  - A **Visualforce Page** that embeds the static resource, allowing it to be displayed within Salesforce.  - A **Custom Tab** to provide a user-friendly entry point to the documentation from the Salesforce navigation.  - A **Permission Set** to grant access to the Visualforce page and Custom Tab.- **Metadata Deployment:** Deploys these newly created metadata components to the specified Salesforce org.- **Permission Set Assignment:** Assigns the newly created permission set to the current user, ensuring immediate access to the documentation.- **Browser Opening (Non-CI):** Opens the Custom Tab in your default browser if the command is not run in a CI/CD environment.**Prerequisite:** The documentation must have been previously generated using `sf hardis:doc:project2markdown --with-history`.**Customization:**- You can specify the type of documentation to generate (e.g., `CICD` or `Monitoring`) using the `--type` flag. The default is `CICD`.- You can override default styles by customizing your `mkdocs.yml` file.More information can be found in the [Documentation section](${CONSTANTS.DOC_URL_ROOT}/salesforce-project-documentation/).## Technical explanationsThe command orchestrates interactions with MkDocs, Salesforce CLI, and file system operations:- **MkDocs Integration:** It first modifies the `mkdocs.yml` file to ensure compatibility with Salesforce static resources (e.g., setting `use_directory_urls` to `false`). Then, it calls `generateMkDocsHTML()` to build the static HTML content.- **Temporary SFDX Project:** It creates a temporary SFDX project using `createTempDir` and `createBlankSfdxProject` to stage the generated Salesforce metadata before deployment.- **Metadata Generation:** It dynamically creates the XML metadata files for the Static Resource, Visualforce Page, Custom Tab, and Permission Set. The HTML content from the MkDocs build is moved into the static resource folder.- **Salesforce CLI Deployment:** It constructs and executes a `sf project deploy start` command to deploy the generated metadata to the target Salesforce org. It intelligently adds `--test-level RunLocalTests` for production orgs and `--test-level NoTestRun` for sandboxes.- **Permission Set Assignment:** After successful deployment, it calls `initPermissionSetAssignments` to assign the newly created permission set to the current user.- **Browser Launch:** For non-CI environments, it uses `execCommand` to open the deployed Custom Tab in the user's default browser.- **Error Handling and Cleanup:** It includes error handling for deployment failures (e.g., static resource size limits) and ensures that the `mkdocs.yml` file is restored to its original state after execution.- **File System Operations:** It extensively uses `fs-extra` for file manipulation, including creating directories, moving files, and writing XML content.",
+      "description": "\n## Command Behavior\n**Generates MkDocs HTML pages and deploys them to a Salesforce org as a static resource, Visualforce page, and Custom Tab.**\n\nThis command provides a convenient way to host your project's documentation directly within Salesforce, making it easily accessible to users. It automates the entire process of converting your MkDocs project into a deployable Salesforce package.\n\nKey operations performed:\n\n- **MkDocs HTML Generation:** Builds the MkDocs project into static HTML pages. It can use a locally installed `mkdocs-material` or a `mkdocs` Docker image.\n- **Salesforce Metadata Creation:** Creates the necessary Salesforce metadata components:\n  - A **Static Resource** to store the generated HTML, CSS, and JavaScript files.\n  - A **Visualforce Page** that embeds the static resource, allowing it to be displayed within Salesforce.\n  - A **Custom Tab** to provide a user-friendly entry point to the documentation from the Salesforce navigation.\n  - A **Permission Set** to grant access to the Visualforce page and Custom Tab.\n- **Metadata Deployment:** Deploys these newly created metadata components to the specified Salesforce org.\n- **Permission Set Assignment:** Assigns the newly created permission set to the current user, ensuring immediate access to the documentation.\n- **Browser Opening (Non-CI):** Opens the Custom Tab in your default browser if the command is not run in a CI/CD environment.\n\n**Prerequisite:** The documentation must have been previously generated using `sf hardis:doc:project2markdown --with-history`.\n\n**Customization:**\n\n- You can specify the type of documentation to generate (e.g., `CICD` or `Monitoring`) using the `--type` flag. The default is `CICD`.\n- You can override default styles by customizing your `mkdocs.yml` file.\n\nMore information can be found in the [Documentation section](${CONSTANTS.DOC_URL_ROOT}/salesforce-project-documentation/).\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command orchestrates interactions with MkDocs, Salesforce CLI, and file system operations:\n\n- **MkDocs Integration:** It first modifies the `mkdocs.yml` file to ensure compatibility with Salesforce static resources (e.g., setting `use_directory_urls` to `false`). Then, it calls `generateMkDocsHTML()` to build the static HTML content.\n- **Temporary SFDX Project:** It creates a temporary SFDX project using `createTempDir` and `createBlankSfdxProject` to stage the generated Salesforce metadata before deployment.\n- **Metadata Generation:** It dynamically creates the XML metadata files for the Static Resource, Visualforce Page, Custom Tab, and Permission Set. The HTML content from the MkDocs build is moved into the static resource folder.\n- **Salesforce CLI Deployment:** It constructs and executes a `sf project deploy start` command to deploy the generated metadata to the target Salesforce org. It intelligently adds `--test-level RunLocalTests` for production orgs and `--test-level NoTestRun` for sandboxes.\n- **Permission Set Assignment:** After successful deployment, it calls `initPermissionSetAssignments` to assign the newly created permission set to the current user.\n- **Browser Launch:** For non-CI environments, it uses `execCommand` to open the deployed Custom Tab in the user's default browser.\n- **Error Handling and Cleanup:** It includes error handling for deployment failures (e.g., static resource size limits) and ensures that the `mkdocs.yml` file is restored to its original state after execution.\n- **File System Operations:** It extensively uses `fs-extra` for file manipulation, including creating directories, moving files, and writing XML content.\n</details>\n",
       "examples": [
         "$ sf hardis:doc:mkdocs-to-salesforce"
       ],
@@ -681,7 +681,7 @@
     "hardis:doc:override-prompts": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Creates local override files for AI prompt templates and variables, allowing for customization of sfdx-hardis AI interactions.**\n\nThis command sets up a `config/prompt-templates/` folder within your project. It populates this folder with `.txt` files containing the default AI prompt templates and variables used by sfdx-hardis. This enables you to tailor the AI's behavior and responses to your organization's specific needs, terminology, and coding standards.\n\nKey functionalities:\n\n- **Template Customization:** Modify templates used for generating documentation, solving deployment errors, and describing Salesforce metadata.\n- **Variable Customization:** Adjust common instruction patterns (e.g., role definitions, formatting requirements, security cautions) that are reused across multiple templates.\n- **Persistent Overrides:** Once created, these local files will override the default sfdx-hardis templates and variables, and they will not be overwritten by future sfdx-hardis updates unless explicitly requested with the `--overwrite` flag.\n\n**Important:** After running this command, you can modify any of the `.txt` files in `config/prompt-templates/` to customize the AI's behavior.\n\nAvailable templates:\n- PROMPT_SOLVE_DEPLOYMENT_ERROR\\n- PROMPT_DESCRIBE_FLOW\\n- PROMPT_DESCRIBE_FLOW_DIFF\\n- PROMPT_DESCRIBE_OBJECT\\n- PROMPT_COMPLETE_OBJECT_ATTRIBUTES_MD\\n- PROMPT_DESCRIBE_APEX\\n- PROMPT_DESCRIBE_PAGE\\n- PROMPT_DESCRIBE_PACKAGE\\n- PROMPT_DESCRIBE_PROFILE\\n- PROMPT_DESCRIBE_PERMISSION_SET\\n- PROMPT_DESCRIBE_PERMISSION_SET_GROUP\\n- PROMPT_DESCRIBE_ASSIGNMENT_RULES\\n- PROMPT_DESCRIBE_APPROVAL_PROCESS\\n- PROMPT_DESCRIBE_LWC\\n- PROMPT_DESCRIBE_AUTORESPONSE_RULES\\n- PROMPT_DESCRIBE_ESCALATION_RULES\\n- PROMPT_DESCRIBE_ROLES\n\nAvailable variables:\n- VARIABLE_OUTPUT_FORMAT_MARKDOWN_DOC\\n- VARIABLE_FORMATTING_REQUIREMENTS\\n- VARIABLE_ADDITIONAL_INSTRUCTIONS\n\nMore info on [AI Prompts documentation](https://sfdx-hardis.cloudity.com/salesforce-ai-prompts/)\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Directory Creation:** Ensures the `config/prompt-templates/` directory exists using `fs.ensureDirSync()`.\n- **File Copying:** Iterates through predefined `PROMPT_TEMPLATES` and `PROMPT_VARIABLES` objects. For each template/variable, it extracts the English text content and writes it to a corresponding `.txt` file in the `config/prompt-templates/` directory.\n- **Overwrite Logic:** Checks if a file already exists. If the `--overwrite` flag is provided, it overwrites the existing file; otherwise, it skips the file and logs a message.\n- **User Feedback:** Provides detailed logs about created, overwritten, and skipped files, along with instructions on how to use the customized prompts and variables.\n- **Dynamic Content:** The description itself dynamically lists available templates and variables by iterating over `PROMPT_TEMPLATES` and `PROMPT_VARIABLES` objects.\n",
+      "description": "\n## Command Behavior\n\n**Creates local override files for AI prompt templates and variables, allowing for customization of sfdx-hardis AI interactions.**\n\nThis command sets up a `config/prompt-templates/` folder within your project. It populates this folder with `.txt` files containing the default AI prompt templates and variables used by sfdx-hardis. This enables you to tailor the AI's behavior and responses to your organization's specific needs, terminology, and coding standards.\n\nKey functionalities:\n\n- **Template Customization:** Modify templates used for generating documentation, solving deployment errors, and describing Salesforce metadata.\n- **Variable Customization:** Adjust common instruction patterns (e.g., role definitions, formatting requirements, security cautions) that are reused across multiple templates.\n- **Persistent Overrides:** Once created, these local files will override the default sfdx-hardis templates and variables, and they will not be overwritten by future sfdx-hardis updates unless explicitly requested with the `--overwrite` flag.\n\n**Important:** After running this command, you can modify any of the `.txt` files in `config/prompt-templates/` to customize the AI's behavior.\n\nAvailable templates:\n- PROMPT_SOLVE_DEPLOYMENT_ERROR\\n- PROMPT_DESCRIBE_FLOW\\n- PROMPT_DESCRIBE_FLOW_DIFF\\n- PROMPT_DESCRIBE_OBJECT\\n- PROMPT_COMPLETE_OBJECT_ATTRIBUTES_MD\\n- PROMPT_DESCRIBE_APEX\\n- PROMPT_DESCRIBE_PAGE\\n- PROMPT_DESCRIBE_PACKAGE\\n- PROMPT_DESCRIBE_PROFILE\\n- PROMPT_DESCRIBE_PERMISSION_SET\\n- PROMPT_DESCRIBE_PERMISSION_SET_GROUP\\n- PROMPT_DESCRIBE_ASSIGNMENT_RULES\\n- PROMPT_DESCRIBE_APPROVAL_PROCESS\\n- PROMPT_DESCRIBE_LWC\\n- PROMPT_DESCRIBE_AUTORESPONSE_RULES\\n- PROMPT_DESCRIBE_ESCALATION_RULES\\n- PROMPT_DESCRIBE_ROLES\n\nAvailable variables:\n- VARIABLE_OUTPUT_FORMAT_MARKDOWN_DOC\\n- VARIABLE_FORMATTING_REQUIREMENTS\\n- VARIABLE_ADDITIONAL_INSTRUCTIONS\n\nMore info on [AI Prompts documentation](https://sfdx-hardis.cloudity.com/salesforce-ai-prompts/)\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Directory Creation:** Ensures the `config/prompt-templates/` directory exists using `fs.ensureDirSync()`.\n- **File Copying:** Iterates through predefined `PROMPT_TEMPLATES` and `PROMPT_VARIABLES` objects. For each template/variable, it extracts the English text content and writes it to a corresponding `.txt` file in the `config/prompt-templates/` directory.\n- **Overwrite Logic:** Checks if a file already exists. If the `--overwrite` flag is provided, it overwrites the existing file; otherwise, it skips the file and logs a message.\n- **User Feedback:** Provides detailed logs about created, overwritten, and skipped files, along with instructions on how to use the customized prompts and variables.\n- **Dynamic Content:** The description itself dynamically lists available templates and variables by iterating over `PROMPT_TEMPLATES` and `PROMPT_VARIABLES` objects.\n</details>\n",
       "examples": [
         "$ sf hardis:doc:override-prompts",
         "$ sf hardis:doc:override-prompts --overwrite"
@@ -760,7 +760,7 @@
     "hardis:doc:packagexml2markdown": {
       "aliases": [],
       "args": {},
-      "description": "## Command Behavior**Generates a Markdown documentation file from a Salesforce `package.xml` file.**This command provides a convenient way to visualize and document the metadata components defined within a `package.xml` file. It's particularly useful for:- **Understanding Project Scope:** Quickly grasp what metadata types and components are included in a specific deployment or retrieval.- **Documentation:** Create human-readable documentation of your project's metadata structure.- **Collaboration:** Share a clear overview of metadata changes with team members or stakeholders.Key features:- **Flexible Input:** You can specify the path to a `package.xml` file using the `--inputfile` flag. If not provided, the command will automatically look for `package.xml` files in the `manifest` folder.- **Customizable Output:** You can force the path and name of the output Markdown file using the `--outputfile` flag.- **VS Code Integration:** Automatically opens the generated Markdown file in a new VS Code tab for immediate review.## Technical explanationsThe command's technical implementation involves:- **XML Parsing:** It reads the content of the specified `package.xml` file and parses its XML structure to extract the metadata types and their members.- **Markdown Generation:** It utilizes the `DocBuilderPackageXML.generatePackageXmlMarkdown` utility to transform the parsed `package.xml` data into a structured Markdown format. This utility handles the formatting and organization of the metadata information.- **File System Operations:** It uses `fs-extra` (implicitly through `DocBuilderPackageXML`) to read the input `package.xml` and write the generated Markdown file.- **WebSocket Communication:** It interacts with a WebSocket client (`WebSocketClient.requestOpenFile`) to open the generated Markdown file in a VS Code tab, enhancing user experience.- **Salesforce Org Context:** It can optionally use the `target-org` flag to provide context, such as the instance URL, which might be used for generating links or additional information within the Markdown.",
+      "description": "\n## Command Behavior\n\n**Generates a Markdown documentation file from a Salesforce `package.xml` file.**\n\nThis command provides a convenient way to visualize and document the metadata components defined within a `package.xml` file. It's particularly useful for:\n\n- **Understanding Project Scope:** Quickly grasp what metadata types and components are included in a specific deployment or retrieval.\n- **Documentation:** Create human-readable documentation of your project's metadata structure.\n- **Collaboration:** Share a clear overview of metadata changes with team members or stakeholders.\n\nKey features:\n\n- **Flexible Input:** You can specify the path to a `package.xml` file using the `--inputfile` flag. If not provided, the command will automatically look for `package.xml` files in the `manifest` folder.\n- **Customizable Output:** You can force the path and name of the output Markdown file using the `--outputfile` flag.\n- **VS Code Integration:** Automatically opens the generated Markdown file in a new VS Code tab for immediate review.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **XML Parsing:** It reads the content of the specified `package.xml` file and parses its XML structure to extract the metadata types and their members.\n- **Markdown Generation:** It utilizes the `DocBuilderPackageXML.generatePackageXmlMarkdown` utility to transform the parsed `package.xml` data into a structured Markdown format. This utility handles the formatting and organization of the metadata information.\n- **File System Operations:** It uses `fs-extra` (implicitly through `DocBuilderPackageXML`) to read the input `package.xml` and write the generated Markdown file.\n- **WebSocket Communication:** It interacts with a WebSocket client (`WebSocketClient.requestOpenFile`) to open the generated Markdown file in a VS Code tab, enhancing user experience.\n- **Salesforce Org Context:** It can optionally use the `target-org` flag to provide context, such as the instance URL, which might be used for generating links or additional information within the Markdown.\n</details>\n",
       "examples": [
         "$ sf hardis:doc:packagexml2markdown",
         "$ sf hardis:doc:packagexml2markdown --inputfile manifest/package-all.xml"
@@ -977,7 +977,7 @@
     "hardis:lint:access": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Checks if specified Salesforce metadata elements (Apex classes and custom fields) have at least one permission defined in any Permission Set or Profile.**\n\nThis command is crucial for maintaining proper access control and identifying potential security vulnerabilities or misconfigurations in your Salesforce project. It helps ensure that all custom elements are accessible to the intended users through appropriate permission assignments.\n\nKey functionalities:\n\n- **Element Validation:** Verifies that Apex classes and custom fields have `enabled` (for Apex classes) or `readable`/`editable` (for custom fields) access in at least one Permission Set or Profile.\n- **Configurable Ignores:** Allows you to ignore specific elements or entire types of elements (e.g., all Apex classes, a particular custom field) using the `--elementsignored` flag or project configuration.\n- **Permission Set/Profile Filtering:** You can specify Permission Sets or Profiles to ignore during the access check using the `--ignorerights` flag.\n- **Reporting:** Generates a CSV report of all missing access elements, which can be used for auditing or further analysis.\n- **Notifications:** Integrates with notification providers (Grafana, Slack, MS Teams) to alert about missing access issues, making it suitable for CI/CD monitoring.\n- **Interactive Fix:** In non-CI environments, it offers an interactive prompt to automatically add missing accesses to selected Permission Sets.\n\nThis command is part of [sfdx-hardis Monitoring](https://sfdx-hardis.cloudity.com/salesforce-monitoring-missing-access/) and can output Grafana, Slack and MsTeams Notifications.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **File System Traversal:** Uses `glob` to find all Apex class (`.cls`) and custom field (`.field-meta.xml`) files within the specified root folder.\n- **XML Parsing:** Parses the XML content of Permission Set (`.permissionset-meta.xml`) and Profile (`.profile-meta.xml`) files to extract access configurations.\n- **Element Filtering:** Filters out elements that are explicitly ignored (via flags or configuration) or are not subject to access checks (e.g., Master-Detail fields, required fields, Custom Metadata Types, Custom Settings).\n- **Access Verification Logic:** Iterates through each element to check and verifies if it has the necessary access enabled in any of the non-ignored Permission Sets or Profiles.\n- **Data Aggregation:** Collects all elements with missing access into a `missingElements` array and `missingElementsMap` for reporting and notification purposes.\n",
+      "description": "\n## Command Behavior\n\n**Checks if specified Salesforce metadata elements (Apex classes and custom fields) have at least one permission defined in any Permission Set or Profile.**\n\nThis command is crucial for maintaining proper access control and identifying potential security vulnerabilities or misconfigurations in your Salesforce project. It helps ensure that all custom elements are accessible to the intended users through appropriate permission assignments.\n\nKey functionalities:\n\n- **Element Validation:** Verifies that Apex classes and custom fields have `enabled` (for Apex classes) or `readable`/`editable` (for custom fields) access in at least one Permission Set or Profile.\n- **Configurable Ignores:** Allows you to ignore specific elements or entire types of elements (e.g., all Apex classes, a particular custom field) using the `--elementsignored` flag or project configuration.\n- **Permission Set/Profile Filtering:** You can specify Permission Sets or Profiles to ignore during the access check using the `--ignorerights` flag.\n- **Reporting:** Generates a CSV report of all missing access elements, which can be used for auditing or further analysis.\n- **Notifications:** Integrates with notification providers (Grafana, Slack, MS Teams) to alert about missing access issues, making it suitable for CI/CD monitoring.\n- **Interactive Fix:** In non-CI environments, it offers an interactive prompt to automatically add missing accesses to selected Permission Sets.\n\nThis command is part of [sfdx-hardis Monitoring](https://sfdx-hardis.cloudity.com/salesforce-monitoring-missing-access/) and can output Grafana, Slack and MsTeams Notifications.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **File System Traversal:** Uses `glob` to find all Apex class (`.cls`) and custom field (`.field-meta.xml`) files within the specified root folder.\n- **XML Parsing:** Parses the XML content of Permission Set (`.permissionset-meta.xml`) and Profile (`.profile-meta.xml`) files to extract access configurations.\n- **Element Filtering:** Filters out elements that are explicitly ignored (via flags or configuration) or are not subject to access checks (e.g., Master-Detail fields, required fields, Custom Metadata Types, Custom Settings).\n- **Access Verification Logic:** Iterates through each element to check and verifies if it has the necessary access enabled in any of the non-ignored Permission Sets or Profiles.\n- **Data Aggregation:** Collects all elements with missing access into a `missingElements` array and `missingElementsMap` for reporting and notification purposes.\n</details>\n",
       "examples": [
         "$ sf hardis:lint:access",
         "$ sf hardis:lint:access -e \"ApexClass:ClassA, CustomField:Account.CustomField\"",
@@ -1130,7 +1130,7 @@
     "hardis:lint:metadatastatus": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Checks for inactive metadata elements within your Salesforce DX project, helping to maintain a clean and efficient codebase.**\n\nThis command identifies various types of metadata components that are marked as inactive in your local project files. Keeping metadata active and relevant is crucial for deployment success, performance, and avoiding confusion. This tool helps you pinpoint and address such inactive elements.\n\nIt specifically checks for the inactive status of:\n\n- **Approval Processes**\n- **Assignment Rules**\n- **Auto Response Rules**\n- **Escalation Rules**\n- **Flows** (specifically those in 'Draft' status)\n- **Forecasting Types**\n- **Record Types**\n- **Validation Rules**\n- **Workflow Rules**\n\n![](https://github.com/hardisgroupcom/sfdx-hardis/raw/main/docs/assets/images/detect-inactive-metadata.gif)\n\nThis command is part of [sfdx-hardis Monitoring](https://sfdx-hardis.cloudity.com/salesforce-monitoring-inactive-metadata/) and can output Grafana, Slack and MsTeams Notifications.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **File Discovery:** It uses `glob` patterns (e.g., `**/flows/**/*.flow-meta.xml`, `**/objects/**/validationRules/*.validationRule-meta.xml`) to locate relevant metadata files within your project.\n- **XML Parsing:** For each identified metadata file, it reads the XML content and parses it to extract the `active` or `status` flag (e.g., `<active>false</active>`, `<status>Draft</status>`).\n- **Status Verification:** It checks the value of these flags to determine if the metadata component is inactive.\n- **Data Aggregation:** All detected inactive items are collected into a list, including their type, name, and a severity level.\n- **Report Generation:** It generates a CSV report (`lint-metadatastatus.csv`) containing details of all inactive metadata elements, which can be used for further analysis or record-keeping.\n- **Notification Integration:** It integrates with the `NotifProvider` to send notifications (e.g., to Slack, MS Teams, Grafana) about the presence and count of inactive metadata, making it suitable for automated monitoring in CI/CD pipelines.\n- **Error Handling:** It includes basic error handling for file operations and ensures that the process continues even if some files cannot be read.\n",
+      "description": "\n## Command Behavior\n\n**Checks for inactive metadata elements within your Salesforce DX project, helping to maintain a clean and efficient codebase.**\n\nThis command identifies various types of metadata components that are marked as inactive in your local project files. Keeping metadata active and relevant is crucial for deployment success, performance, and avoiding confusion. This tool helps you pinpoint and address such inactive elements.\n\nIt specifically checks for the inactive status of:\n\n- **Approval Processes**\n- **Assignment Rules**\n- **Auto Response Rules**\n- **Escalation Rules**\n- **Flows** (specifically those in 'Draft' status)\n- **Forecasting Types**\n- **Record Types**\n- **Validation Rules**\n- **Workflow Rules**\n\n![](https://github.com/hardisgroupcom/sfdx-hardis/raw/main/docs/assets/images/detect-inactive-metadata.gif)\n\nThis command is part of [sfdx-hardis Monitoring](https://sfdx-hardis.cloudity.com/salesforce-monitoring-inactive-metadata/) and can output Grafana, Slack and MsTeams Notifications.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **File Discovery:** It uses `glob` patterns (e.g., `**/flows/**/*.flow-meta.xml`, `**/objects/**/validationRules/*.validationRule-meta.xml`) to locate relevant metadata files within your project.\n- **XML Parsing:** For each identified metadata file, it reads the XML content and parses it to extract the `active` or `status` flag (e.g., `<active>false</active>`, `<status>Draft</status>`).\n- **Status Verification:** It checks the value of these flags to determine if the metadata component is inactive.\n- **Data Aggregation:** All detected inactive items are collected into a list, including their type, name, and a severity level.\n- **Report Generation:** It generates a CSV report (`lint-metadatastatus.csv`) containing details of all inactive metadata elements, which can be used for further analysis or record-keeping.\n- **Notification Integration:** It integrates with the `NotifProvider` to send notifications (e.g., to Slack, MS Teams, Grafana) about the presence and count of inactive metadata, making it suitable for automated monitoring in CI/CD pipelines.\n- **Error Handling:** It includes basic error handling for file operations and ensures that the process continues even if some files cannot be read.\n</details>\n",
       "examples": [
         "$ sf hardis:lint:metadatastatus"
       ],
@@ -1225,7 +1225,7 @@
     "hardis:lint:missingattributes": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Checks for missing descriptions on custom fields within your Salesforce DX project.**\n\nThis command helps enforce documentation standards by identifying custom fields that lack a descriptive explanation. Comprehensive field descriptions are crucial for:\n\n- **Maintainability:** Making it easier for developers and administrators to understand the purpose and usage of each field.\n- **Data Governance:** Ensuring data quality and consistency.\n- **User Adoption:** Providing clear guidance to end-users on how to interact with fields.\n\nIt specifically targets custom fields (ending with `__c`) and excludes standard fields, managed package fields, and fields on Custom Settings or Data Cloud objects.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **File Discovery:** It uses `glob` to find all custom field metadata files (`.field-meta.xml`) within your project.\n- **Custom Setting Exclusion:** It first filters out fields belonging to Custom Settings by reading the corresponding object metadata files (`.object-meta.xml`) and checking for the `<customSettingsType>` tag. It also excludes Data Cloud objects (`__dlm`, `__dll`) and managed package fields.\n- **XML Parsing:** For each remaining custom field file, it reads the XML content and parses it using `xml2js` to extract the `fullName` and `description` attributes.\n- **Description Check:** It verifies if the `description` attribute is present and not empty for each custom field.\n- **Data Aggregation:** All custom fields found to be missing a description are collected into a list, along with their object and field names.\n- **Report Generation:** It generates a CSV report (`lint-missingattributes.csv`) containing details of all fields with missing descriptions.\n- **Notification Integration:** It integrates with the `NotifProvider` to send notifications (e.g., to Slack, MS Teams, Grafana) about the presence and count of fields with missing descriptions, making it suitable for automated quality checks in CI/CD pipelines.\n",
+      "description": "\n## Command Behavior\n\n**Checks for missing descriptions on custom fields within your Salesforce DX project.**\n\nThis command helps enforce documentation standards by identifying custom fields that lack a descriptive explanation. Comprehensive field descriptions are crucial for:\n\n- **Maintainability:** Making it easier for developers and administrators to understand the purpose and usage of each field.\n- **Data Governance:** Ensuring data quality and consistency.\n- **User Adoption:** Providing clear guidance to end-users on how to interact with fields.\n\nIt specifically targets custom fields (ending with `__c`) and excludes standard fields, managed package fields, and fields on Custom Settings or Data Cloud objects.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **File Discovery:** It uses `glob` to find all custom field metadata files (`.field-meta.xml`) within your project.\n- **Custom Setting Exclusion:** It first filters out fields belonging to Custom Settings by reading the corresponding object metadata files (`.object-meta.xml`) and checking for the `<customSettingsType>` tag. It also excludes Data Cloud objects (`__dlm`, `__dll`) and managed package fields.\n- **XML Parsing:** For each remaining custom field file, it reads the XML content and parses it using `xml2js` to extract the `fullName` and `description` attributes.\n- **Description Check:** It verifies if the `description` attribute is present and not empty for each custom field.\n- **Data Aggregation:** All custom fields found to be missing a description are collected into a list, along with their object and field names.\n- **Report Generation:** It generates a CSV report (`lint-missingattributes.csv`) containing details of all fields with missing descriptions.\n- **Notification Integration:** It integrates with the `NotifProvider` to send notifications (e.g., to Slack, MS Teams, Grafana) about the presence and count of fields with missing descriptions, making it suitable for automated quality checks in CI/CD pipelines.\n</details>\n",
       "examples": [
         "$ sf hardis:lint:missingattributes"
       ],
@@ -1320,7 +1320,7 @@
     "hardis:lint:unusedmetadatas": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Checks for unused custom labels and custom permissions within your Salesforce DX project.**\n\nThis command helps identify and report on custom labels and custom permissions that are defined in your project but do not appear to be referenced anywhere in your codebase. Identifying unused metadata is crucial for:\n\n- **Code Cleanliness:** Removing dead code and unnecessary metadata improves project maintainability.\n- **Performance:** Reducing the overall size of your metadata, which can positively impact deployment times and org performance.\n- **Clarity:** Ensuring that all defined components serve a purpose, making the codebase easier to understand.\n\nIt specifically scans for references to custom labels (e.g., `$Label.MyLabel`) and custom permissions (by their API name or label) across various file types (Apex, JavaScript, HTML, XML, etc.).\n\nThis command is part of [sfdx-hardis Monitoring](https://sfdx-hardis.cloudity.com/salesforce-monitoring-unused-metadata/) and can output Grafana, Slack and MsTeams Notifications.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **File Discovery:** It uses `glob` to find all relevant project files (Apex classes, triggers, JavaScript, HTML, XML, Aura components, Visualforce pages) and custom label (`CustomLabels.labels-meta.xml`) and custom permission (`.customPermission-meta.xml`) definition files.\n- **XML Parsing:** It uses `xml2js` to parse the XML content of `CustomLabels.labels-meta.xml` and custom permission files to extract the full names of labels and permissions.\n- **Content Scanning:** For each label and custom permission, it iterates through all other project files and checks if their names or associated labels are present in the file content. It performs case-insensitive checks for labels.\n- **Usage Tracking:** It maintains a count of how many times each custom permission is referenced. Labels are checked for any inclusion.\n- **Unused Identification:** Elements with no or very few references (for custom permissions, less than 2 to account for their own definition file) are flagged as unused.\n- **Data Aggregation:** All identified unused labels and custom permissions are collected into a list.\n- **Report Generation:** It generates a CSV report (`lint-unusedmetadatas.csv`) containing details of all unused metadata elements.\n- **Notification Integration:** It integrates with the `NotifProvider` to send notifications (e.g., to Slack, MS Teams, Grafana) about the presence and count of unused metadata, making it suitable for automated monitoring in CI/CD pipelines.\n",
+      "description": "\n## Command Behavior\n\n**Checks for unused custom labels and custom permissions within your Salesforce DX project.**\n\nThis command helps identify and report on custom labels and custom permissions that are defined in your project but do not appear to be referenced anywhere in your codebase. Identifying unused metadata is crucial for:\n\n- **Code Cleanliness:** Removing dead code and unnecessary metadata improves project maintainability.\n- **Performance:** Reducing the overall size of your metadata, which can positively impact deployment times and org performance.\n- **Clarity:** Ensuring that all defined components serve a purpose, making the codebase easier to understand.\n\nIt specifically scans for references to custom labels (e.g., `$Label.MyLabel`) and custom permissions (by their API name or label) across various file types (Apex, JavaScript, HTML, XML, etc.).\n\nThis command is part of [sfdx-hardis Monitoring](https://sfdx-hardis.cloudity.com/salesforce-monitoring-unused-metadata/) and can output Grafana, Slack and MsTeams Notifications.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **File Discovery:** It uses `glob` to find all relevant project files (Apex classes, triggers, JavaScript, HTML, XML, Aura components, Visualforce pages) and custom label (`CustomLabels.labels-meta.xml`) and custom permission (`.customPermission-meta.xml`) definition files.\n- **XML Parsing:** It uses `xml2js` to parse the XML content of `CustomLabels.labels-meta.xml` and custom permission files to extract the full names of labels and permissions.\n- **Content Scanning:** For each label and custom permission, it iterates through all other project files and checks if their names or associated labels are present in the file content. It performs case-insensitive checks for labels.\n- **Usage Tracking:** It maintains a count of how many times each custom permission is referenced. Labels are checked for any inclusion.\n- **Unused Identification:** Elements with no or very few references (for custom permissions, less than 2 to account for their own definition file) are flagged as unused.\n- **Data Aggregation:** All identified unused labels and custom permissions are collected into a list.\n- **Report Generation:** It generates a CSV report (`lint-unusedmetadatas.csv`) containing details of all unused metadata elements.\n- **Notification Integration:** It integrates with the `NotifProvider` to send notifications (e.g., to Slack, MS Teams, Grafana) about the presence and count of unused metadata, making it suitable for automated monitoring in CI/CD pipelines.\n</details>\n",
       "examples": [
         "$ sf hardis:lint:unusedmetadatas"
       ],
@@ -1415,7 +1415,7 @@
     "hardis:mdapi:deploy": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**A wrapper command for Salesforce CLI's `sf project deploy start` (formerly `sfdx force:mdapi:deploy`), designed to assist with deployment error resolution.**\n\nThis command facilitates the deployment of metadata API source (either from a zip file, a deployment directory, or a validated deploy request ID) to a Salesforce org. Its primary enhancement over the standard Salesforce CLI command is its ability to provide tips and guidance for solving common deployment errors.\n\nKey features:\n\n- **Flexible Input:** Supports deploying from a `.zip` file (`--zipfile`), a local directory (`--deploydir`), or by referencing a previously validated deployment (`--validateddeployrequestid`).\n- **Test Level Control:** Allows specifying the test level for deployments (`NoTestRun`, `RunSpecifiedTests`, `RunLocalTestsInOrg`, `RunAllTestsInOrg`).\n- **Error Handling Assistance:** Displays helpful tips and links to documentation to guide you through resolving deployment failures.\n\n**Important Note:** The underlying Salesforce CLI command `sfdx force:mdapi:deploy` is being deprecated by Salesforce in November 2024. It is recommended to migrate to `sf project deploy start` for future compatibility. See [Salesforce CLI Migration Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_mig_deploy_retrieve.htm) for more information.\n\nFor visual assistance with solving deployment errors, refer to this article:\n\n[![Assisted solving of Salesforce deployments errors](https://github.com/hardisgroupcom/sfdx-hardis/raw/main/docs/assets/images/article-deployment-errors.jpg)](https://nicolas.vuillamy.fr/assisted-solving-of-salesforce-deployments-errors-47f3666a9ed0)\n\n## Technical explanations\n\nThis command acts as an intelligent wrapper around the Salesforce CLI's metadata deployment functionality:\n\n- **Command Wrapping:** It uses the `wrapSfdxCoreCommand` utility to execute the `sfdx force:mdapi:deploy` (or its equivalent `sf project deploy start`) command, passing through all relevant flags and arguments.\n- **Error Analysis (Implicit):** While the direct code snippet doesn't show explicit error analysis, the description implies that the `wrapSfdxCoreCommand` or a subsequent process intercepts deployment failures and provides contextual help.\n- **User Guidance:** It logs messages to the console, including deprecation warnings and pointers to external documentation for troubleshooting.\n- **Argument Passthrough:** It directly passes the command-line arguments (`this.argv`) to the underlying Salesforce CLI command, ensuring all standard deployment options are supported.\n",
+      "description": "\n## Command Behavior\n\n**A wrapper command for Salesforce CLI's `sf project deploy start` (formerly `sfdx force:mdapi:deploy`), designed to assist with deployment error resolution.**\n\nThis command facilitates the deployment of metadata API source (either from a zip file, a deployment directory, or a validated deploy request ID) to a Salesforce org. Its primary enhancement over the standard Salesforce CLI command is its ability to provide tips and guidance for solving common deployment errors.\n\nKey features:\n\n- **Flexible Input:** Supports deploying from a `.zip` file (`--zipfile`), a local directory (`--deploydir`), or by referencing a previously validated deployment (`--validateddeployrequestid`).\n- **Test Level Control:** Allows specifying the test level for deployments (`NoTestRun`, `RunSpecifiedTests`, `RunLocalTestsInOrg`, `RunAllTestsInOrg`).\n- **Error Handling Assistance:** Displays helpful tips and links to documentation to guide you through resolving deployment failures.\n\n**Important Note:** The underlying Salesforce CLI command `sfdx force:mdapi:deploy` is being deprecated by Salesforce in November 2024. It is recommended to migrate to `sf project deploy start` for future compatibility. See [Salesforce CLI Migration Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_mig_deploy_retrieve.htm) for more information.\n\nFor visual assistance with solving deployment errors, refer to this article:\n\n[![Assisted solving of Salesforce deployments errors](https://github.com/hardisgroupcom/sfdx-hardis/raw/main/docs/assets/images/article-deployment-errors.jpg)](https://nicolas.vuillamy.fr/assisted-solving-of-salesforce-deployments-errors-47f3666a9ed0)\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThis command acts as an intelligent wrapper around the Salesforce CLI's metadata deployment functionality:\n\n- **Command Wrapping:** It uses the `wrapSfdxCoreCommand` utility to execute the `sfdx force:mdapi:deploy` (or its equivalent `sf project deploy start`) command, passing through all relevant flags and arguments.\n- **Error Analysis (Implicit):** While the direct code snippet doesn't show explicit error analysis, the description implies that the `wrapSfdxCoreCommand` or a subsequent process intercepts deployment failures and provides contextual help.\n- **User Guidance:** It logs messages to the console, including deprecation warnings and pointers to external documentation for troubleshooting.\n- **Argument Passthrough:** It directly passes the command-line arguments (`this.argv`) to the underlying Salesforce CLI command, ensuring all standard deployment options are supported.\n</details>\n",
       "examples": [],
       "flags": {
         "json": {
@@ -1606,7 +1606,7 @@
     "hardis:misc:custom-label-translations": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Extracts selected custom labels, or all custom labels used within a given Lightning Web Component (LWC), from all available language translation files in the project.**\n\nThis command streamlines the process of managing and isolating specific custom label translations. It's particularly useful for:\n\n- **Localization Management:** Focusing on translations for a subset of labels or for labels relevant to a specific UI component.\n- **Collaboration:** Sharing only the necessary translation files with translators, reducing complexity.\n- **Debugging:** Isolating translation issues for specific labels or components.\n\nKey functionalities:\n\n- **Label Selection:** You can specify custom label names directly using the `--label` flag (comma-separated).\n- **LWC-based Extraction:** Alternatively, you can provide an LWC developer name using the `--lwc` flag, and the command will automatically identify and extract all custom labels referenced within that LWC's JavaScript files.\n- **Interactive Prompts:** If neither `--label` nor `--lwc` is provided, the command will interactively prompt you to choose between selecting specific labels or extracting from an LWC.\n- **Output Generation:** For each language found in your project's `translations` folder, it generates a new `.translation-meta.xml` file containing only the extracted custom labels and their translations. These files are placed in a timestamped output directory.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **File Discovery:** It uses `glob` to find all `*.translation-meta.xml` files in the `**/translations/` directory and, if an LWC is specified, it searches for the LWC's JavaScript files (`**/lwc/**/*.js`).\n- **LWC Label Extraction:** The `extractLabelsFromLwc` function uses regular expressions (`@salesforce/label/c.([a-zA-Z0-9_]+)`) to parse LWC JavaScript files and identify referenced custom labels.\n- **XML Parsing and Building:** It uses `xml2js` (`parseStringPromise` and `Builder`) to:\n  - Read and parse existing `.translation-meta.xml` files.\n  - Filter the `customLabels` array to include only the requested labels.\n  - Construct a new XML structure containing only the filtered labels.\n  - Build a new XML string with proper formatting and write it to a new file.\n- **Interactive Prompts:** The `prompts` library is used extensively to guide the user through the selection of extraction methods (labels or LWC) and specific labels/components.\n- **File System Operations:** It uses `fs-extra` for creating output directories (`extracted-translations/`) and writing the generated translation files.\n- **WebSocket Communication:** It uses `WebSocketClient.requestOpenFile` to open the output directory in VS Code for easy access to the generated files.\n",
+      "description": "\n## Command Behavior\n\n**Extracts selected custom labels, or all custom labels used within a given Lightning Web Component (LWC), from all available language translation files in the project.**\n\nThis command streamlines the process of managing and isolating specific custom label translations. It's particularly useful for:\n\n- **Localization Management:** Focusing on translations for a subset of labels or for labels relevant to a specific UI component.\n- **Collaboration:** Sharing only the necessary translation files with translators, reducing complexity.\n- **Debugging:** Isolating translation issues for specific labels or components.\n\nKey functionalities:\n\n- **Label Selection:** You can specify custom label names directly using the `--label` flag (comma-separated).\n- **LWC-based Extraction:** Alternatively, you can provide an LWC developer name using the `--lwc` flag, and the command will automatically identify and extract all custom labels referenced within that LWC's JavaScript files.\n- **Interactive Prompts:** If neither `--label` nor `--lwc` is provided, the command will interactively prompt you to choose between selecting specific labels or extracting from an LWC.\n- **Output Generation:** For each language found in your project's `translations` folder, it generates a new `.translation-meta.xml` file containing only the extracted custom labels and their translations. These files are placed in a timestamped output directory.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **File Discovery:** It uses `glob` to find all `*.translation-meta.xml` files in the `**/translations/` directory and, if an LWC is specified, it searches for the LWC's JavaScript files (`**/lwc/**/*.js`).\n- **LWC Label Extraction:** The `extractLabelsFromLwc` function uses regular expressions (`@salesforce/label/c.([a-zA-Z0-9_]+)`) to parse LWC JavaScript files and identify referenced custom labels.\n- **XML Parsing and Building:** It uses `xml2js` (`parseStringPromise` and `Builder`) to:\n  - Read and parse existing `.translation-meta.xml` files.\n  - Filter the `customLabels` array to include only the requested labels.\n  - Construct a new XML structure containing only the filtered labels.\n  - Build a new XML string with proper formatting and write it to a new file.\n- **Interactive Prompts:** The `prompts` library is used extensively to guide the user through the selection of extraction methods (labels or LWC) and specific labels/components.\n- **File System Operations:** It uses `fs-extra` for creating output directories (`extracted-translations/`) and writing the generated translation files.\n- **WebSocket Communication:** It uses `WebSocketClient.requestOpenFile` to open the output directory in VS Code for easy access to the generated files.\n</details>\n",
       "examples": [
         "$ sf hardis:misc:custom-label-translations --label CustomLabelName",
         "$ sf hardis:misc:custom-label-translations --label Label1,Label2",
@@ -1696,7 +1696,7 @@
     "hardis:misc:purge-references": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Purges references to specified strings within your Salesforce metadata files before deployment.**\n\nThis command is a powerful, yet dangerous, tool designed to modify your local Salesforce metadata by removing or altering references to specific strings. It's primarily intended for advanced use cases, such as refactoring a custom field's API name (e.g., changing a Master-Detail relationship to a Lookup) where direct string replacement across many files is necessary.\n\n**USE WITH EXTREME CAUTION AND CAREFULLY READ ALL MESSAGES!** Incorrect usage can lead to data loss or metadata corruption.\n\nKey functionalities:\n\n- **Reference String Input:** You can provide a comma-separated list of strings (e.g., `Affaire__c,MyField__c`) that you want to find and modify within your metadata.\n- **Automatic Related Field Inclusion:** If a custom field API name (ending with `__c`) is provided, it automatically includes its relationship name (ending with `__r`) in the list of references to purge, ensuring comprehensive cleanup.\n- **Source Synchronization Check:** Prompts you to confirm if your local sources are up-to-date with the target org, offering to retrieve metadata if needed.\n- **Targeted File Scan:** Scans `.cls`, `.trigger`, and `.xml` files within your SFDX project to identify occurrences of the specified reference strings.\n- **Configurable Replacements:** Applies predefined replacement rules based on file type (e.g., Apex classes, XML files) to modify the content where references are found.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Interactive Input:** Uses `prompts` to get the list of reference strings from the user if not provided via flags.\n- **Metadata Retrieval:** If the user indicates that local sources are not up-to-date, it executes `sf project retrieve start` to fetch the latest metadata from the target org.\n- **File System Scan:** It uses `glob` to efficiently find all relevant source files (`.cls`, `.trigger`, `.xml`) within the project's package directories.\n- **Content Matching:** Reads the content of each source file and checks for the presence of any of the specified reference strings.\n\nThe core utility function for replacements is called `applyAllReplacementsDefinitions`. It is responsible for iterating through the identified files and applying the defined replacement rules. These rules are structured to target specific patterns (for example, `,{{REF}},` or `{{REF}}[ |=].+` in Apex code) and replace them with a desired string (often an empty string or a modified version).\n\n- **Regular Expressions:** The replacement rules heavily rely on regular expressions (`regex`) to precisely match and modify the content.\n- **User Feedback:** Provides real-time feedback using `ora` for spinners and `uxLog` for logging messages about the progress and results of the operation.\n",
+      "description": "\n## Command Behavior\n\n**Purges references to specified strings within your Salesforce metadata files before deployment.**\n\nThis command is a powerful, yet dangerous, tool designed to modify your local Salesforce metadata by removing or altering references to specific strings. It's primarily intended for advanced use cases, such as refactoring a custom field's API name (e.g., changing a Master-Detail relationship to a Lookup) where direct string replacement across many files is necessary.\n\n**USE WITH EXTREME CAUTION AND CAREFULLY READ ALL MESSAGES!** Incorrect usage can lead to data loss or metadata corruption.\n\nKey functionalities:\n\n- **Reference String Input:** You can provide a comma-separated list of strings (e.g., `Affaire__c,MyField__c`) that you want to find and modify within your metadata.\n- **Automatic Related Field Inclusion:** If a custom field API name (ending with `__c`) is provided, it automatically includes its relationship name (ending with `__r`) in the list of references to purge, ensuring comprehensive cleanup.\n- **Source Synchronization Check:** Prompts you to confirm if your local sources are up-to-date with the target org, offering to retrieve metadata if needed.\n- **Targeted File Scan:** Scans `.cls`, `.trigger`, and `.xml` files within your SFDX project to identify occurrences of the specified reference strings.\n- **Configurable Replacements:** Applies predefined replacement rules based on file type (e.g., Apex classes, XML files) to modify the content where references are found.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Interactive Input:** Uses `prompts` to get the list of reference strings from the user if not provided via flags.\n- **Metadata Retrieval:** If the user indicates that local sources are not up-to-date, it executes `sf project retrieve start` to fetch the latest metadata from the target org.\n- **File System Scan:** It uses `glob` to efficiently find all relevant source files (`.cls`, `.trigger`, `.xml`) within the project's package directories.\n- **Content Matching:** Reads the content of each source file and checks for the presence of any of the specified reference strings.\n\nThe core utility function for replacements is called `applyAllReplacementsDefinitions`. It is responsible for iterating through the identified files and applying the defined replacement rules. These rules are structured to target specific patterns (for example, `,{{REF}},` or `{{REF}}[ |=].+` in Apex code) and replace them with a desired string (often an empty string or a modified version).\n\n- **Regular Expressions:** The replacement rules heavily rely on regular expressions (`regex`) to precisely match and modify the content.\n- **User Feedback:** Provides real-time feedback using `ora` for spinners and `uxLog` for logging messages about the progress and results of the operation.\n</details>\n",
       "examples": [
         "$ sf hardis:misc:purge-references"
       ],
@@ -1902,7 +1902,7 @@
     "hardis:misc:toml2csv": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Splits a TOML (Tom's Obvious, Minimal Language) file into multiple CSV files, applying transformations and filters based on a JSON configuration.**\n\nThis command is designed for data processing workflows where data is initially stored in a TOML-like format and needs to be converted into structured CSV files for import into Salesforce or other systems. It offers powerful capabilities for data manipulation and cleansing during the conversion process.\n\nKey functionalities:\n\n- **TOML Parsing:** Reads an input TOML file, identifying sections (e.g., `[COMPTES]`) and processing data lines within each section.\n- **Configurable Transformations:** Applies transformations to individual data fields based on a JSON configuration file (`transfoConfig.json`). This can include:\n  - **Date Formatting:** Reformatting date strings to a desired output format.\n  - **Enum Transcoding:** Mapping input values to predefined output values using lookup tables (enums).\n  - **Concatenation:** Combining multiple input fields into a single output field.\n  - **Record Type ID Resolution:** Dynamically retrieving Salesforce Record Type IDs.\n- **Data Filtering:** Filters data lines based on specified criteria (e.g., date ranges, parent ID existence, column values), allowing you to exclude irrelevant data from the output.\n- **Duplicate Removal:** Optionally removes duplicate lines from the output CSV files.\n- **Error Handling and Reporting:** Catches transformation errors, logs them, and can output problematic lines to separate error CSV files for review.\n- **CSV Output:** Generates one or more CSV files, with configurable separators and headers, ready for Salesforce Data Loader or other import tools.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **File I/O:** Uses `fs-extra` for file system operations (reading TOML, writing CSVs, creating directories) and `readline` for efficient line-by-line processing of large TOML files.\n- **Configuration Loading:** Reads and parses the `transfoConfig.json` file, which defines the mapping rules, transformations, and filters. It also loads external enum files if specified in the configuration.\n- **Data Processing Pipeline:** Iterates through each line of the TOML file:\n  - Identifies section headers to determine the current data context.\n  - Parses data lines based on the input separator.\n  - Applies filters defined in `transfoConfig` to decide whether to process or skip a line.\n  - Performs data transformations (date formatting, enum lookups, concatenations) as specified in the `transfoConfig`.\n  - Resolves Salesforce Record Type IDs by querying the target org using `getRecordTypeId`.\n  - Formats the output CSV cells, handling special characters and separators.\n  - Writes the transformed data to the appropriate CSV output stream.\n- **Error Management:** Catches exceptions during transformation and logs detailed error messages, including the problematic line and the reason for the error.\n- **Progress Indication:** Uses `ora` for a command-line spinner to provide visual feedback on the processing progress.\n- **Statistics Collection:** Tracks various statistics, such as the number of processed lines, successful lines, error lines, and filtered lines, providing a summary at the end.\n- **File Copying:** Optionally copies generated CSV files to other specified locations.\n",
+      "description": "\n## Command Behavior\n\n**Splits a TOML (Tom's Obvious, Minimal Language) file into multiple CSV files, applying transformations and filters based on a JSON configuration.**\n\nThis command is designed for data processing workflows where data is initially stored in a TOML-like format and needs to be converted into structured CSV files for import into Salesforce or other systems. It offers powerful capabilities for data manipulation and cleansing during the conversion process.\n\nKey functionalities:\n\n- **TOML Parsing:** Reads an input TOML file, identifying sections (e.g., `[COMPTES]`) and processing data lines within each section.\n- **Configurable Transformations:** Applies transformations to individual data fields based on a JSON configuration file (`transfoConfig.json`). This can include:\n  - **Date Formatting:** Reformatting date strings to a desired output format.\n  - **Enum Transcoding:** Mapping input values to predefined output values using lookup tables (enums).\n  - **Concatenation:** Combining multiple input fields into a single output field.\n  - **Record Type ID Resolution:** Dynamically retrieving Salesforce Record Type IDs.\n- **Data Filtering:** Filters data lines based on specified criteria (e.g., date ranges, parent ID existence, column values), allowing you to exclude irrelevant data from the output.\n- **Duplicate Removal:** Optionally removes duplicate lines from the output CSV files.\n- **Error Handling and Reporting:** Catches transformation errors, logs them, and can output problematic lines to separate error CSV files for review.\n- **CSV Output:** Generates one or more CSV files, with configurable separators and headers, ready for Salesforce Data Loader or other import tools.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **File I/O:** Uses `fs-extra` for file system operations (reading TOML, writing CSVs, creating directories) and `readline` for efficient line-by-line processing of large TOML files.\n- **Configuration Loading:** Reads and parses the `transfoConfig.json` file, which defines the mapping rules, transformations, and filters. It also loads external enum files if specified in the configuration.\n- **Data Processing Pipeline:** Iterates through each line of the TOML file:\n  - Identifies section headers to determine the current data context.\n  - Parses data lines based on the input separator.\n  - Applies filters defined in `transfoConfig` to decide whether to process or skip a line.\n  - Performs data transformations (date formatting, enum lookups, concatenations) as specified in the `transfoConfig`.\n  - Resolves Salesforce Record Type IDs by querying the target org using `getRecordTypeId`.\n  - Formats the output CSV cells, handling special characters and separators.\n  - Writes the transformed data to the appropriate CSV output stream.\n- **Error Management:** Catches exceptions during transformation and logs detailed error messages, including the problematic line and the reason for the error.\n- **Progress Indication:** Uses `ora` for a command-line spinner to provide visual feedback on the processing progress.\n- **Statistics Collection:** Tracks various statistics, such as the number of processed lines, successful lines, error lines, and filtered lines, providing a summary at the end.\n- **File Copying:** Optionally copies generated CSV files to other specified locations.\n</details>\n",
       "examples": [
         "$ sf hardis:misc:toml2csv --tomlfile 'D:/clients/toto/V1_full.txt' ",
         "$ sf hardis:misc:toml2csv --skiptransfo --tomlfile 'D:/clients/toto/V1_full.txt' ",
@@ -2033,7 +2033,7 @@
     "hardis:org:connect": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Connects to a Salesforce org without setting it as the default username, and optionally opens the org in a web browser.**\n\nThis command provides a quick way to establish a connection to a Salesforce organization for one-off tasks or when you don't want to change your default org. It's useful for accessing different environments without disrupting your primary development setup.\n\nKey functionalities:\n\n- **Org Selection:** Prompts the user to select an existing Salesforce org or connect to a new one.\n- **Non-Default Connection:** Ensures that the selected org is connected but does not set it as the default username for subsequent Salesforce CLI commands.\n- **Browser Launch (Optional):** Offers to open the connected org directly in your default web browser, providing immediate access to the Salesforce UI.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Interactive Org Prompt:** Uses the `promptOrg` utility to display a list of available Salesforce orgs and allows the user to select one or initiate a new authentication flow.\n- **Salesforce CLI Integration:** Internally, it leverages Salesforce CLI commands to establish the connection to the chosen org. It does not use `sf config set target-org` to avoid changing the default org.\n- **Browser Launch:** If the user opts to open the org in a browser, it executes the `sf org open` command, passing the selected org's username as the target.\n- **Environment Awareness:** Checks the `isCI` flag to determine whether to offer the browser launch option, as it's typically not applicable in continuous integration environments.\n",
+      "description": "\n## Command Behavior\n\n**Connects to a Salesforce org without setting it as the default username, and optionally opens the org in a web browser.**\n\nThis command provides a quick way to establish a connection to a Salesforce organization for one-off tasks or when you don't want to change your default org. It's useful for accessing different environments without disrupting your primary development setup.\n\nKey functionalities:\n\n- **Org Selection:** Prompts the user to select an existing Salesforce org or connect to a new one.\n- **Non-Default Connection:** Ensures that the selected org is connected but does not set it as the default username for subsequent Salesforce CLI commands.\n- **Browser Launch (Optional):** Offers to open the connected org directly in your default web browser, providing immediate access to the Salesforce UI.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Interactive Org Prompt:** Uses the `promptOrg` utility to display a list of available Salesforce orgs and allows the user to select one or initiate a new authentication flow.\n- **Salesforce CLI Integration:** Internally, it leverages Salesforce CLI commands to establish the connection to the chosen org. It does not use `sf config set target-org` to avoid changing the default org.\n- **Browser Launch:** If the user opts to open the org in a browser, it executes the `sf org open` command, passing the selected org's username as the target.\n- **Environment Awareness:** Checks the `isCI` flag to determine whether to offer the browser launch option, as it's typically not applicable in continuous integration environments.\n</details>\n",
       "examples": [
         "$ sf hardis:org:connect"
       ],
@@ -2105,7 +2105,7 @@
     "hardis:org:create": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Creates and initializes a Salesforce sandbox org.**\n\nThis command automates the process of provisioning a new sandbox environment, making it ready for development or testing. It handles various aspects of sandbox creation and initial setup, reducing manual effort and ensuring consistency.\n\nKey functionalities:\n\n- **Sandbox Definition:** Uses a `project-sandbox-def.json` file (if present in `config/`) to define sandbox properties like name, description, license type, and source sandbox. If not provided, it uses default values.\n- **Dynamic Naming:** Generates a unique sandbox alias based on the current username, Git branch, and a timestamp.\n- **Sandbox Creation:** Executes the Salesforce CLI command to create the sandbox, including setting it as the default org and waiting for its completion.\n- **User Update:** Updates the main sandbox user's details (e.g., Last Name, First Name) and can fix country values or marketing user permissions if needed.\n- **Initialization Scripts:** Runs predefined Apex scripts, assigns permission sets, and imports initial data into the newly created sandbox, based on configurations in your project.\n- **Error Handling:** Provides detailed error messages for common sandbox creation issues, including Salesforce-specific errors.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Configuration Loading:** It loads project and user configurations using `getConfig` to retrieve settings like `projectName`, `devHubAlias`, and `userEmail`.\n- **Git Integration:** Retrieves the current Git branch name using `getCurrentGitBranch` to inform sandbox naming.\n- **File System Operations:** Uses `fs-extra` to manage sandbox definition files (reading `project-sandbox-def.json`, writing a user-specific definition file) and temporary directories.\n- **Salesforce CLI Execution:** Executes Salesforce CLI commands (`sf org create sandbox`, `sf data get record`, `sf data update record`, `sf org open`) using `execSfdxJson` for sandbox creation, user updates, and opening the org in a browser.\n- **Cache Management:** Clears the Salesforce CLI org list cache (`clearCache('sf org list')`) to ensure the newly created sandbox is immediately recognized.\n- **Initialization Utilities:** Calls a suite of utility functions (`initPermissionSetAssignments`, `initApexScripts`, `initOrgData`) to perform post-creation setup tasks.\n- **Error Assertions:** Uses `assert` to check the success of Salesforce CLI commands and provides custom error messages for better debugging.\n- **WebSocket Communication:** Uses `WebSocketClient.sendRefreshStatusMessage` to notify connected VS Code clients about the new sandbox.\n- **Required Plugin Check:** Explicitly lists `sfdmu` as a required plugin, indicating its role in data initialization.\n",
+      "description": "\n## Command Behavior\n\n**Creates and initializes a Salesforce sandbox org.**\n\nThis command automates the process of provisioning a new sandbox environment, making it ready for development or testing. It handles various aspects of sandbox creation and initial setup, reducing manual effort and ensuring consistency.\n\nKey functionalities:\n\n- **Sandbox Definition:** Uses a `project-sandbox-def.json` file (if present in `config/`) to define sandbox properties like name, description, license type, and source sandbox. If not provided, it uses default values.\n- **Dynamic Naming:** Generates a unique sandbox alias based on the current username, Git branch, and a timestamp.\n- **Sandbox Creation:** Executes the Salesforce CLI command to create the sandbox, including setting it as the default org and waiting for its completion.\n- **User Update:** Updates the main sandbox user's details (e.g., Last Name, First Name) and can fix country values or marketing user permissions if needed.\n- **Initialization Scripts:** Runs predefined Apex scripts, assigns permission sets, and imports initial data into the newly created sandbox, based on configurations in your project.\n- **Error Handling:** Provides detailed error messages for common sandbox creation issues, including Salesforce-specific errors.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Configuration Loading:** It loads project and user configurations using `getConfig` to retrieve settings like `projectName`, `devHubAlias`, and `userEmail`.\n- **Git Integration:** Retrieves the current Git branch name using `getCurrentGitBranch` to inform sandbox naming.\n- **File System Operations:** Uses `fs-extra` to manage sandbox definition files (reading `project-sandbox-def.json`, writing a user-specific definition file) and temporary directories.\n- **Salesforce CLI Execution:** Executes Salesforce CLI commands (`sf org create sandbox`, `sf data get record`, `sf data update record`, `sf org open`) using `execSfdxJson` for sandbox creation, user updates, and opening the org in a browser.\n- **Cache Management:** Clears the Salesforce CLI org list cache (`clearCache('sf org list')`) to ensure the newly created sandbox is immediately recognized.\n- **Initialization Utilities:** Calls a suite of utility functions (`initPermissionSetAssignments`, `initApexScripts`, `initOrgData`) to perform post-creation setup tasks.\n- **Error Assertions:** Uses `assert` to check the success of Salesforce CLI commands and provides custom error messages for better debugging.\n- **WebSocket Communication:** Uses `WebSocketClient.sendRefreshStatusMessage` to notify connected VS Code clients about the new sandbox.\n- **Required Plugin Check:** Explicitly lists `sfdmu` as a required plugin, indicating its role in data initialization.\n</details>\n",
       "examples": [
         "$ sf hardis:org:create"
       ],
@@ -2181,7 +2181,7 @@
     "hardis:org:multi-org-query": {
       "aliases": [],
       "args": {},
-      "description": "\n**Executes a SOQL query across multiple Salesforce organizations and consolidates the results into a single report.**\n\nThis command is highly valuable for administrators and developers who need to gather consistent data from various Salesforce environments (e.g., sandboxes, production orgs) for reporting, auditing, or comparison purposes. It streamlines the process of querying multiple orgs, eliminating the need to log into each one individually.\n\nKey functionalities:\n\n- **Flexible Query Input:** You can provide a custom SOQL query directly using the `--query` flag, or select from a list of predefined query templates (e.g., `active-users`, `all-users`) using the `--query-template` flag.\n- **Multiple Org Targeting:** Specify a list of Salesforce org usernames or aliases using the `--target-orgs` flag. If not provided, an interactive menu will allow you to select multiple authenticated orgs.\n- **Consolidated Report:** All query results from the different orgs are combined into a single CSV file, making data analysis and comparison straightforward.\n- **Authentication Handling:** For CI/CD jobs, ensure that the target orgs are already authenticated using Salesforce CLI. In interactive mode, it will prompt for authentication if an org is not connected.\n\n**Visual Demo:**\n\n[![Use in VsCode SFDX Hardis !](https://github.com/hardisgroupcom/sfdx-hardis/raw/main/docs/assets/images/multi-org-query-demo.gif)](https://marketplace.visualstudio.com/items?itemName=NicolasVuillamy.vscode-sfdx-hardis)\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Org Authentication and Connection:** It uses `AuthInfo.create` and `Connection.create` to establish connections to each target Salesforce org. It also leverages `makeSureOrgIsConnected` and `promptOrgList` for interactive org selection and authentication checks.\n- **SOQL Query Execution (Bulk API):** It executes the specified SOQL query against each connected org using `bulkQuery` for efficient data retrieval, especially for large datasets.\n- **Data Aggregation:** It collects the records from each org's query result and adds metadata about the source org (instance URL, alias, username) to each record, enabling easy identification of data origin in the consolidated report.\n- **Report Generation:** It uses `generateCsvFile` to create the final CSV report and `generateReportPath` to determine the output file location.\n- **Interactive Prompts:** The `prompts` library is used to guide the user through selecting a query template or entering a custom query, and for selecting target orgs if not provided as command-line arguments.\n- **Error Handling:** It logs errors for any orgs where the query fails, ensuring that the overall process continues and provides a clear summary of successes and failures.\n",
+      "description": "\n**Executes a SOQL query across multiple Salesforce organizations and consolidates the results into a single report.**\n\nThis command is highly valuable for administrators and developers who need to gather consistent data from various Salesforce environments (e.g., sandboxes, production orgs) for reporting, auditing, or comparison purposes. It streamlines the process of querying multiple orgs, eliminating the need to log into each one individually.\n\nKey functionalities:\n\n- **Flexible Query Input:** You can provide a custom SOQL query directly using the `--query` flag, or select from a list of predefined query templates (e.g., `active-users`, `all-users`) using the `--query-template` flag.\n- **Multiple Org Targeting:** Specify a list of Salesforce org usernames or aliases using the `--target-orgs` flag. If not provided, an interactive menu will allow you to select multiple authenticated orgs.\n- **Consolidated Report:** All query results from the different orgs are combined into a single CSV file, making data analysis and comparison straightforward.\n- **Authentication Handling:** For CI/CD jobs, ensure that the target orgs are already authenticated using Salesforce CLI. In interactive mode, it will prompt for authentication if an org is not connected.\n\n**Visual Demo:**\n\n[![Use in VsCode SFDX Hardis !](https://github.com/hardisgroupcom/sfdx-hardis/raw/main/docs/assets/images/multi-org-query-demo.gif)](https://marketplace.visualstudio.com/items?itemName=NicolasVuillamy.vscode-sfdx-hardis)\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Org Authentication and Connection:** It uses `AuthInfo.create` and `Connection.create` to establish connections to each target Salesforce org. It also leverages `makeSureOrgIsConnected` and `promptOrgList` for interactive org selection and authentication checks.\n- **SOQL Query Execution (Bulk API):** It executes the specified SOQL query against each connected org using `bulkQuery` for efficient data retrieval, especially for large datasets.\n- **Data Aggregation:** It collects the records from each org's query result and adds metadata about the source org (instance URL, alias, username) to each record, enabling easy identification of data origin in the consolidated report.\n- **Report Generation:** It uses `generateCsvFile` to create the final CSV report and `generateReportPath` to determine the output file location.\n- **Interactive Prompts:** The `prompts` library is used to guide the user through selecting a query template or entering a custom query, and for selecting target orgs if not provided as command-line arguments.\n- **Error Handling:** It logs errors for any orgs where the query fails, ensuring that the overall process continues and provides a clear summary of successes and failures.\n</details>\n",
       "examples": [
         "$ sf hardis:org:multi-org-query",
         "$ sf hardis:org:multi-org-query --query \"SELECT Id,Username FROM User\"",
@@ -2297,7 +2297,7 @@
     "hardis:org:select": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Allows you to select a Salesforce org and set it as your default, optionally filtering by Dev Hub or scratch orgs.**\n\nThis command simplifies switching between different Salesforce environments. It presents an interactive list of your authenticated orgs, enabling you to quickly set a new default org for subsequent Salesforce CLI commands.\n\nKey functionalities:\n\n- **Interactive Org Selection:** Displays a list of your authenticated Salesforce orgs, allowing you to choose one.\n- **Default Org Setting:** Sets the selected org as the default for your Salesforce CLI environment.\n- **Dev Hub Filtering:** The `--devhub` flag filters the list to show only Dev Hub orgs.\n- **Scratch Org Filtering:** The `--scratch` flag filters the list to show only scratch orgs related to your default Dev Hub.\n- **Connection Verification:** Ensures that the selected org is connected and prompts for re-authentication if necessary.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Interactive Org Prompt:** Uses the `promptOrg` utility to display a list of available Salesforce orgs and allows the user to select one. It passes the `devHub` and `scratch` flags to `promptOrg` to filter the displayed list.\n- **Default Org Configuration:** The `promptOrg` utility (internally) handles setting the selected org as the default using Salesforce CLI's configuration mechanisms.\n- **Connection Check:** It calls `makeSureOrgIsConnected` to verify the connection status of the selected org and guides the user to re-authenticate if the org is not connected.\n- **Salesforce CLI Integration:** It leverages Salesforce CLI's underlying commands for org listing and authentication.\n",
+      "description": "\n## Command Behavior\n\n**Allows you to select a Salesforce org and set it as your default, optionally filtering by Dev Hub or scratch orgs.**\n\nThis command simplifies switching between different Salesforce environments. It presents an interactive list of your authenticated orgs, enabling you to quickly set a new default org for subsequent Salesforce CLI commands.\n\nKey functionalities:\n\n- **Interactive Org Selection:** Displays a list of your authenticated Salesforce orgs, allowing you to choose one.\n- **Default Org Setting:** Sets the selected org as the default for your Salesforce CLI environment.\n- **Dev Hub Filtering:** The `--devhub` flag filters the list to show only Dev Hub orgs.\n- **Scratch Org Filtering:** The `--scratch` flag filters the list to show only scratch orgs related to your default Dev Hub.\n- **Connection Verification:** Ensures that the selected org is connected and prompts for re-authentication if necessary.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Interactive Org Prompt:** Uses the `promptOrg` utility to display a list of available Salesforce orgs and allows the user to select one. It passes the `devHub` and `scratch` flags to `promptOrg` to filter the displayed list.\n- **Default Org Configuration:** The `promptOrg` utility (internally) handles setting the selected org as the default using Salesforce CLI's configuration mechanisms.\n- **Connection Check:** It calls `makeSureOrgIsConnected` to verify the connection status of the selected org and guides the user to re-authenticate if the org is not connected.\n- **Salesforce CLI Integration:** It leverages Salesforce CLI's underlying commands for org listing and authentication.\n</details>\n",
       "examples": [
         "$ sf hardis:org:select"
       ],
@@ -2383,7 +2383,7 @@
     "hardis:package:create": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Creates a new Salesforce package (either Managed or Unlocked) in your Dev Hub.**\n\nThis command streamlines the process of setting up a new Salesforce package, which is a fundamental step for modularizing your Salesforce metadata and enabling continuous integration and delivery practices. It guides you through defining the package's essential properties.\n\nKey functionalities:\n\n- **Interactive Package Definition:** Prompts you for the package name, the path to its source code, and the package type (Managed or Unlocked).\n- **Package Type Selection:**\n  - **Managed Packages:** Ideal for AppExchange solutions, where code is hidden in subscriber orgs.\n  - **Unlocked Packages:** Suitable for client projects or shared tooling, where code is readable and modifiable in subscriber orgs.\n- **Package Creation:** Executes the Salesforce CLI command to create the package in your connected Dev Hub.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Interactive Prompts:** Uses the `prompts` library to gather necessary information from the user, such as `packageName`, `packagePath`, and `packageType`.\n- **Salesforce CLI Integration:** It constructs and executes the `sf package create` command, passing the user-provided details as arguments.\n- **`execSfdxJson`:** This utility is used to execute the Salesforce CLI command and capture its JSON output, which includes the newly created package's ID.\n- **User Feedback:** Provides clear messages to the user about the successful creation of the package, including its ID and the associated Dev Hub.\n",
+      "description": "\n## Command Behavior\n\n**Creates a new Salesforce package (either Managed or Unlocked) in your Dev Hub.**\n\nThis command streamlines the process of setting up a new Salesforce package, which is a fundamental step for modularizing your Salesforce metadata and enabling continuous integration and delivery practices. It guides you through defining the package's essential properties.\n\nKey functionalities:\n\n- **Interactive Package Definition:** Prompts you for the package name, the path to its source code, and the package type (Managed or Unlocked).\n- **Package Type Selection:**\n  - **Managed Packages:** Ideal for AppExchange solutions, where code is hidden in subscriber orgs.\n  - **Unlocked Packages:** Suitable for client projects or shared tooling, where code is readable and modifiable in subscriber orgs.\n- **Package Creation:** Executes the Salesforce CLI command to create the package in your connected Dev Hub.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Interactive Prompts:** Uses the `prompts` library to gather necessary information from the user, such as `packageName`, `packagePath`, and `packageType`.\n- **Salesforce CLI Integration:** It constructs and executes the `sf package create` command, passing the user-provided details as arguments.\n- **`execSfdxJson`:** This utility is used to execute the Salesforce CLI command and capture its JSON output, which includes the newly created package's ID.\n- **User Feedback:** Provides clear messages to the user about the successful creation of the package, including its ID and the associated Dev Hub.\n</details>\n",
       "examples": [
         "$ sf hardis:package:create"
       ],
@@ -2572,7 +2572,7 @@
     "hardis:package:mergexml": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Merges multiple Salesforce `package.xml` files into a single, consolidated `package.xml` file.**\n\nThis command is useful for combining metadata definitions from various sources (e.g., different feature branches, separate development efforts) into one comprehensive package.xml, which can then be used for deployments or retrievals.\n\nKey functionalities:\n\n- **Flexible Input:** You can specify the `package.xml` files to merge either by:\n  - Providing a comma-separated list of file paths using the `--packagexmls` flag.\n  - Specifying a folder and a glob pattern using `--folder` and `--pattern` to automatically discover `package.xml` files.\n  - If no input is provided, an interactive menu will prompt you to select files from the `manifest` folder.\n- **Customizable Output:** You can define the name and path of the resulting merged `package.xml` file using the `--result` flag.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **File Discovery:** It uses `glob` to find `package.xml` files based on the provided folder and pattern, or it directly uses the list of files from the `--packagexmls` flag.\n- **Interactive Prompts:** If no `package.xml` files are specified, it uses the `prompts` library to allow the user to interactively select files to merge.\n- **`appendPackageXmlFilesContent` Utility:** The core merging logic is handled by the `appendPackageXmlFilesContent` utility function. This function reads the content of each input `package.xml` file, combines their metadata types and members, and writes the consolidated content to the specified result file.\n- **XML Manipulation:** Internally, `appendPackageXmlFilesContent` parses the XML of each `package.xml`, merges the `<types>` and `<members>` elements, and then rebuilds the XML structure for the output file.\n- **File System Operations:** It uses `fs-extra` to ensure the output directory exists and to write the merged `package.xml` file.\n- **WebSocket Communication:** It uses `WebSocketClient.requestOpenFile` to open the generated merged `package.xml` file in VS Code for immediate review.\n",
+      "description": "\n## Command Behavior\n\n**Merges multiple Salesforce `package.xml` files into a single, consolidated `package.xml` file.**\n\nThis command is useful for combining metadata definitions from various sources (e.g., different feature branches, separate development efforts) into one comprehensive package.xml, which can then be used for deployments or retrievals.\n\nKey functionalities:\n\n- **Flexible Input:** You can specify the `package.xml` files to merge either by:\n  - Providing a comma-separated list of file paths using the `--packagexmls` flag.\n  - Specifying a folder and a glob pattern using `--folder` and `--pattern` to automatically discover `package.xml` files.\n  - If no input is provided, an interactive menu will prompt you to select files from the `manifest` folder.\n- **Customizable Output:** You can define the name and path of the resulting merged `package.xml` file using the `--result` flag.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **File Discovery:** It uses `glob` to find `package.xml` files based on the provided folder and pattern, or it directly uses the list of files from the `--packagexmls` flag.\n- **Interactive Prompts:** If no `package.xml` files are specified, it uses the `prompts` library to allow the user to interactively select files to merge.\n- **`appendPackageXmlFilesContent` Utility:** The core merging logic is handled by the `appendPackageXmlFilesContent` utility function. This function reads the content of each input `package.xml` file, combines their metadata types and members, and writes the consolidated content to the specified result file.\n- **XML Manipulation:** Internally, `appendPackageXmlFilesContent` parses the XML of each `package.xml`, merges the `<types>` and `<members>` elements, and then rebuilds the XML structure for the output file.\n- **File System Operations:** It uses `fs-extra` to ensure the output directory exists and to write the merged `package.xml` file.\n- **WebSocket Communication:** It uses `WebSocketClient.requestOpenFile` to open the generated merged `package.xml` file in VS Code for immediate review.\n</details>\n",
       "examples": [
         "$ sf hardis:package:mergexml",
         "$ sf hardis:package:mergexml --folder packages --pattern /**/*.xml --result myMergedPackage.xml",
@@ -2679,7 +2679,7 @@
     "hardis:packagexml:append": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Appends the content of one or more Salesforce `package.xml` files into a single target `package.xml` file.**\n\nThis command is useful for consolidating metadata definitions from various sources into a single manifest. For instance, you might have separate `package.xml` files for different features or metadata types, and this command allows you to combine them into one comprehensive file for deployment or retrieval.\n\nKey functionalities:\n\n- **Multiple Input Files:** Takes a comma-separated list of `package.xml` file paths as input.\n- **Single Output File:** Merges the content of all input files into a specified output `package.xml` file.\n- **Metadata Consolidation:** Combines the `<types>` and `<members>` elements from all input files, ensuring that all unique metadata components are included in the resulting file.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **File Parsing:** It reads and parses the XML content of each input `package.xml` file.\n- **Content Merging:** It iterates through the parsed XML structures, merging the `types` and `members` arrays. If a metadata type exists in multiple input files, its members are combined (duplicates are typically handled by the underlying XML utility).\n- **XML Building:** After consolidating the metadata, it rebuilds the XML structure for the output `package.xml` file.\n- **File Writing:** The newly constructed XML content is then written to the specified output file.\n- **`appendPackageXmlFilesContent` Utility:** The core logic for this operation is encapsulated within the `appendPackageXmlFilesContent` utility function, which handles the parsing, merging, and writing of the `package.xml` files.\n",
+      "description": "\n## Command Behavior\n\n**Appends the content of one or more Salesforce `package.xml` files into a single target `package.xml` file.**\n\nThis command is useful for consolidating metadata definitions from various sources into a single manifest. For instance, you might have separate `package.xml` files for different features or metadata types, and this command allows you to combine them into one comprehensive file for deployment or retrieval.\n\nKey functionalities:\n\n- **Multiple Input Files:** Takes a comma-separated list of `package.xml` file paths as input.\n- **Single Output File:** Merges the content of all input files into a specified output `package.xml` file.\n- **Metadata Consolidation:** Combines the `<types>` and `<members>` elements from all input files, ensuring that all unique metadata components are included in the resulting file.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **File Parsing:** It reads and parses the XML content of each input `package.xml` file.\n- **Content Merging:** It iterates through the parsed XML structures, merging the `types` and `members` arrays. If a metadata type exists in multiple input files, its members are combined (duplicates are typically handled by the underlying XML utility).\n- **XML Building:** After consolidating the metadata, it rebuilds the XML structure for the output `package.xml` file.\n- **File Writing:** The newly constructed XML content is then written to the specified output file.\n- **`appendPackageXmlFilesContent` Utility:** The core logic for this operation is encapsulated within the `appendPackageXmlFilesContent` utility function, which handles the parsing, merging, and writing of the `package.xml` files.\n</details>\n",
       "examples": [
         "$ sf hardis packagexml append -p package1.xml,package2.xml -o package3.xml"
       ],
@@ -2760,7 +2760,7 @@
     "hardis:packagexml:remove": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Removes metadata components from a `package.xml` file that are also present in another `package.xml` file (e.g., a `destructiveChanges.xml`).**\n\nThis command is useful for refining your `package.xml` manifests by excluding components that are being deleted or are otherwise irrelevant for a specific deployment or retrieval. For example, you can use it to create a `package.xml` that only contains additions and modifications, by removing items listed in a `destructiveChanges.xml`.\n\nKey functionalities:\n\n- **Source `package.xml`:** The main `package.xml` file from which components will be removed (specified by `--packagexml`). Defaults to `package.xml`.\n- **Filter `package.xml`:** The `package.xml` file containing the components to be removed from the source (specified by `--removepackagexml`). Defaults to `destructiveChanges.xml`.\n- **Output File:** The path to the new `package.xml` file that will contain the filtered content (specified by `--outputfile`).\n- **Removed Only Output:** The `--removedonly` flag allows you to generate a `package.xml` that contains *only* the items that were removed from the source `package.xml`.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **File Parsing:** It reads and parses the XML content of both the source `package.xml` and the filter `package.xml`.\n- **Content Comparison and Filtering:** It compares the metadata types and members defined in both files. Components found in the filter `package.xml` are excluded from the output.\n- **XML Building:** After filtering, it rebuilds the XML structure for the new `package.xml` file.\n- **File Writing:** The newly constructed XML content is then written to the specified output file.\n- **`removePackageXmlFilesContent` Utility:** The core logic for this operation is encapsulated within the `removePackageXmlFilesContent` utility function, which handles the parsing, filtering, and writing of the `package.xml` files.\n",
+      "description": "\n## Command Behavior\n\n**Removes metadata components from a `package.xml` file that are also present in another `package.xml` file (e.g., a `destructiveChanges.xml`).**\n\nThis command is useful for refining your `package.xml` manifests by excluding components that are being deleted or are otherwise irrelevant for a specific deployment or retrieval. For example, you can use it to create a `package.xml` that only contains additions and modifications, by removing items listed in a `destructiveChanges.xml`.\n\nKey functionalities:\n\n- **Source `package.xml`:** The main `package.xml` file from which components will be removed (specified by `--packagexml`). Defaults to `package.xml`.\n- **Filter `package.xml`:** The `package.xml` file containing the components to be removed from the source (specified by `--removepackagexml`). Defaults to `destructiveChanges.xml`.\n- **Output File:** The path to the new `package.xml` file that will contain the filtered content (specified by `--outputfile`).\n- **Removed Only Output:** The `--removedonly` flag allows you to generate a `package.xml` that contains *only* the items that were removed from the source `package.xml`.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **File Parsing:** It reads and parses the XML content of both the source `package.xml` and the filter `package.xml`.\n- **Content Comparison and Filtering:** It compares the metadata types and members defined in both files. Components found in the filter `package.xml` are excluded from the output.\n- **XML Building:** After filtering, it rebuilds the XML structure for the new `package.xml` file.\n- **File Writing:** The newly constructed XML content is then written to the specified output file.\n- **`removePackageXmlFilesContent` Utility:** The core logic for this operation is encapsulated within the `removePackageXmlFilesContent` utility function, which handles the parsing, filtering, and writing of the `package.xml` files.\n</details>\n",
       "examples": [
         "$ sf hardis packagexml:remove -p package.xml -r destructiveChanges.xml -o my-reduced-package.xml"
       ],
@@ -2928,7 +2928,7 @@
     "hardis:project:lint": {
       "aliases": [],
       "args": {},
-      "description": "## Command Behavior\n\n**Applies syntactic analysis (linting) to your repository sources using Mega-Linter, ensuring code quality and adherence to coding standards.**\n\nThis command integrates Mega-Linter, a comprehensive linter orchestrator, into your Salesforce DX project. It helps identify and fix code style violations, potential bugs, and other issues across various file types relevant to Salesforce development.\n\nKey functionalities:\n\n- **Automated Linting:** Runs a suite of linters configured for Salesforce projects.\n- **Fixing Issues (`--fix` flag):** Automatically attempts to fix detected linting issues, saving manual effort.\n- **Configuration Management:** If `.mega-linter.yml` is not found, it guides you through the initial setup of Mega-Linter, prompting for the Salesforce flavor.\n- **CI/CD Integration:** Designed to be used in CI/CD pipelines to enforce code quality gates.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Mega-Linter Integration:** It leverages the `mega-linter-runner` library to execute Mega-Linter.\n- **Configuration Check:** Before running, it checks for the presence of `.mega-linter.yml`. If not found and not in a CI environment, it initiates an interactive setup process using `MegaLinterRunner().run({ install: true })`.\n- **Linter Execution:** It calls `MegaLinterRunner().run(megaLinterOptions)` with the `salesforce` flavor and the `fix` flag (if provided).\n- **Exit Code Handling:** The `process.exitCode` is set based on the Mega-Linter's exit status, allowing CI/CD pipelines to react to linting failures.\n- **User Feedback:** Provides clear messages about the success or failure of the linting process.\n",
+      "description": "## Command Behavior\n\n**Applies syntactic analysis (linting) to your repository sources using Mega-Linter, ensuring code quality and adherence to coding standards.**\n\nThis command integrates Mega-Linter, a comprehensive linter orchestrator, into your Salesforce DX project. It helps identify and fix code style violations, potential bugs, and other issues across various file types relevant to Salesforce development.\n\nKey functionalities:\n\n- **Automated Linting:** Runs a suite of linters configured for Salesforce projects.\n- **Fixing Issues (`--fix` flag):** Automatically attempts to fix detected linting issues, saving manual effort.\n- **Configuration Management:** If `.mega-linter.yml` is not found, it guides you through the initial setup of Mega-Linter, prompting for the Salesforce flavor.\n- **CI/CD Integration:** Designed to be used in CI/CD pipelines to enforce code quality gates.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Mega-Linter Integration:** It leverages the `mega-linter-runner` library to execute Mega-Linter.\n- **Configuration Check:** Before running, it checks for the presence of `.mega-linter.yml`. If not found and not in a CI environment, it initiates an interactive setup process using `MegaLinterRunner().run({ install: true })`.\n- **Linter Execution:** It calls `MegaLinterRunner().run(megaLinterOptions)` with the `salesforce` flavor and the `fix` flag (if provided).\n- **Exit Code Handling:** The `process.exitCode` is set based on the Mega-Linter's exit status, allowing CI/CD pipelines to react to linting failures.\n- **User Feedback:** Provides clear messages about the success or failure of the linting process.\n</details>\n",
       "examples": [
         "$ sf hardis:project:lint",
         "$ sf hardis:project:lint --fix"
@@ -3125,7 +3125,7 @@
     "hardis:scratch:delete": {
       "aliases": [],
       "args": {},
-      "description": "## Command Behavior\n\n**Provides an assisted menu to delete Salesforce scratch orgs associated with a Dev Hub.**\n\nThis command simplifies the process of cleaning up your Salesforce development environments by allowing you to easily select and delete multiple scratch orgs. This is crucial for managing your scratch org limits and ensuring that you don't accumulate unnecessary or expired orgs.\n\nKey functionalities:\n\n- **Interactive Scratch Org Selection:** Displays a list of all active scratch orgs linked to your Dev Hub, including their usernames, instance URLs, and last used dates.\n- **Multi-Selection:** Allows you to select multiple scratch orgs for deletion.\n- **Confirmation Prompt:** Prompts for confirmation before proceeding with the deletion, ensuring that you don't accidentally delete important orgs.\n- **Dev Hub Integration:** Works with your configured Dev Hub to manage scratch orgs.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Salesforce CLI Integration:** It executes the `sf org list` command to retrieve a list of all scratch orgs associated with the current Dev Hub. It then filters this list to show only active orgs.\n- **Interactive Prompts:** Uses the `prompts` library to present a multi-select menu of scratch orgs to the user.\n- **Scratch Org Deletion:** For each selected scratch org, it executes the `sf org delete scratch --no-prompt` command to perform the deletion.\n- **Error Handling:** Includes basic error handling for Salesforce CLI commands.\n- **Data Sorting:** Sorts the list of scratch orgs by username, alias, and instance URL for better readability in the interactive menu.\n",
+      "description": "## Command Behavior\n\n**Provides an assisted menu to delete Salesforce scratch orgs associated with a Dev Hub.**\n\nThis command simplifies the process of cleaning up your Salesforce development environments by allowing you to easily select and delete multiple scratch orgs. This is crucial for managing your scratch org limits and ensuring that you don't accumulate unnecessary or expired orgs.\n\nKey functionalities:\n\n- **Interactive Scratch Org Selection:** Displays a list of all active scratch orgs linked to your Dev Hub, including their usernames, instance URLs, and last used dates.\n- **Multi-Selection:** Allows you to select multiple scratch orgs for deletion.\n- **Confirmation Prompt:** Prompts for confirmation before proceeding with the deletion, ensuring that you don't accidentally delete important orgs.\n- **Dev Hub Integration:** Works with your configured Dev Hub to manage scratch orgs.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Salesforce CLI Integration:** It executes the `sf org list` command to retrieve a list of all scratch orgs associated with the current Dev Hub. It then filters this list to show only active orgs.\n- **Interactive Prompts:** Uses the `prompts` library to present a multi-select menu of scratch orgs to the user.\n- **Scratch Org Deletion:** For each selected scratch org, it executes the `sf org delete scratch --no-prompt` command to perform the deletion.\n- **Error Handling:** Includes basic error handling for Salesforce CLI commands.\n- **Data Sorting:** Sorts the list of scratch orgs by username, alias, and instance URL for better readability in the interactive menu.\n</details>\n",
       "examples": [
         "$ sf hardis:scratch:delete"
       ],
@@ -3210,7 +3210,7 @@
     "hardis:scratch:pull": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Pulls metadata changes from your scratch org or source-tracked sandbox into your local project files.**\n\nThis command is essential for synchronizing your local development environment with the changes you've made directly in your Salesforce org. After pulling, you can then stage and commit the relevant files to your version control system.\n\nKey features and considerations:\n\n- **Underlying Command:** Internally, this command executes `sf project retrieve start` to fetch the metadata.\n- **Error Handling:** If the pull operation encounters errors, it offers to automatically add the problematic items to your `.forceignore` file and then attempts to pull again, helping you resolve conflicts and ignore unwanted metadata.\n- **Missing Updates:** If you don't see certain updated items in the pull results, you might need to manually retrieve them using the Salesforce Extension's **Org Browser** or the **Salesforce CLI** directly. Refer to the [Retrieve Metadatas documentation](https://sfdx-hardis.cloudity.com/salesforce-ci-cd-publish-task/#retrieve-metadatas) for more details.\n- **Automatic Retrieval:** You can configure the `autoRetrieveWhenPull` property in your `.sfdx-hardis.yml` file to always retrieve specific metadata types (e.g., `CustomApplication`) that might not always be detected as updates by `project:retrieve:start`.\n\nExample `.sfdx-hardis.yml` configuration for `autoRetrieveWhenPull`:\n```yaml\nautoRetrieveWhenPull:\n  - CustomApplication:MyCustomApplication\n  - CustomApplication:MyOtherCustomApplication\n  - CustomApplication:MyThirdCustomApp\n```\n\nFor a visual explanation of the process, watch this video:\n\n<iframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/Ik6whtflmfY\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen></iframe>\n\n## Technical explanations\n\nThe command's technical implementation focuses on robust metadata synchronization:\n\n- **Salesforce CLI Wrapper:** It acts as a wrapper around the standard Salesforce CLI `sf project retrieve start` command, providing enhanced error handling and configuration options.\n- **Force Source Pull Utility:** The core logic resides in the `forceSourcePull` utility function, which orchestrates the retrieval process, including handling `.forceignore` updates.\n- **Configuration Integration:** It reads the `autoRetrieveWhenPull` setting from the project's `.sfdx-hardis.yml` to determine additional metadata to retrieve automatically.\n- **User Feedback:** Provides clear messages to the user regarding the pull status and guidance for troubleshooting.\n",
+      "description": "\n## Command Behavior\n\n**Pulls metadata changes from your scratch org or source-tracked sandbox into your local project files.**\n\nThis command is essential for synchronizing your local development environment with the changes you've made directly in your Salesforce org. After pulling, you can then stage and commit the relevant files to your version control system.\n\nKey features and considerations:\n\n- **Underlying Command:** Internally, this command executes `sf project retrieve start` to fetch the metadata.\n- **Error Handling:** If the pull operation encounters errors, it offers to automatically add the problematic items to your `.forceignore` file and then attempts to pull again, helping you resolve conflicts and ignore unwanted metadata.\n- **Missing Updates:** If you don't see certain updated items in the pull results, you might need to manually retrieve them using the Salesforce Extension's **Org Browser** or the **Salesforce CLI** directly. Refer to the [Retrieve Metadatas documentation](https://sfdx-hardis.cloudity.com/salesforce-ci-cd-publish-task/#retrieve-metadatas) for more details.\n- **Automatic Retrieval:** You can configure the `autoRetrieveWhenPull` property in your `.sfdx-hardis.yml` file to always retrieve specific metadata types (e.g., `CustomApplication`) that might not always be detected as updates by `project:retrieve:start`.\n\nExample `.sfdx-hardis.yml` configuration for `autoRetrieveWhenPull`:\n```yaml\nautoRetrieveWhenPull:\n  - CustomApplication:MyCustomApplication\n  - CustomApplication:MyOtherCustomApplication\n  - CustomApplication:MyThirdCustomApp\n```\n\nFor a visual explanation of the process, watch this video:\n\n<iframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/Ik6whtflmfY\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen></iframe>\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation focuses on robust metadata synchronization:\n\n- **Salesforce CLI Wrapper:** It acts as a wrapper around the standard Salesforce CLI `sf project retrieve start` command, providing enhanced error handling and configuration options.\n- **Force Source Pull Utility:** The core logic resides in the `forceSourcePull` utility function, which orchestrates the retrieval process, including handling `.forceignore` updates.\n- **Configuration Integration:** It reads the `autoRetrieveWhenPull` setting from the project's `.sfdx-hardis.yml` to determine additional metadata to retrieve automatically.\n- **User Feedback:** Provides clear messages to the user regarding the pull status and guidance for troubleshooting.\n</details>\n",
       "examples": [
         "$ sf hardis:scratch:pull"
       ],
@@ -3297,7 +3297,7 @@
     "hardis:scratch:push": {
       "aliases": [],
       "args": {},
-      "description": "## Command Behavior\n\n**Pushes local Salesforce DX source files to a scratch org or source-tracked sandbox.**\n\nThis command is a fundamental operation in Salesforce DX development, allowing developers to synchronize their local codebase with their development org. It ensures that changes made locally are reflected in the scratch org, enabling testing and validation.\n\nKey functionalities:\n\n- **Source Synchronization:** Deploys all local changes (metadata and code) to the target scratch org.\n- **Underlying Command:** Internally, this command executes `sf project deploy start` to perform the push operation.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Salesforce CLI Wrapper:** It acts as a wrapper around the standard Salesforce CLI `sf project deploy start` command.\n- **`forceSourcePush` Utility:** The core logic resides in the `forceSourcePush` utility function, which orchestrates the deployment process.\n- **Connection Handling:** It uses the connection to the target org to perform the push operation.\n",
+      "description": "## Command Behavior\n\n**Pushes local Salesforce DX source files to a scratch org or source-tracked sandbox.**\n\nThis command is a fundamental operation in Salesforce DX development, allowing developers to synchronize their local codebase with their development org. It ensures that changes made locally are reflected in the scratch org, enabling testing and validation.\n\nKey functionalities:\n\n- **Source Synchronization:** Deploys all local changes (metadata and code) to the target scratch org.\n- **Underlying Command:** Internally, this command executes `sf project deploy start` to perform the push operation.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Salesforce CLI Wrapper:** It acts as a wrapper around the standard Salesforce CLI `sf project deploy start` command.\n- **`forceSourcePush` Utility:** The core logic resides in the `forceSourcePush` utility function, which orchestrates the deployment process.\n- **Connection Handling:** It uses the connection to the target org to perform the push operation.\n</details>\n",
       "examples": [
         "$ sf hardis:scratch:push"
       ],
@@ -3754,7 +3754,7 @@
     "hardis:source:retrieve": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**A wrapper command for Salesforce CLI's `sf project retrieve start` (formerly `sfdx force:source:retrieve`), with enhanced interactive features.**\n\nThis command facilitates the retrieval of metadata from a Salesforce org into your local project. It provides an assisted experience, especially when no specific retrieval constraints are provided.\n\nKey features:\n\n- **Assisted Metadata Selection:** If no `sourcepath`, `manifest`, `metadata`, or `packagenames` flags are specified, an interactive menu will prompt you to select the metadata types you wish to retrieve.\n- **Assisted Org Selection:** If no target org is specified, an interactive menu will guide you to choose an org for the retrieval operation.\n- **Backward Compatibility:** While this command wraps the newer `sf project retrieve start`, it maintains compatibility with the older `sfdx force:source:retrieve` flags.\n\n**Important Note:** The underlying Salesforce CLI command `sfdx force:source:retrieve` is being deprecated by Salesforce in November 2024. It is recommended to migrate to `sf project retrieve start` for future compatibility. See [Salesforce CLI Migration Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_mig_deploy_retrieve.htm) for more information.\n\n## Technical explanations\n\nThis command acts as an intelligent wrapper around the Salesforce CLI's source retrieval functionality:\n\n- **Command Wrapping:** It uses the `wrapSfdxCoreCommand` utility to execute the `sfdx force:source:retrieve` (or its equivalent `sf project retrieve start`) command, passing through all relevant flags and arguments.\n- **Interactive Prompts:** It leverages `MetadataUtils.promptMetadataTypes()` and `promptOrgUsernameDefault()` to provide interactive menus for metadata and org selection when the user does not provide them as flags.\n- **Argument Transformation:** It dynamically constructs the command-line arguments for the underlying Salesforce CLI command based on user selections and provided flags.\n- **Error Handling:** It includes basic error handling, such as prompting the user to re-select an org if an issue occurs during org selection.\n- **Deprecation Warning:** It explicitly logs warnings about the deprecation of `sfdx force:source:retrieve` to inform users about upcoming changes.\n",
+      "description": "\n## Command Behavior\n\n**A wrapper command for Salesforce CLI's `sf project retrieve start` (formerly `sfdx force:source:retrieve`), with enhanced interactive features.**\n\nThis command facilitates the retrieval of metadata from a Salesforce org into your local project. It provides an assisted experience, especially when no specific retrieval constraints are provided.\n\nKey features:\n\n- **Assisted Metadata Selection:** If no `sourcepath`, `manifest`, `metadata`, or `packagenames` flags are specified, an interactive menu will prompt you to select the metadata types you wish to retrieve.\n- **Assisted Org Selection:** If no target org is specified, an interactive menu will guide you to choose an org for the retrieval operation.\n- **Backward Compatibility:** While this command wraps the newer `sf project retrieve start`, it maintains compatibility with the older `sfdx force:source:retrieve` flags.\n\n**Important Note:** The underlying Salesforce CLI command `sfdx force:source:retrieve` is being deprecated by Salesforce in November 2024. It is recommended to migrate to `sf project retrieve start` for future compatibility. See [Salesforce CLI Migration Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_mig_deploy_retrieve.htm) for more information.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThis command acts as an intelligent wrapper around the Salesforce CLI's source retrieval functionality:\n\n- **Command Wrapping:** It uses the `wrapSfdxCoreCommand` utility to execute the `sfdx force:source:retrieve` (or its equivalent `sf project retrieve start`) command, passing through all relevant flags and arguments.\n- **Interactive Prompts:** It leverages `MetadataUtils.promptMetadataTypes()` and `promptOrgUsernameDefault()` to provide interactive menus for metadata and org selection when the user does not provide them as flags.\n- **Argument Transformation:** It dynamically constructs the command-line arguments for the underlying Salesforce CLI command based on user selections and provided flags.\n- **Error Handling:** It includes basic error handling, such as prompting the user to re-select an org if an issue occurs during org selection.\n- **Deprecation Warning:** It explicitly logs warnings about the deprecation of `sfdx force:source:retrieve` to inform users about upcoming changes.\n</details>\n",
       "examples": [],
       "flags": {
         "json": {
@@ -3921,7 +3921,7 @@
     "hardis:work:new": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Assisted menu to start working on a Salesforce User Story, streamlining the setup of your development environment.**\n\nThis command guides you through the process of preparing your local environment and a Salesforce org for a new development or configuration based User Story. It automates several steps, ensuring consistency and adherence to project standards.\n\nKey features include:\n\n- **Git Branch Management:** Ensures your local Git repository is up-to-date with the target branch and creates a new Git branch with a formatted name based on your User Story details. Branch naming conventions can be customized via the `branchPrefixChoices` property in `.sfdx-hardis.yml`.\n- **Org Provisioning & Initialization:** Facilitates the creation and initialization of either a scratch org or a source-tracked sandbox. The configuration for org initialization (e.g., package installation, source push, permission set assignments, Apex script execution, data loading) can be defined in `config/.sfdx-hardis.yml- **Project-Specific Configuration:** Supports defining multiple target branches (`availableTargetBranches`) and projects (`availableProjects`) in `.sfdx-hardis.yml`, allowing for tailored User Stories workflows.\n- **User Story Name Validation:** Enforces User Story name formatting using `newTaskNameRegex` and provides examples via `newTaskNameRegexExample- **Shared Development Sandboxes:** Accounts for scenarios with shared development sandboxes, adjusting prompts to prevent accidental overwrites.\n\nAdvanced instructions are available in the [Create New User Story documentation](https://sfdx-hardis.cloudity.com/salesforce-ci-cd-create-new-task/).\n\n## Technical explanations\n\nThe command's logic orchestrates various underlying processes:\n\n- **Git Operations:** Utilizes `checkGitClean`, `ensureGitBranch`, `gitCheckOutRemote`, and `git().pull()` to manage Git repository state and branches.\n- **Interactive Prompts:** Leverages the `prompts` library to gather user input for User Story type, source types, and User Story names.\n- **Configuration Management:** Reads and applies project-specific configurations from `.sfdx-hardis.yml` using `getConfig` and `setConfig- **Org Initialization Utilities:** Calls a suite of utility functions for org setup, including `initApexScripts`, `initOrgData`, `initOrgMetadatas`, `initPermissionSetAssignments`, `installPackages`, and `makeSureOrgIsConnected- **Salesforce CLI Interaction:** Executes Salesforce CLI commands (e.g., `sf config set target-org`, `sf org open`, `sf project delete tracking`) via `execCommand` and `execSfdxJson- **Dynamic Org Selection:** Presents choices for scratch orgs or sandboxes based on project configuration and existing orgs, dynamically calling `ScratchCreate.run` or `SandboxCreate.run` as needed.\n- **WebSocket Communication:** Sends refresh status messages via `WebSocketClient.sendRefreshStatusMessage()` to update connected VS Code clients.\n",
+      "description": "\n## Command Behavior\n\n**Assisted menu to start working on a Salesforce User Story, streamlining the setup of your development environment.**\n\nThis command guides you through the process of preparing your local environment and a Salesforce org for a new development or configuration based User Story. It automates several steps, ensuring consistency and adherence to project standards.\n\nKey features include:\n\n- **Git Branch Management:** Ensures your local Git repository is up-to-date with the target branch and creates a new Git branch with a formatted name based on your User Story details. Branch naming conventions can be customized via the `branchPrefixChoices` property in `.sfdx-hardis.yml`.\n\n- **Org Provisioning & Initialization:** Facilitates the creation and initialization of either a scratch org or a source-tracked sandbox. The configuration for org initialization (e.g., package installation, source push, permission set assignments, Apex script execution, data loading) can be defined in `config/.sfdx-hardis.yml\n- **Project-Specific Configuration:** Supports defining multiple target branches (`availableTargetBranches`) and projects (`availableProjects`) in `.sfdx-hardis.yml`, allowing for tailored User Stories workflows.\n\n- **User Story Name Validation:** Enforces User Story name formatting using `newTaskNameRegex` and provides examples via `newTaskNameRegexExample\n- **Shared Development Sandboxes:** Accounts for scenarios with shared development sandboxes, adjusting prompts to prevent accidental overwrites.\n\nAdvanced instructions are available in the [Create New User Story documentation](https://sfdx-hardis.cloudity.com/salesforce-ci-cd-create-new-task/).\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's logic orchestrates various underlying processes:\n\n- **Git Operations:** Utilizes `checkGitClean`, `ensureGitBranch`, `gitCheckOutRemote`, and `git().pull()` to manage Git repository state and branches.\n- **Interactive Prompts:** Leverages the `prompts` library to gather user input for User Story type, source types, and User Story names.\n- **Configuration Management:** Reads and applies project-specific configurations from `.sfdx-hardis.yml` using `getConfig` and `setConfig- **Org Initialization Utilities:** Calls a suite of utility functions for org setup, including `initApexScripts`, `initOrgData`, `initOrgMetadatas`, `initPermissionSetAssignments`, `installPackages`, and `makeSureOrgIsConnected- **Salesforce CLI Interaction:** Executes Salesforce CLI commands (e.g., `sf config set target-org`, `sf org open`, `sf project delete tracking`) via `execCommand` and `execSfdxJson- **Dynamic Org Selection:** Presents choices for scratch orgs or sandboxes based on project configuration and existing orgs, dynamically calling `ScratchCreate.run` or `SandboxCreate.run` as needed.\n- **WebSocket Communication:** Sends refresh status messages via `WebSocketClient.sendRefreshStatusMessage()` to update connected VS Code clients.\n</details>\n",
       "examples": [
         "$ sf hardis:work:new"
       ],
@@ -4021,7 +4021,7 @@
     "hardis:work:refresh": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Refreshes your local Git branch and Salesforce org with the latest content from another Git branch.**\n\nThis command is designed to help developers keep their local development environment synchronized with changes made by other team members. It automates the process of pulling updates from a designated branch, merging them into your current working branch, and then pushing those changes to your scratch org or source-tracked sandbox.\n\nKey functionalities:\n\n- **Pre-Merge Check:** Prompts the user to confirm that they have saved their current work before proceeding with the merge, preventing accidental data loss.\n- **Branch Selection:** Allows you to select a target Git branch (e.g., `integration`, `preprod`) from which to pull updates.\n- **Git Operations:** Performs a series of Git operations:\n  - Pulls the latest version of the selected merge branch.\n  - Stashes your uncommitted local changes before merging.\n  - Merges the selected branch into your current local branch.\n  - Handles merge conflicts interactively, prompting the user to resolve them.\n  - Restores your stashed changes after the merge.\n- **Org Synchronization:** Pushes the updated local branch content to your scratch org or source-tracked sandbox, ensuring your org reflects the latest merged code.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Configuration Loading:** It retrieves project configurations using `getConfig` to determine the default development branch.\n- **Git Integration:** Extensively uses `simple-git` (`git()`) for various Git operations:\n  - `git().branch()`: Lists local and remote branches.\n  - `git().stash()`: Saves and restores uncommitted changes.\n  - `git().fetch()`: Fetches updates from remote repositories.\n  - `git().checkout()`: Switches between branches.\n  - `git().pull()`: Pulls changes from a remote branch.\n  - `git().merge()`: Merges one branch into another, handling conflicts.\n- **Interactive Prompts:** Uses the `prompts` library to guide the user through confirmations (e.g., saving work) and branch selection.\n- **Salesforce CLI Integration:** It uses `forceSourcePull` to pull changes from the scratch org and `forceSourcePush` to push changes to the scratch org.\n- **Error Handling:** Includes robust error handling for Git operations (e.g., merge conflicts) and provides guidance to the user for resolution.\n- **Environment Variable Check:** Checks for an `EXPERIMENTAL` environment variable to gate access to this command, indicating it might not be fully stable.\n",
+      "description": "\n## Command Behavior\n\n**Refreshes your local Git branch and Salesforce org with the latest content from another Git branch.**\n\nThis command is designed to help developers keep their local development environment synchronized with changes made by other team members. It automates the process of pulling updates from a designated branch, merging them into your current working branch, and then pushing those changes to your scratch org or source-tracked sandbox.\n\nKey functionalities:\n\n- **Pre-Merge Check:** Prompts the user to confirm that they have saved their current work before proceeding with the merge, preventing accidental data loss.\n- **Branch Selection:** Allows you to select a target Git branch (e.g., `integration`, `preprod`) from which to pull updates.\n- **Git Operations:** Performs a series of Git operations:\n  - Pulls the latest version of the selected merge branch.\n  - Stashes your uncommitted local changes before merging.\n  - Merges the selected branch into your current local branch.\n  - Handles merge conflicts interactively, prompting the user to resolve them.\n  - Restores your stashed changes after the merge.\n- **Org Synchronization:** Pushes the updated local branch content to your scratch org or source-tracked sandbox, ensuring your org reflects the latest merged code.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Configuration Loading:** It retrieves project configurations using `getConfig` to determine the default development branch.\n- **Git Integration:** Extensively uses `simple-git` (`git()`) for various Git operations:\n  - `git().branch()`: Lists local and remote branches.\n  - `git().stash()`: Saves and restores uncommitted changes.\n  - `git().fetch()`: Fetches updates from remote repositories.\n  - `git().checkout()`: Switches between branches.\n  - `git().pull()`: Pulls changes from a remote branch.\n  - `git().merge()`: Merges one branch into another, handling conflicts.\n- **Interactive Prompts:** Uses the `prompts` library to guide the user through confirmations (e.g., saving work) and branch selection.\n- **Salesforce CLI Integration:** It uses `forceSourcePull` to pull changes from the scratch org and `forceSourcePush` to push changes to the scratch org.\n- **Error Handling:** Includes robust error handling for Git operations (e.g., merge conflicts) and provides guidance to the user for resolution.\n- **Environment Variable Check:** Checks for an `EXPERIMENTAL` environment variable to gate access to this command, indicating it might not be fully stable.\n</details>\n",
       "examples": [
         "$ sf hardis:work:refresh"
       ],
@@ -4115,7 +4115,7 @@
     "hardis:work:resetselection": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Resets the local Git repository to allow for a new selection of files to be included in a merge request.**\n\nThis command is designed to be used when you need to re-evaluate which changes should be part of your next merge request. It performs a soft Git reset, effectively unstaging all committed changes since the last merge with the target branch, and then cleans up any generated files.\n\nKey functionalities:\n\n- **Target Branch Selection:** Prompts you to select the target branch of your current or future merge request.\n- **Soft Git Reset:** Performs a `git reset --soft` operation to uncommit changes, moving the HEAD pointer back but keeping the changes in your working directory.\n- **Generated File Cleanup:** Resets and checks out `manifest/package.xml` and `manifest/destructiveChanges.xml` to their state before the reset, ensuring a clean slate for new selections.\n- **Force Push Authorization:** Sets a flag in your user configuration (`canForcePush: true`) to allow a force push in the subsequent `hardis:work:save` command, as the history will have been rewritten.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Git Integration:** Uses `simple-git` (`git()`) to interact with the Git repository:\n  - `git().branch()`: Retrieves information about local and remote branches.\n  - `git().log()`: Fetches the commit history to determine which commits to reset.\n  - `git().reset()`: Performs the soft reset operation.\n  - `git().checkout()`: Resets specific files (`package.xml`, `destructiveChanges.xml`) to their previous state.\n  - `git().status()`: Displays the current status of the Git repository after the reset.\n- **Interactive Prompts:** Uses the `prompts` library to confirm the reset operation with the user and to select the target branch.\n- **Configuration Management:** Updates the user's configuration (`.sfdx-hardis.yml`) using `setConfig` to set the `canForcePush` flag.\n- **Error Handling:** Includes a check to prevent resetting protected branches.\n",
+      "description": "\n## Command Behavior\n\n**Resets the local Git repository to allow for a new selection of files to be included in a merge request.**\n\nThis command is designed to be used when you need to re-evaluate which changes should be part of your next merge request. It performs a soft Git reset, effectively unstaging all committed changes since the last merge with the target branch, and then cleans up any generated files.\n\nKey functionalities:\n\n- **Target Branch Selection:** Prompts you to select the target branch of your current or future merge request.\n- **Soft Git Reset:** Performs a `git reset --soft` operation to uncommit changes, moving the HEAD pointer back but keeping the changes in your working directory.\n- **Generated File Cleanup:** Resets and checks out `manifest/package.xml` and `manifest/destructiveChanges.xml` to their state before the reset, ensuring a clean slate for new selections.\n- **Force Push Authorization:** Sets a flag in your user configuration (`canForcePush: true`) to allow a force push in the subsequent `hardis:work:save` command, as the history will have been rewritten.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Git Integration:** Uses `simple-git` (`git()`) to interact with the Git repository:\n  - `git().branch()`: Retrieves information about local and remote branches.\n  - `git().log()`: Fetches the commit history to determine which commits to reset.\n  - `git().reset()`: Performs the soft reset operation.\n  - `git().checkout()`: Resets specific files (`package.xml`, `destructiveChanges.xml`) to their previous state.\n  - `git().status()`: Displays the current status of the Git repository after the reset.\n- **Interactive Prompts:** Uses the `prompts` library to confirm the reset operation with the user and to select the target branch.\n- **Configuration Management:** Updates the user's configuration (`.sfdx-hardis.yml`) using `setConfig` to set the `canForcePush` flag.\n- **Error Handling:** Includes a check to prevent resetting protected branches.\n</details>\n",
       "examples": [
         "$ sf hardis:work:resetsave"
       ],
@@ -4202,7 +4202,7 @@
     "hardis:work:save": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Guides the user through the process of saving their work, preparing it for a Merge Request (also named Pull Request), and pushing changes to the remote Git repository.**\n\nThis command automates several critical steps involved in finalizing a development User Story and integrating it into the main codebase. It ensures that your local changes are properly synchronized, cleaned, and committed before being pushed.\n\nKey functionalities include:\n\n- **Git Status Management:** Ensures a clean Git working directory by handling ongoing merges and unstaging files.\n- **Org Synchronization (Optional):** Prompts the user to pull the latest metadata updates from their scratch org or source-tracked sandbox, ensuring local files reflect the org's state.\n- **Package.xml Updates:** Automatically generates `package.xml` and `destructiveChanges.xml` files based on the Git delta between your current branch and the target branch, reflecting added, modified, and deleted metadata.\n- **Automated Source Cleaning:** Applies predefined cleaning operations to your local Salesforce sources, such as removing unwanted references, minimizing profiles, or cleaning XML files based on configurations in your `.sfdx-hardis.yml`.\n  - `autoCleanTypes`: A list of automated source cleanings, configurable via [hardis:project:clean:references](${CONSTANTS.DOC_URL_ROOT}/hardis/project/clean/references/).\n  - `autoRemoveUserPermissions`: A list of user permissions to automatically remove from profile metadata.\n- **Deployment Plan Generation:** Builds an automated deployment plan based on the updated `package.xml` and configured deployment splits.\n- **Commit and Push:** Guides the user to commit the changes and push them to the remote Git repository, optionally handling force pushes if a branch reset occurred.\n- **Merge Request Guidance:** Provides information and links to facilitate the creation of a merge request after the changes are pushed.\n\nExample `.sfdx-hardis.yml` configuration:\n\n```yaml\nautoCleanTypes:\n  - checkPermissions\n  - destructivechanges\n  - datadotcom\n  - minimizeProfiles\n  - listViewsMine\nautoRemoveUserPermissions:\n  - EnableCommunityAppLauncher\n  - FieldServiceAccess\n  - OmnichannelInventorySync\n  - SendExternalEmailAvailable\n  - UseOmnichannelInventoryAPIs\n  - ViewDataLeakageEvents\n  - ViewMLModels\n  - ViewPlatformEvents\n  - WorkCalibrationUser\n```\n\nAdvanced instructions are available in the [Publish a User Story documentation](${CONSTANTS.DOC_URL_ROOT}/salesforce-ci-cd-publish-task/).\n\n## Technical explanations\n\nThe command's technical implementation involves a series of orchestrated steps:\n\n- **Git Integration:** Extensively uses the `git` utility for status checks, adding files, committing, and pushing. It also leverages `sfdx-git-delta` for generating metadata differences between Git revisions.\n- **Interactive Prompts:** Employs the `prompts` library to interact with the user for decisions like pulling sources or pushing commits.\n- **Configuration Management:** Reads and updates project and user configurations using `getConfig` and `setConfig` to store preferences and deployment plans.\n- **Metadata Synchronization:** Calls `forceSourcePull` to retrieve metadata from the org and `callSfdxGitDelta` to generate `package.xml` and `destructiveChanges.xml` based on Git changes.\n- **XML Manipulation:** Utilizes `appendPackageXmlFilesContent`, `removePackageXmlFilesContent`, `parseXmlFile`, and `writeXmlFile` for modifying `package.xml` and `destructiveChanges.xml` files.\n- **Automated Cleaning:** Integrates with `CleanReferences.run` and `CleanXml.run` commands to perform automated cleaning operations on the Salesforce source files.\n- **Deployment Plan Building:** Dynamically constructs a deployment plan by analyzing the `package.xml` content and applying configured deployment splits.\n- **WebSocket Communication:** Uses `WebSocketClient.sendRefreshStatusMessage` to notify connected VS Code clients about status updates.\n- **External Tool Integration:** Requires the `sfdx-git-delta` plugin to be installed for its core functionality.\n",
+      "description": "\n## Command Behavior\n\n**Guides the user through the process of saving their work, preparing it for a Merge Request (also named Pull Request), and pushing changes to the remote Git repository.**\n\nThis command automates several critical steps involved in finalizing a development User Story and integrating it into the main codebase. It ensures that your local changes are properly synchronized, cleaned, and committed before being pushed.\n\nKey functionalities include:\n\n- **Git Status Management:** Ensures a clean Git working directory by handling ongoing merges and unstaging files.\n- **Org Synchronization (Optional):** Prompts the user to pull the latest metadata updates from their scratch org or source-tracked sandbox, ensuring local files reflect the org's state.\n- **Package.xml Updates:** Automatically generates `package.xml` and `destructiveChanges.xml` files based on the Git delta between your current branch and the target branch, reflecting added, modified, and deleted metadata.\n- **Automated Source Cleaning:** Applies predefined cleaning operations to your local Salesforce sources, such as removing unwanted references, minimizing profiles, or cleaning XML files based on configurations in your `.sfdx-hardis.yml`.\n  - `autoCleanTypes`: A list of automated source cleanings, configurable via [hardis:project:clean:references](${CONSTANTS.DOC_URL_ROOT}/hardis/project/clean/references/).\n  - `autoRemoveUserPermissions`: A list of user permissions to automatically remove from profile metadata.\n- **Deployment Plan Generation:** Builds an automated deployment plan based on the updated `package.xml` and configured deployment splits.\n- **Commit and Push:** Guides the user to commit the changes and push them to the remote Git repository, optionally handling force pushes if a branch reset occurred.\n- **Merge Request Guidance:** Provides information and links to facilitate the creation of a merge request after the changes are pushed.\n\nExample `.sfdx-hardis.yml` configuration:\n\n```yaml\nautoCleanTypes:\n  - checkPermissions\n  - destructivechanges\n  - datadotcom\n  - minimizeProfiles\n  - listViewsMine\nautoRemoveUserPermissions:\n  - EnableCommunityAppLauncher\n  - FieldServiceAccess\n  - OmnichannelInventorySync\n  - SendExternalEmailAvailable\n  - UseOmnichannelInventoryAPIs\n  - ViewDataLeakageEvents\n  - ViewMLModels\n  - ViewPlatformEvents\n  - WorkCalibrationUser\n```\n\nAdvanced instructions are available in the [Publish a User Story documentation](${CONSTANTS.DOC_URL_ROOT}/salesforce-ci-cd-publish-task/).\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves a series of orchestrated steps:\n\n- **Git Integration:** Extensively uses the `git` utility for status checks, adding files, committing, and pushing. It also leverages `sfdx-git-delta` for generating metadata differences between Git revisions.\n- **Interactive Prompts:** Employs the `prompts` library to interact with the user for decisions like pulling sources or pushing commits.\n- **Configuration Management:** Reads and updates project and user configurations using `getConfig` and `setConfig` to store preferences and deployment plans.\n- **Metadata Synchronization:** Calls `forceSourcePull` to retrieve metadata from the org and `callSfdxGitDelta` to generate `package.xml` and `destructiveChanges.xml` based on Git changes.\n- **XML Manipulation:** Utilizes `appendPackageXmlFilesContent`, `removePackageXmlFilesContent`, `parseXmlFile`, and `writeXmlFile` for modifying `package.xml` and `destructiveChanges.xml` files.\n- **Automated Cleaning:** Integrates with `CleanReferences.run` and `CleanXml.run` commands to perform automated cleaning operations on the Salesforce source files.\n- **Deployment Plan Building:** Dynamically constructs a deployment plan by analyzing the `package.xml` content and applying configured deployment splits.\n- **WebSocket Communication:** Uses `WebSocketClient.sendRefreshStatusMessage` to notify connected VS Code clients about status updates.\n- **External Tool Integration:** Requires the `sfdx-git-delta` plugin to be installed for its core functionality.\n</details>\n",
       "examples": [
         "$ sf hardis:work:task:save",
         "$ sf hardis:work:task:save --nopull --nogit --noclean"
@@ -4327,7 +4327,7 @@
     "hardis:work:ws": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Performs technical operations related to WebSocket communication, primarily for internal use by the sfdx-hardis VS Code Extension.**\n\nThis command is not intended for direct end-user interaction. It facilitates communication between the sfdx-hardis CLI and the VS Code Extension, enabling features like real-time status updates and plugin refreshes.\n\nKey functionalities:\n\n- **Refresh Status (`--event refreshStatus`):** Sends a message to the VS Code Extension to refresh its displayed status, ensuring that the UI reflects the latest state of Salesforce orgs or project activities.\n- **Refresh Plugins (`--event refreshPlugins`):** Sends a message to the VS Code Extension to refresh its loaded plugins, useful after installing or updating sfdx-hardis or other related extensions.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **WebSocketClient:** It utilizes the `WebSocketClient` utility to establish and manage WebSocket connections.\n- **Event-Driven Communication:** It listens for specific events (e.g., `refreshStatus`, `refreshPlugins`) and triggers corresponding actions on the connected WebSocket client.\n- **Internal Use:** This command is primarily called programmatically by the VS Code Extension to maintain synchronization and provide a seamless user experience.\n",
+      "description": "\n## Command Behavior\n\n**Performs technical operations related to WebSocket communication, primarily for internal use by the sfdx-hardis VS Code Extension.**\n\nThis command is not intended for direct end-user interaction. It facilitates communication between the sfdx-hardis CLI and the VS Code Extension, enabling features like real-time status updates and plugin refreshes.\n\nKey functionalities:\n\n- **Refresh Status (`--event refreshStatus`):** Sends a message to the VS Code Extension to refresh its displayed status, ensuring that the UI reflects the latest state of Salesforce orgs or project activities.\n- **Refresh Plugins (`--event refreshPlugins`):** Sends a message to the VS Code Extension to refresh its loaded plugins, useful after installing or updating sfdx-hardis or other related extensions.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **WebSocketClient:** It utilizes the `WebSocketClient` utility to establish and manage WebSocket connections.\n- **Event-Driven Communication:** It listens for specific events (e.g., `refreshStatus`, `refreshPlugins`) and triggers corresponding actions on the connected WebSocket client.\n- **Internal Use:** This command is primarily called programmatically by the VS Code Extension to maintain synchronization and provide a seamless user experience.\n</details>\n",
       "examples": [
         "$ sf hardis:work:ws --event refreshStatus"
       ],
@@ -4509,7 +4509,7 @@
     "hardis:doc:plugin:generate": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Generates Markdown documentation for an SF CLI plugin, ready for conversion into HTML with MkDocs.**\n\nThis command automates the creation of comprehensive documentation for your Salesforce CLI plugin. It processes your plugin's commands and their flags to generate structured Markdown files, which can then be used with MkDocs to produce a professional-looking website.\n\nKey functionalities:\n\n- **Command Documentation:** Generates a dedicated Markdown file for each command, including its description, parameters (flags), and examples.\n- **Index and Commands Pages:** Creates an `index.md` and `commands.md` file that list all available commands, providing an overview and easy navigation.\n- **MkDocs Integration:** Sets up the basic MkDocs project structure and updates the `mkdocs.yml` navigation to include the generated command documentation.\n- **Default File Copying:** Copies essential MkDocs configuration files and GitHub Actions workflows to your project, streamlining the setup for continuous documentation deployment.\n\n**Post-Generation Steps:**\n\nAfter the initial run, you will need to manually update:\n\n- `mkdocs.yml`: Customize the project title, theme, and other MkDocs settings.\n- `.github/workflows/build-deploy-docs.yml`: Configure the GitHub Actions workflow for automatic documentation deployment.\n- `docs/javascripts/gtag.js`: If desired, set up Google Analytics tracking.\n\nFinally, activate GitHub Pages with `gh_pages` as the target branch. This will enable automatic documentation rebuilding and publishing to GitHub Pages upon each merge into your `master`/`main` branch.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Plugin Configuration Loading:** It loads the SF CLI plugin's configuration using `@oclif/core`'s `Config.load()`, which provides access to all registered commands and their metadata.\n- **Command Iteration:** It iterates through each command defined in the plugin's configuration.\n- **Markdown File Generation:** For each command, it constructs a Markdown file (`.md`) containing:\n  - The command ID as the main heading.\n  - The command's `description` property.\n  - A table of parameters (flags), including their name, type, description, default value, required status, and available options. It dynamically extracts this information from the command's `flags` property.\n  - Code blocks for each example provided in the command's `examples` property.\n- **Navigation Structure:** It builds a nested JavaScript object (`commandsNav`) that mirrors the command hierarchy, which is then converted to YAML and inserted into `mkdocs.yml` to create the navigation menu.\n- **Index and Commands Page Generation:** It reads the project's `README.md` and extracts relevant sections to create the `index.md` file. It also generates a separate `commands.md` file listing all commands.\n- **File System Operations:** It uses `fs-extra` to create directories, copy default MkDocs files (`defaults/mkdocs`), and write the generated Markdown and YAML files.\n- **YAML Serialization:** It uses `js-yaml` to serialize the navigation object into YAML format for `mkdocs.yml`.\n",
+      "description": "\n## Command Behavior\n\n**Generates Markdown documentation for an SF CLI plugin, ready for conversion into HTML with MkDocs.**\n\nThis command automates the creation of comprehensive documentation for your Salesforce CLI plugin. It processes your plugin's commands and their flags to generate structured Markdown files, which can then be used with MkDocs to produce a professional-looking website.\n\nKey functionalities:\n\n- **Command Documentation:** Generates a dedicated Markdown file for each command, including its description, parameters (flags), and examples.\n- **Index and Commands Pages:** Creates an `index.md` and `commands.md` file that list all available commands, providing an overview and easy navigation.\n- **MkDocs Integration:** Sets up the basic MkDocs project structure and updates the `mkdocs.yml` navigation to include the generated command documentation.\n- **Default File Copying:** Copies essential MkDocs configuration files and GitHub Actions workflows to your project, streamlining the setup for continuous documentation deployment.\n\n**Post-Generation Steps:**\n\nAfter the initial run, you will need to manually update:\n\n- `mkdocs.yml`: Customize the project title, theme, and other MkDocs settings.\n- `.github/workflows/build-deploy-docs.yml`: Configure the GitHub Actions workflow for automatic documentation deployment.\n- `docs/javascripts/gtag.js`: If desired, set up Google Analytics tracking.\n\nFinally, activate GitHub Pages with `gh_pages` as the target branch. This will enable automatic documentation rebuilding and publishing to GitHub Pages upon each merge into your `master`/`main` branch.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Plugin Configuration Loading:** It loads the SF CLI plugin's configuration using `@oclif/core`'s `Config.load()`, which provides access to all registered commands and their metadata.\n- **Command Iteration:** It iterates through each command defined in the plugin's configuration.\n- **Markdown File Generation:** For each command, it constructs a Markdown file (`.md`) containing:\n  - The command ID as the main heading.\n  - The command's `description` property.\n  - A table of parameters (flags), including their name, type, description, default value, required status, and available options. It dynamically extracts this information from the command's `flags` property.\n  - Code blocks for each example provided in the command's `examples` property.\n- **Navigation Structure:** It builds a nested JavaScript object (`commandsNav`) that mirrors the command hierarchy, which is then converted to YAML and inserted into `mkdocs.yml` to create the navigation menu.\n- **Index and Commands Page Generation:** It reads the project's `README.md` and extracts relevant sections to create the `index.md` file. It also generates a separate `commands.md` file listing all commands.\n- **File System Operations:** It uses `fs-extra` to create directories, copy default MkDocs files (`defaults/mkdocs`), and write the generated Markdown and YAML files.\n- **YAML Serialization:** It uses `js-yaml` to serialize the navigation object into YAML format for `mkdocs.yml`.\n</details>\n",
       "examples": [
         "$ sf hardis:doc:plugin:generate"
       ],
@@ -4600,7 +4600,7 @@
     "hardis:git:pull-requests:extract": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Extracts pull request information from your Git server based on specified filtering criteria.**\n\nThis command provides a powerful way to query and retrieve details about pull requests (or merge requests, depending on your Git provider) in your repository. It's highly useful for reporting, auditing, and analyzing development workflows.\n\nKey functionalities include:\n\n- **Target Branch Filtering:** You can filter pull requests by their target branch using the `--target-branch` flag. If not specified, the command will prompt you to select one.\n- **Status Filtering:** Filter pull requests by their status: `open`, `merged`, or `abandoned` using the `--status` flag. An interactive prompt is provided if no status is specified.\n- **Minimum Date Filtering:** Use the `--min-date` flag to retrieve pull requests created or updated after a specific date.\n- **CSV Output:** The extracted pull request data is generated into a CSV file, which can be used for further analysis in spreadsheet software.\n\n## Technical explanations\n\nThe command's technical implementation involves interacting with a Git provider's API:\n\n- **Git Provider Abstraction:** It uses the `GitProvider.getInstance(true)` to abstract away the specifics of different Git platforms (e.g., GitHub, GitLab, Azure DevOps). This ensures the command can work across various environments.\n- **API Calls:** The `gitProvider.listPullRequests()` method is called with a `prConstraint` object that encapsulates the filtering criteria (target branch, minimum date, status).\n- **Interactive Prompts:** The `prompts` library is used to interactively gather input from the user for the target branch and pull request status if they are not provided as command-line flags.\n- **Date Handling:** The `moment` library is used to parse and handle date inputs for the `--min-date` flag.\n- **CSV Generation:** The `generateCsvFile` utility is responsible for converting the retrieved pull request data into a CSV format, and `generateReportPath` determines the output file location.\n- **Error Handling:** It includes error handling for cases where a Git provider cannot be identified.\n",
+      "description": "\n## Command Behavior\n\n**Extracts pull request information from your Git server based on specified filtering criteria.**\n\nThis command provides a powerful way to query and retrieve details about pull requests (or merge requests, depending on your Git provider) in your repository. It's highly useful for reporting, auditing, and analyzing development workflows.\n\nKey functionalities include:\n\n- **Target Branch Filtering:** You can filter pull requests by their target branch using the `--target-branch` flag. If not specified, the command will prompt you to select one.\n- **Status Filtering:** Filter pull requests by their status: `open`, `merged`, or `abandoned` using the `--status` flag. An interactive prompt is provided if no status is specified.\n- **Minimum Date Filtering:** Use the `--min-date` flag to retrieve pull requests created or updated after a specific date.\n- **CSV Output:** The extracted pull request data is generated into a CSV file, which can be used for further analysis in spreadsheet software.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves interacting with a Git provider's API:\n\n- **Git Provider Abstraction:** It uses the `GitProvider.getInstance(true)` to abstract away the specifics of different Git platforms (e.g., GitHub, GitLab, Azure DevOps). This ensures the command can work across various environments.\n- **API Calls:** The `gitProvider.listPullRequests()` method is called with a `prConstraint` object that encapsulates the filtering criteria (target branch, minimum date, status).\n- **Interactive Prompts:** The `prompts` library is used to interactively gather input from the user for the target branch and pull request status if they are not provided as command-line flags.\n- **Date Handling:** The `moment` library is used to parse and handle date inputs for the `--min-date` flag.\n- **CSV Generation:** The `generateCsvFile` utility is responsible for converting the retrieved pull request data into a CSV format, and `generateReportPath` determines the output file location.\n- **Error Handling:** It includes error handling for cases where a Git provider cannot be identified.\n</details>\n",
       "examples": [
         "$ sf hardis:git:pull-requests:extract",
         "$ sf hardis:git:pull-requests:extract --target-branch main --status merged"
@@ -4729,7 +4729,7 @@
     "hardis:org:community:update": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Updates the status of one or more Salesforce Experience Cloud (Community) networks.**\n\nThis command provides a way to programmatically change the status of your Salesforce Communities, allowing you to manage their availability. This is particularly useful for:\n\n- **Maintenance:** Taking communities offline for planned maintenance (`DownForMaintenance`).\n- **Activation/Deactivation:** Bringing communities online or offline (`Live`, `DownForMaintenance`).\n- **Automation:** Integrating community status changes into CI/CD pipelines or scheduled jobs.\n\nKey functionalities:\n\n- **Network Selection:** You can specify one or more community network names (separated by commas) using the `--name` flag.\n- **Status Update:** You can set the new status for the selected communities using the `--status` flag. Supported values are `Live` and `DownForMaintenance`.\n- **Confirmation Prompt:** In non-CI environments, it provides a confirmation prompt before executing the update, ensuring intentional changes.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Salesforce SOQL Query:** It first queries the Salesforce `Network` object using SOQL to retrieve the `Id`, `Name`, and `Status` of the specified communities. This ensures that only existing communities are targeted.\n- **SObject Update:** It then constructs an array of `Network` sObjects with their `Id` and the new `Status` and performs a DML update operation using `conn.sobject(\"Network\").update()`. The `allOrNone: false` option is used to allow partial success in case some updates fail.\n- **Error Handling and Reporting:** It iterates through the update results, logging success or failure for each community. It also provides a summary of successful and erroneous updates.\n- **User Interaction:** Uses `prompts` to confirm the update action with the user when not running in a CI environment.\n- **Salesforce Connection:** Establishes a connection to the target Salesforce org using the `target-org` flag.\n",
+      "description": "\n## Command Behavior\n\n**Updates the status of one or more Salesforce Experience Cloud (Community) networks.**\n\nThis command provides a way to programmatically change the status of your Salesforce Communities, allowing you to manage their availability. This is particularly useful for:\n\n- **Maintenance:** Taking communities offline for planned maintenance (`DownForMaintenance`).\n- **Activation/Deactivation:** Bringing communities online or offline (`Live`, `DownForMaintenance`).\n- **Automation:** Integrating community status changes into CI/CD pipelines or scheduled jobs.\n\nKey functionalities:\n\n- **Network Selection:** You can specify one or more community network names (separated by commas) using the `--name` flag.\n- **Status Update:** You can set the new status for the selected communities using the `--status` flag. Supported values are `Live` and `DownForMaintenance`.\n- **Confirmation Prompt:** In non-CI environments, it provides a confirmation prompt before executing the update, ensuring intentional changes.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Salesforce SOQL Query:** It first queries the Salesforce `Network` object using SOQL to retrieve the `Id`, `Name`, and `Status` of the specified communities. This ensures that only existing communities are targeted.\n- **SObject Update:** It then constructs an array of `Network` sObjects with their `Id` and the new `Status` and performs a DML update operation using `conn.sobject(\"Network\").update()`. The `allOrNone: false` option is used to allow partial success in case some updates fail.\n- **Error Handling and Reporting:** It iterates through the update results, logging success or failure for each community. It also provides a summary of successful and erroneous updates.\n- **User Interaction:** Uses `prompts` to confirm the update action with the user when not running in a CI environment.\n- **Salesforce Connection:** Establishes a connection to the target Salesforce org using the `target-org` flag.\n</details>\n",
       "examples": [
         "$ sf hardis:org:community:update --name 'MyNetworkName' --status DownForMaintenance",
         "$ sf hardis:org:community:update --name 'MyNetworkName,MySecondNetworkName' --status Live"
@@ -4840,7 +4840,7 @@
     "hardis:org:configure:data": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Configures a Salesforce Data Migration Utility (SFDMU) project for data export and import operations.**\n\nThis command assists in setting up SFDMU workspaces, which are essential for managing data within your Salesforce environments. It streamlines the creation of `export.json` files and related configurations, enabling efficient data seeding, migration, and synchronization.\n\nKey functionalities:\n\n- **Template-Based Configuration:** Allows you to choose from predefined SFDMU templates or start with a blank configuration. Templates can pre-populate `export.json` with common data migration scenarios.\n- **Interactive Setup:** Guides you through the process of defining the SFDMU project folder name, label, and description.\n- **`export.json` Generation:** Creates the `export.json` file, which is the core configuration file for SFDMU, defining objects to export/import, queries, and operations.\n- **Additional File Generation:** Can generate additional configuration files, such as a `badwords.json` file for data filtering scenarios.\n- **Scratch Org Integration:** Offers to automatically configure the SFDMU project to be used for data import when initializing a new scratch org, ensuring consistent test data across development environments.\n\nSee this article for a practical example:\n\n[![How to detect bad words in Salesforce records using SFDX Data Loader and sfdx-hardis](https://github.com/hardisgroupcom/sfdx-hardis/raw/main/docs/assets/images/article-badwords.jpg)](https://nicolas.vuillamy.fr/how-to-detect-bad-words-in-salesforce-records-using-sfdx-data-loader-and-sfdx-hardis-171db40a9bac)\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **SFDMU Integration:** It acts as a setup wizard for SFDMU, generating the necessary configuration files that the `sfdmu` plugin consumes.\n- **Interactive Prompts:** Uses the `prompts` library to gather user input for various configuration parameters, such as the data path, label, and description.\n- **File System Operations:** Employs `fs-extra` to create directories (e.g., `data/your-project-name/`) and write the `export.json` and any additional configuration files.\n- **JSON Manipulation:** Constructs the `export.json` content dynamically based on user input and selected templates, including defining objects, queries, and operations.\n- **PascalCase Conversion:** Uses `pascalcase` to format the SFDMU folder name consistently.\n- **Configuration Persistence:** Updates the project's `sfdx-hardis.yml` file (via `setConfig`) to include the newly configured data package if it's intended for scratch org initialization.\n- **WebSocket Communication:** Uses `WebSocketClient.requestOpenFile` to open the generated `export.json` file in VS Code, facilitating immediate configuration.\n- **Required Plugin Check:** Explicitly lists `sfdmu` as a required plugin, ensuring the necessary dependency is present.\n",
+      "description": "\n## Command Behavior\n\n**Configures a Salesforce Data Migration Utility (SFDMU) project for data export and import operations.**\n\nThis command assists in setting up SFDMU workspaces, which are essential for managing data within your Salesforce environments. It streamlines the creation of `export.json` files and related configurations, enabling efficient data seeding, migration, and synchronization.\n\nKey functionalities:\n\n- **Template-Based Configuration:** Allows you to choose from predefined SFDMU templates or start with a blank configuration. Templates can pre-populate `export.json` with common data migration scenarios.\n- **Interactive Setup:** Guides you through the process of defining the SFDMU project folder name, label, and description.\n- **`export.json` Generation:** Creates the `export.json` file, which is the core configuration file for SFDMU, defining objects to export/import, queries, and operations.\n- **Additional File Generation:** Can generate additional configuration files, such as a `badwords.json` file for data filtering scenarios.\n- **Scratch Org Integration:** Offers to automatically configure the SFDMU project to be used for data import when initializing a new scratch org, ensuring consistent test data across development environments.\n\nSee this article for a practical example:\n\n[![How to detect bad words in Salesforce records using SFDX Data Loader and sfdx-hardis](https://github.com/hardisgroupcom/sfdx-hardis/raw/main/docs/assets/images/article-badwords.jpg)](https://nicolas.vuillamy.fr/how-to-detect-bad-words-in-salesforce-records-using-sfdx-data-loader-and-sfdx-hardis-171db40a9bac)\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **SFDMU Integration:** It acts as a setup wizard for SFDMU, generating the necessary configuration files that the `sfdmu` plugin consumes.\n- **Interactive Prompts:** Uses the `prompts` library to gather user input for various configuration parameters, such as the data path, label, and description.\n- **File System Operations:** Employs `fs-extra` to create directories (e.g., `data/your-project-name/`) and write the `export.json` and any additional configuration files.\n- **JSON Manipulation:** Constructs the `export.json` content dynamically based on user input and selected templates, including defining objects, queries, and operations.\n- **PascalCase Conversion:** Uses `pascalcase` to format the SFDMU folder name consistently.\n- **Configuration Persistence:** Updates the project's `sfdx-hardis.yml` file (via `setConfig`) to include the newly configured data package if it's intended for scratch org initialization.\n- **WebSocket Communication:** Uses `WebSocketClient.requestOpenFile` to open the generated `export.json` file in VS Code, facilitating immediate configuration.\n- **Required Plugin Check:** Explicitly lists `sfdmu` as a required plugin, ensuring the necessary dependency is present.\n</details>\n",
       "examples": [
         "$ sf hardis:org:configure:data"
       ],
@@ -4934,7 +4934,7 @@
     "hardis:org:configure:files": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Configures a project for exporting file attachments from a Salesforce org.**\n\nThis command streamlines the setup of configurations for mass downloading files (such as Notes, Attachments, or Salesforce Files) associated with Salesforce records. It's particularly useful for data backups, migrations, or integrating Salesforce files with external systems.\n\nKey functionalities:\n\n- **Template-Based Configuration:** Allows you to choose from predefined templates for common file export scenarios or start with a blank configuration. Templates can pre-populate the export settings.\n- **Interactive Setup:** Guides you through defining the export project folder name and other export parameters.\n- **`export.json` Generation:** Creates an `export.json` file within the designated project folder. This file contains the configuration for the file export operation, including:\n  - **SOQL Query:** A SOQL query to select the parent records from which files will be exported.\n  - **File Types:** Specifies which types of files (e.g., `ContentVersion`, `Attachment`) to include.\n  - **Output Folder/File Naming:** Defines how the exported files and their containing folders will be named based on record fields.\n  - **Overwrite Options:** Controls whether existing files or parent records should be overwritten during the export.\n\nSee this article for a practical example:\n\n[![How to mass download notes and attachments files from a Salesforce org](https://github.com/hardisgroupcom/sfdx-hardis/raw/main/docs/assets/images/article-mass-download.jpg)](https://nicolas.vuillamy.fr/how-to-mass-download-notes-and-attachments-files-from-a-salesforce-org-83a028824afd)\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Template Selection:** It uses `selectTemplate` to present predefined file export templates or a blank option to the user.\n- **Interactive Prompts:** The `promptFilesExportConfiguration` utility is used to gather detailed export settings from the user, such as the SOQL query, file types, and naming conventions.\n- **File System Operations:** Employs `fs-extra` to create the project directory (`files/your-project-name/`) and write the `export.json` configuration file.\n- **PascalCase Conversion:** Uses `pascalcase` to format the files export path consistently.\n- **JSON Serialization:** Serializes the collected export configuration into a JSON string and writes it to `export.json`.\n- **WebSocket Communication:** Uses `WebSocketClient.requestOpenFile` to open the generated `export.json` file in VS Code, facilitating immediate configuration.\n",
+      "description": "\n## Command Behavior\n\n**Configures a project for exporting file attachments from a Salesforce org.**\n\nThis command streamlines the setup of configurations for mass downloading files (such as Notes, Attachments, or Salesforce Files) associated with Salesforce records. It's particularly useful for data backups, migrations, or integrating Salesforce files with external systems.\n\nKey functionalities:\n\n- **Template-Based Configuration:** Allows you to choose from predefined templates for common file export scenarios or start with a blank configuration. Templates can pre-populate the export settings.\n- **Interactive Setup:** Guides you through defining the export project folder name and other export parameters.\n- **`export.json` Generation:** Creates an `export.json` file within the designated project folder. This file contains the configuration for the file export operation, including:\n  - **SOQL Query:** A SOQL query to select the parent records from which files will be exported.\n  - **File Types:** Specifies which types of files (e.g., `ContentVersion`, `Attachment`) to include.\n  - **Output Folder/File Naming:** Defines how the exported files and their containing folders will be named based on record fields.\n  - **Overwrite Options:** Controls whether existing files or parent records should be overwritten during the export.\n\nSee this article for a practical example:\n\n[![How to mass download notes and attachments files from a Salesforce org](https://github.com/hardisgroupcom/sfdx-hardis/raw/main/docs/assets/images/article-mass-download.jpg)](https://nicolas.vuillamy.fr/how-to-mass-download-notes-and-attachments-files-from-a-salesforce-org-83a028824afd)\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Template Selection:** It uses `selectTemplate` to present predefined file export templates or a blank option to the user.\n- **Interactive Prompts:** The `promptFilesExportConfiguration` utility is used to gather detailed export settings from the user, such as the SOQL query, file types, and naming conventions.\n- **File System Operations:** Employs `fs-extra` to create the project directory (`files/your-project-name/`) and write the `export.json` configuration file.\n- **PascalCase Conversion:** Uses `pascalcase` to format the files export path consistently.\n- **JSON Serialization:** Serializes the collected export configuration into a JSON string and writes it to `export.json`.\n- **WebSocket Communication:** Uses `WebSocketClient.requestOpenFile` to open the generated `export.json` file in VS Code, facilitating immediate configuration.\n</details>\n",
       "examples": [
         "$ sf hardis:org:configure:files"
       ],
@@ -5025,7 +5025,7 @@
     "hardis:org:configure:monitoring": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Configures the monitoring of a Salesforce org within a dedicated Git repository.**\n\nThis command streamlines the setup of continuous monitoring for a Salesforce organization, ensuring that changes and health metrics are tracked and reported. It is designed to be run within a Git repository specifically dedicated to monitoring configurations.\n\nKey functionalities include:\n\n- **Git Repository Validation:** Ensures the current Git repository's name contains \"monitoring\" to enforce best practices for separating monitoring configurations from deployment sources.\n- **Prerequisite Check:** Guides the user to confirm that necessary monitoring prerequisites (CI/CD variables, permissions) are configured on their Git server.\n- **Org Selection:** Prompts the user to select or connect to the Salesforce org they wish to monitor.\n- **Monitoring Branch Creation:** Creates or checks out a dedicated Git branch (e.g., `monitoring_yourinstanceurl`) for the monitoring configuration.\n- **SFDX Project Setup:** Initializes an SFDX project structure within the repository if it doesn't already exist, and copies default monitoring files.\n- **Configuration File Update:** Updates the local `.sfdx-hardis.yml` file with the target org's username and instance URL.\n- **SSL Certificate Generation:** Generates an SSL certificate for secure authentication to the monitored org.\n- **Automated Commit and Push:** Offers to automatically commit and push the generated configuration files to the remote Git repository.\n- **Scheduling Guidance:** Provides instructions and links for scheduling the monitoring job on the Git server.\n\n## Technical explanations\n\nThe command's technical implementation involves a series of Git operations, file system manipulations, and Salesforce CLI interactions:\n\n- **Git Operations:** Utilizes `ensureGitRepository`, `getGitRepoName`, `execCommand` (for `git add`, `git stash`), `ensureGitBranch`, and `gitAddCommitPush` to manage the Git repository, branches, and commits.\n- **Interactive Prompts:** Employs the `prompts` library to interact with the user for confirmations and selections.\n- **File System Management:** Uses `fs-extra` for copying default monitoring files (`defaults/monitoring`) and managing the SFDX project structure.\n- **Salesforce CLI Integration:** Calls `sf project generate` to create a new SFDX project and uses `promptOrg` for Salesforce org authentication and selection.\n- **Configuration Management:** Updates the `.sfdx-hardis.yml` file using `setInConfigFile` to store org-specific monitoring configurations.\n- **SSL Certificate Generation:** Leverages `generateSSLCertificate` to create the necessary SSL certificates for JWT-based authentication to the Salesforce org.\n- **External Tool Integration:** Requires `openssl` to be installed on the system for SSL certificate generation.\n- **WebSocket Communication:** Uses `WebSocketClient.sendRunSfdxHardisCommandMessage` to restart the command in VS Code if the default org changes, and `WebSocketClient.sendRefreshStatusMessage` to update the status.\n",
+      "description": "\n## Command Behavior\n\n**Configures the monitoring of a Salesforce org within a dedicated Git repository.**\n\nThis command streamlines the setup of continuous monitoring for a Salesforce organization, ensuring that changes and health metrics are tracked and reported. It is designed to be run within a Git repository specifically dedicated to monitoring configurations.\n\nKey functionalities include:\n\n- **Git Repository Validation:** Ensures the current Git repository's name contains \"monitoring\" to enforce best practices for separating monitoring configurations from deployment sources.\n- **Prerequisite Check:** Guides the user to confirm that necessary monitoring prerequisites (CI/CD variables, permissions) are configured on their Git server.\n- **Org Selection:** Prompts the user to select or connect to the Salesforce org they wish to monitor.\n- **Monitoring Branch Creation:** Creates or checks out a dedicated Git branch (e.g., `monitoring_yourinstanceurl`) for the monitoring configuration.\n- **SFDX Project Setup:** Initializes an SFDX project structure within the repository if it doesn't already exist, and copies default monitoring files.\n- **Configuration File Update:** Updates the local `.sfdx-hardis.yml` file with the target org's username and instance URL.\n- **SSL Certificate Generation:** Generates an SSL certificate for secure authentication to the monitored org.\n- **Automated Commit and Push:** Offers to automatically commit and push the generated configuration files to the remote Git repository.\n- **Scheduling Guidance:** Provides instructions and links for scheduling the monitoring job on the Git server.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves a series of Git operations, file system manipulations, and Salesforce CLI interactions:\n\n- **Git Operations:** Utilizes `ensureGitRepository`, `getGitRepoName`, `execCommand` (for `git add`, `git stash`), `ensureGitBranch`, and `gitAddCommitPush` to manage the Git repository, branches, and commits.\n- **Interactive Prompts:** Employs the `prompts` library to interact with the user for confirmations and selections.\n- **File System Management:** Uses `fs-extra` for copying default monitoring files (`defaults/monitoring`) and managing the SFDX project structure.\n- **Salesforce CLI Integration:** Calls `sf project generate` to create a new SFDX project and uses `promptOrg` for Salesforce org authentication and selection.\n- **Configuration Management:** Updates the `.sfdx-hardis.yml` file using `setInConfigFile` to store org-specific monitoring configurations.\n- **SSL Certificate Generation:** Leverages `generateSSLCertificate` to create the necessary SSL certificates for JWT-based authentication to the Salesforce org.\n- **External Tool Integration:** Requires `openssl` to be installed on the system for SSL certificate generation.\n- **WebSocket Communication:** Uses `WebSocketClient.sendRunSfdxHardisCommandMessage` to restart the command in VS Code if the default org changes, and `WebSocketClient.sendRefreshStatusMessage` to update the status.\n</details>\n",
       "examples": [
         "$ sf hardis:org:configure:monitoring"
       ],
@@ -5141,7 +5141,7 @@
     "hardis:org:data:delete": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Deletes records in multiple Salesforce objects using an SFDMU (Salesforce Data Migration Utility) workspace.**\n\nThis command provides a powerful and controlled way to remove data from your Salesforce orgs based on configurations defined in an SFDMU workspace. It's particularly useful for:\n\n- **Data Cleanup:** Removing test data, obsolete records, or sensitive information.\n- **Environment Reset:** Preparing sandboxes for new development cycles by clearing specific data sets.\n- **Compliance:** Deleting data to meet regulatory requirements.\n\n**Important Considerations for Production Environments:**\n\nIf you intend to run this command in a production environment, you must:\n\n- Set `runnableInProduction` to `true` in your `export.json` file within the SFDMU workspace.\n- Define `sfdmuCanModify: YOUR_INSTANCE_URL` in your branch-specific configuration file (e.g., `config/branches/.sfdx-hardis.YOUR_BRANCH.yml`) to explicitly authorize data modification for that instance.\n\n## Technical explanations\n\nThe command's technical implementation relies heavily on the SFDMU plugin:\n\n- **SFDMU Integration:** It leverages the `sfdmu` plugin to perform the actual data deletion operations. The command acts as a wrapper, providing an assisted interface for SFDMU execution.\n- **Workspace Selection:** If the SFDMU workspace path is not provided via the `--path` flag, it interactively prompts the user to select a data workspace using `selectDataWorkspace`.\n- **Org Selection:** It ensures that a target Salesforce org is selected (either via the `--target-org` flag or through an interactive prompt using `promptOrgUsernameDefault`) to specify where the data deletion will occur.\n- **`deleteData` Utility:** The core logic for executing the SFDMU deletion process is encapsulated within the `deleteData` utility function, which takes the SFDMU workspace path and the target username as arguments.\n- **Environment Awareness:** It checks the `isCI` flag to determine whether to run in an interactive mode (prompting for user input) or a non-interactive mode (relying solely on command-line flags).\n- **Required Plugin:** It explicitly lists `sfdmu` as a required plugin, ensuring that the necessary dependency is in place before execution.\n",
+      "description": "\n## Command Behavior\n\n**Deletes records in multiple Salesforce objects using an SFDMU (Salesforce Data Migration Utility) workspace.**\n\nThis command provides a powerful and controlled way to remove data from your Salesforce orgs based on configurations defined in an SFDMU workspace. It's particularly useful for:\n\n- **Data Cleanup:** Removing test data, obsolete records, or sensitive information.\n- **Environment Reset:** Preparing sandboxes for new development cycles by clearing specific data sets.\n- **Compliance:** Deleting data to meet regulatory requirements.\n\n**Important Considerations for Production Environments:**\n\nIf you intend to run this command in a production environment, you must:\n\n- Set `runnableInProduction` to `true` in your `export.json` file within the SFDMU workspace.\n- Define `sfdmuCanModify: YOUR_INSTANCE_URL` in your branch-specific configuration file (e.g., `config/branches/.sfdx-hardis.YOUR_BRANCH.yml`) to explicitly authorize data modification for that instance.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation relies heavily on the SFDMU plugin:\n\n- **SFDMU Integration:** It leverages the `sfdmu` plugin to perform the actual data deletion operations. The command acts as a wrapper, providing an assisted interface for SFDMU execution.\n- **Workspace Selection:** If the SFDMU workspace path is not provided via the `--path` flag, it interactively prompts the user to select a data workspace using `selectDataWorkspace`.\n- **Org Selection:** It ensures that a target Salesforce org is selected (either via the `--target-org` flag or through an interactive prompt using `promptOrgUsernameDefault`) to specify where the data deletion will occur.\n- **`deleteData` Utility:** The core logic for executing the SFDMU deletion process is encapsulated within the `deleteData` utility function, which takes the SFDMU workspace path and the target username as arguments.\n- **Environment Awareness:** It checks the `isCI` flag to determine whether to run in an interactive mode (prompting for user input) or a non-interactive mode (relying solely on command-line flags).\n- **Required Plugin:** It explicitly lists `sfdmu` as a required plugin, ensuring that the necessary dependency is in place before execution.\n</details>\n",
       "examples": [
         "$ sf hardis:org:data:delete"
       ],
@@ -5258,7 +5258,7 @@
     "hardis:org:data:export": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Exports data from a Salesforce org using an SFDMU (Salesforce Data Migration Utility) project.**\n\nThis command facilitates the extraction of data from your Salesforce environments based on configurations defined in an SFDMU workspace. It's a powerful tool for various data-related tasks, including:\n\n- **Data Backup:** Creating snapshots of your Salesforce data.\n- **Data Migration:** Extracting data for transfer to another Salesforce org or external system.\n- **Reporting and Analysis:** Exporting specific datasets for detailed analysis outside of Salesforce.\n- **Data Seeding:** Preparing data for import into other environments.\n\nKey functionalities:\n\n- **SFDMU Workspace Integration:** Leverages an existing SFDMU workspace (defined by an `export.json` file) to determine which objects and records to export, along with any filtering or transformation rules.\n- **Interactive Workspace Selection:** If the SFDMU workspace path is not provided via the `--path` flag, it interactively prompts the user to select one.\n- **Org Selection:** Ensures that a target Salesforce org is selected (either via the `--target-org` flag or through an interactive prompt) to specify the source of the data export.\n\nSee this article for a practical example:\n\n[![How to detect bad words in Salesforce records using SFDX Data Loader and sfdx-hardis](https://github.com/hardisgroupcom/sfdx-hardis/raw/main/docs/assets/images/article-badwords.jpg)](https://nicolas.vuillamy.fr/how-to-detect-bad-words-in-salesforce-records-using-sfdx-data-loader-and-sfdx-hardis-171db40a9bac)\n\n## Technical explanations\n\nThe command's technical implementation relies heavily on the SFDMU plugin:\n\n- **SFDMU Integration:** It acts as a wrapper around the `sfdmu` plugin, which performs the actual data export operations. The command provides an assisted interface for SFDMU execution.\n- **`exportData` Utility:** The core logic for executing the SFDMU export process is encapsulated within the `exportData` utility function, which takes the SFDMU workspace path and the source username as arguments.\n- **Interactive Prompts:** Uses `selectDataWorkspace` to allow the user to choose an SFDMU project and `promptOrgUsernameDefault` for selecting the source Salesforce org when not running in a CI environment.\n- **Environment Awareness:** Checks the `isCI` flag to determine whether to run in an interactive mode (prompting for user input) or a non-interactive mode (relying solely on command-line flags).\n- **Required Plugin:** It explicitly lists `sfdmu` as a required plugin, ensuring that the necessary dependency is in place before execution.\n",
+      "description": "\n## Command Behavior\n\n**Exports data from a Salesforce org using an SFDMU (Salesforce Data Migration Utility) project.**\n\nThis command facilitates the extraction of data from your Salesforce environments based on configurations defined in an SFDMU workspace. It's a powerful tool for various data-related tasks, including:\n\n- **Data Backup:** Creating snapshots of your Salesforce data.\n- **Data Migration:** Extracting data for transfer to another Salesforce org or external system.\n- **Reporting and Analysis:** Exporting specific datasets for detailed analysis outside of Salesforce.\n- **Data Seeding:** Preparing data for import into other environments.\n\nKey functionalities:\n\n- **SFDMU Workspace Integration:** Leverages an existing SFDMU workspace (defined by an `export.json` file) to determine which objects and records to export, along with any filtering or transformation rules.\n- **Interactive Workspace Selection:** If the SFDMU workspace path is not provided via the `--path` flag, it interactively prompts the user to select one.\n- **Org Selection:** Ensures that a target Salesforce org is selected (either via the `--target-org` flag or through an interactive prompt) to specify the source of the data export.\n\nSee this article for a practical example:\n\n[![How to detect bad words in Salesforce records using SFDX Data Loader and sfdx-hardis](https://github.com/hardisgroupcom/sfdx-hardis/raw/main/docs/assets/images/article-badwords.jpg)](https://nicolas.vuillamy.fr/how-to-detect-bad-words-in-salesforce-records-using-sfdx-data-loader-and-sfdx-hardis-171db40a9bac)\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation relies heavily on the SFDMU plugin:\n\n- **SFDMU Integration:** It acts as a wrapper around the `sfdmu` plugin, which performs the actual data export operations. The command provides an assisted interface for SFDMU execution.\n- **`exportData` Utility:** The core logic for executing the SFDMU export process is encapsulated within the `exportData` utility function, which takes the SFDMU workspace path and the source username as arguments.\n- **Interactive Prompts:** Uses `selectDataWorkspace` to allow the user to choose an SFDMU project and `promptOrgUsernameDefault` for selecting the source Salesforce org when not running in a CI environment.\n- **Environment Awareness:** Checks the `isCI` flag to determine whether to run in an interactive mode (prompting for user input) or a non-interactive mode (relying solely on command-line flags).\n- **Required Plugin:** It explicitly lists `sfdmu` as a required plugin, ensuring that the necessary dependency is in place before execution.\n</details>\n",
       "examples": [
         "$ sf hardis:org:data:export"
       ],
@@ -5492,7 +5492,7 @@
     "hardis:org:files:export": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Exports file attachments (ContentVersion, Attachment) from a Salesforce org based on a predefined configuration.**\n\nThis command enables the mass download of files associated with Salesforce records, providing a robust solution for backing up files, migrating them to other systems, or integrating them with external document management solutions.\n\nKey functionalities:\n\n- **Configuration-Driven Export:** Relies on an `export.json` file within a designated file export project to define the export criteria, including the SOQL query for parent records, file types to export, and output naming conventions.\n- **Interactive Project Selection:** If the file export project path is not provided via the `--path` flag, it interactively prompts the user to select one.\n- **Configurable Export Options:** Allows overriding default export settings such as `chunksize` (number of records processed in a batch), `polltimeout` (timeout for Bulk API calls), and `startchunknumber` (to resume a failed export).\n- **Support for ContentVersion and Attachment:** Handles both modern Salesforce Files (ContentVersion) and older Attachments.\n\nSee this article for a practical example:\n\n[![How to mass download notes and attachments files from a Salesforce org](https://github.com/hardisgroupcom/sfdx-hardis/raw/main/docs/assets/images/article-mass-download.jpg)](https://nicolas.vuillamy.fr/how-to-mass-download-notes-and-attachments-files-from-a-salesforce-org-83a028824afd)\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **FilesExporter Class:** The core logic is encapsulated within the `FilesExporter` class, which orchestrates the entire export process.\n- **SOQL Queries (Bulk API):** It uses Salesforce Bulk API queries to efficiently retrieve large volumes of parent record IDs and file metadata.\n- **File Download:** Downloads the actual file content from Salesforce.\n- **File System Operations:** Writes the downloaded files to the local file system, organizing them into folders based on the configured naming conventions.\n- **Configuration Loading:** Reads the `export.json` file to get the export configuration. It also allows for interactive overriding of these settings.\n- **Interactive Prompts:** Uses `selectFilesWorkspace` to allow the user to choose a file export project and `promptFilesExportConfiguration` for customizing export options.\n- **Error Handling:** Includes mechanisms to handle potential errors during the export process, such as network issues or API limits.\n",
+      "description": "\n## Command Behavior\n\n**Exports file attachments (ContentVersion, Attachment) from a Salesforce org based on a predefined configuration.**\n\nThis command enables the mass download of files associated with Salesforce records, providing a robust solution for backing up files, migrating them to other systems, or integrating them with external document management solutions.\n\nKey functionalities:\n\n- **Configuration-Driven Export:** Relies on an `export.json` file within a designated file export project to define the export criteria, including the SOQL query for parent records, file types to export, and output naming conventions.\n- **Interactive Project Selection:** If the file export project path is not provided via the `--path` flag, it interactively prompts the user to select one.\n- **Configurable Export Options:** Allows overriding default export settings such as `chunksize` (number of records processed in a batch), `polltimeout` (timeout for Bulk API calls), and `startchunknumber` (to resume a failed export).\n- **Support for ContentVersion and Attachment:** Handles both modern Salesforce Files (ContentVersion) and older Attachments.\n\nSee this article for a practical example:\n\n[![How to mass download notes and attachments files from a Salesforce org](https://github.com/hardisgroupcom/sfdx-hardis/raw/main/docs/assets/images/article-mass-download.jpg)](https://nicolas.vuillamy.fr/how-to-mass-download-notes-and-attachments-files-from-a-salesforce-org-83a028824afd)\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **FilesExporter Class:** The core logic is encapsulated within the `FilesExporter` class, which orchestrates the entire export process.\n- **SOQL Queries (Bulk API):** It uses Salesforce Bulk API queries to efficiently retrieve large volumes of parent record IDs and file metadata.\n- **File Download:** Downloads the actual file content from Salesforce.\n- **File System Operations:** Writes the downloaded files to the local file system, organizing them into folders based on the configured naming conventions.\n- **Configuration Loading:** Reads the `export.json` file to get the export configuration. It also allows for interactive overriding of these settings.\n- **Interactive Prompts:** Uses `selectFilesWorkspace` to allow the user to choose a file export project and `promptFilesExportConfiguration` for customizing export options.\n- **Error Handling:** Includes mechanisms to handle potential errors during the export process, such as network issues or API limits.\n</details>\n",
       "examples": [
         "$ sf hardis:org:files:export"
       ],
@@ -5633,7 +5633,7 @@
     "hardis:org:files:import": {
       "aliases": [],
       "args": {},
-      "description": "\nThis command facilitates the mass upload of files into Salesforce, allowing you to populate records with associated documents, images, or other file types. It's a crucial tool for data migration, content seeding, or synchronizing external file repositories with Salesforce.\n\nKey functionalities:\n\n- **Configuration-Driven Import:** Relies on an `export.json` file within a designated file export project (created using `sf hardis:org:configure:files`) to determine which files to import and how they should be associated with Salesforce records.\n- **Interactive Project Selection:** If the file import project path is not provided via the `--path` flag, it interactively prompts the user to select one.\n- **Overwrite Option:** The `--overwrite` flag allows you to replace existing files in Salesforce with local versions that have the same name. Be aware that this option doubles the number of API calls used.\n- **Support for ContentVersion and Attachment:** Handles both modern Salesforce Files (ContentVersion) and older Attachments.\n\nSee this article for how to export files, which is often a prerequisite for importing:\n\n[![How to mass download notes and attachments files from a Salesforce org](https://github.com/hardisgroupcom/sfdx-hardis/raw/main/docs/assets/images/article-mass-download.jpg)](https://nicolas.vuillamy.fr/how-to-mass-download-notes-and-attachments-files-from-a-salesforce-org-83a028824afd)\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **FilesImporter Class:** The core logic is encapsulated within the `FilesImporter` class, which orchestrates the entire import process.\n- **File System Scan:** Scans the local file system within the configured project directory to identify files for import.\n- **Salesforce API Interaction:** Uses Salesforce APIs (e.g., ContentVersion, Attachment) to upload files and associate them with records.\n- **Configuration Loading:** Reads the `export.json` file to get the import configuration, including SOQL queries to identify parent records for file association.\n- **Interactive Prompts:** Uses `selectFilesWorkspace` to allow the user to choose a file import project and `prompts` for confirming the overwrite behavior.\n- **Error Handling:** Includes mechanisms to handle potential errors during the import process, such as API limits or file upload failures.\n",
+      "description": "\nThis command facilitates the mass upload of files into Salesforce, allowing you to populate records with associated documents, images, or other file types. It's a crucial tool for data migration, content seeding, or synchronizing external file repositories with Salesforce.\n\nKey functionalities:\n\n- **Configuration-Driven Import:** Relies on an `export.json` file within a designated file export project (created using `sf hardis:org:configure:files`) to determine which files to import and how they should be associated with Salesforce records.\n- **Interactive Project Selection:** If the file import project path is not provided via the `--path` flag, it interactively prompts the user to select one.\n- **Overwrite Option:** The `--overwrite` flag allows you to replace existing files in Salesforce with local versions that have the same name. Be aware that this option doubles the number of API calls used.\n- **Support for ContentVersion and Attachment:** Handles both modern Salesforce Files (ContentVersion) and older Attachments.\n\nSee this article for how to export files, which is often a prerequisite for importing:\n\n[![How to mass download notes and attachments files from a Salesforce org](https://github.com/hardisgroupcom/sfdx-hardis/raw/main/docs/assets/images/article-mass-download.jpg)](https://nicolas.vuillamy.fr/how-to-mass-download-notes-and-attachments-files-from-a-salesforce-org-83a028824afd)\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **FilesImporter Class:** The core logic is encapsulated within the `FilesImporter` class, which orchestrates the entire import process.\n- **File System Scan:** Scans the local file system within the configured project directory to identify files for import.\n- **Salesforce API Interaction:** Uses Salesforce APIs (e.g., ContentVersion, Attachment) to upload files and associate them with records.\n- **Configuration Loading:** Reads the `export.json` file to get the import configuration, including SOQL queries to identify parent records for file association.\n- **Interactive Prompts:** Uses `selectFilesWorkspace` to allow the user to choose a file import project and `prompts` for confirming the overwrite behavior.\n- **Error Handling:** Includes mechanisms to handle potential errors during the import process, such as API limits or file upload failures.\n</details>\n",
       "examples": [
         "$ sf hardis:org:files:import"
       ],
@@ -5887,7 +5887,7 @@
     "hardis:org:diagnose:instanceupgrade": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Retrieves and displays the scheduled upgrade date for a Salesforce org's instance.**\n\nThis command provides crucial information about when your Salesforce instance will be upgraded to the next major release (Spring, Summer, or Winter). This is vital for release planning, testing, and ensuring compatibility with upcoming Salesforce features.\n\nKey functionalities:\n\n- **Instance Identification:** Determines the Salesforce instance name of your target org.\n- **Upgrade Date Retrieval:** Fetches the planned start time of the next major core service upgrade for that instance from the Salesforce Status API.\n- **Days Until Upgrade:** Calculates and displays the number of days remaining until the next major upgrade.\n- **Severity-Based Logging:** Adjusts the log severity (info, warning) based on the proximity of the upgrade date, providing a visual cue for urgency.\n- **Notifications:** Sends notifications to configured channels (e.g., Slack, MS Teams, Grafana) with the upgrade information, making it suitable for automated monitoring.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Salesforce SOQL Query:** It first queries the `Organization` object in Salesforce to get the `InstanceName` of the target org.\n- **Salesforce Status API Integration:** It makes an HTTP GET request to the Salesforce Status API (`https://api.status.salesforce.com/v1/instances/{instanceName}/status`) to retrieve detailed information about the instance, including scheduled maintenances.\n- **Data Parsing:** It parses the JSON response from the Status API to extract the relevant major release upgrade information.\n- **Date Calculation:** Uses the `moment` library to calculate the difference in days between the current date and the planned upgrade date.\n- **Notification Integration:** It integrates with the `NotifProvider` to send notifications, including the instance name, upgrade date, and days remaining, along with relevant metrics for monitoring dashboards.\n- **User Feedback:** Provides clear messages to the user about the upgrade status and proximity.\n",
+      "description": "\n## Command Behavior\n\n**Retrieves and displays the scheduled upgrade date for a Salesforce org's instance.**\n\nThis command provides crucial information about when your Salesforce instance will be upgraded to the next major release (Spring, Summer, or Winter). This is vital for release planning, testing, and ensuring compatibility with upcoming Salesforce features.\n\nKey functionalities:\n\n- **Instance Identification:** Determines the Salesforce instance name of your target org.\n- **Upgrade Date Retrieval:** Fetches the planned start time of the next major core service upgrade for that instance from the Salesforce Status API.\n- **Days Until Upgrade:** Calculates and displays the number of days remaining until the next major upgrade.\n- **Severity-Based Logging:** Adjusts the log severity (info, warning) based on the proximity of the upgrade date, providing a visual cue for urgency.\n- **Notifications:** Sends notifications to configured channels (e.g., Slack, MS Teams, Grafana) with the upgrade information, making it suitable for automated monitoring.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Salesforce SOQL Query:** It first queries the `Organization` object in Salesforce to get the `InstanceName` of the target org.\n- **Salesforce Status API Integration:** It makes an HTTP GET request to the Salesforce Status API (`https://api.status.salesforce.com/v1/instances/{instanceName}/status`) to retrieve detailed information about the instance, including scheduled maintenances.\n- **Data Parsing:** It parses the JSON response from the Status API to extract the relevant major release upgrade information.\n- **Date Calculation:** Uses the `moment` library to calculate the difference in days between the current date and the planned upgrade date.\n- **Notification Integration:** It integrates with the `NotifProvider` to send notifications, including the instance name, upgrade date, and days remaining, along with relevant metrics for monitoring dashboards.\n- **User Feedback:** Provides clear messages to the user about the upgrade status and proximity.\n</details>\n",
       "examples": [
         "$ sf hardis:org:diagnose:instanceupgrade"
       ],
@@ -6128,7 +6128,7 @@
     "hardis:org:diagnose:licenses": {
       "aliases": [],
       "args": {},
-      "description": "\n**Lists and analyzes User Licenses and Permission Set Licenses subscribed and used in a Salesforce org.**\n\nThis command provides a comprehensive overview of your Salesforce license consumption. It's particularly useful for:\n\n- **License Management:** Understanding which licenses are active, how many are available, and how many are being used.\n- **Cost Optimization:** Identifying unused or underutilized licenses that could be reallocated or decommissioned.\n- **Compliance:** Ensuring that your organization is compliant with Salesforce licensing agreements.\n- **Monitoring:** Tracking license usage trends over time.\n\nKey functionalities:\n\n- **User License Details:** Retrieves information about standard and custom User Licenses, including `MasterLabel`, `Name`, `TotalLicenses`, and `UsedLicenses`.\n- **Permission Set License Details:** Retrieves information about Permission Set Licenses, including `MasterLabel`, `PermissionSetLicenseKey`, `TotalLicenses`, and `UsedLicenses`.\n- **Used Licenses Filter:** The `--usedonly` flag allows you to filter the report to show only licenses that have at least one `UsedLicenses` count greater than zero.\n- **CSV Report Generation:** Generates a CSV file containing all the retrieved license information, suitable for detailed analysis.\n- **Notifications:** Sends notifications to configured channels (e.g., Grafana, Slack, MS Teams) with a summary of license usage, including lists of active and used licenses.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Salesforce SOQL Queries:** It executes SOQL queries against the `UserLicense` and `PermissionSetLicense` objects in Salesforce to retrieve license data.\n- **Data Transformation:** It processes the query results, reformatting the data to be more readable and consistent for reporting purposes (e.g., removing `Id` and `attributes`, renaming `PermissionSetLicenseKey` to `Name`).\n- **Data Aggregation:** It aggregates license information, creating a `licensesByKey` object for quick lookups and a `usedLicenses` array for a concise list of actively used licenses.\n- **Report Generation:** It uses `generateCsvFile` to create the CSV report of license data.\n- **Notification Integration:** It integrates with the `NotifProvider` to send notifications, including attachments of the generated CSV report and metrics for monitoring dashboards.\n- **User Feedback:** Provides clear messages to the user about the license extraction process and the used licenses.\n",
+      "description": "\n**Lists and analyzes User Licenses and Permission Set Licenses subscribed and used in a Salesforce org.**\n\nThis command provides a comprehensive overview of your Salesforce license consumption. It's particularly useful for:\n\n- **License Management:** Understanding which licenses are active, how many are available, and how many are being used.\n- **Cost Optimization:** Identifying unused or underutilized licenses that could be reallocated or decommissioned.\n- **Compliance:** Ensuring that your organization is compliant with Salesforce licensing agreements.\n- **Monitoring:** Tracking license usage trends over time.\n\nKey functionalities:\n\n- **User License Details:** Retrieves information about standard and custom User Licenses, including `MasterLabel`, `Name`, `TotalLicenses`, and `UsedLicenses`.\n- **Permission Set License Details:** Retrieves information about Permission Set Licenses, including `MasterLabel`, `PermissionSetLicenseKey`, `TotalLicenses`, and `UsedLicenses`.\n- **Used Licenses Filter:** The `--usedonly` flag allows you to filter the report to show only licenses that have at least one `UsedLicenses` count greater than zero.\n- **CSV Report Generation:** Generates a CSV file containing all the retrieved license information, suitable for detailed analysis.\n- **Notifications:** Sends notifications to configured channels (e.g., Grafana, Slack, MS Teams) with a summary of license usage, including lists of active and used licenses.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Salesforce SOQL Queries:** It executes SOQL queries against the `UserLicense` and `PermissionSetLicense` objects in Salesforce to retrieve license data.\n- **Data Transformation:** It processes the query results, reformatting the data to be more readable and consistent for reporting purposes (e.g., removing `Id` and `attributes`, renaming `PermissionSetLicenseKey` to `Name`).\n- **Data Aggregation:** It aggregates license information, creating a `licensesByKey` object for quick lookups and a `usedLicenses` array for a concise list of actively used licenses.\n- **Report Generation:** It uses `generateCsvFile` to create the CSV report of license data.\n- **Notification Integration:** It integrates with the `NotifProvider` to send notifications, including attachments of the generated CSV report and metrics for monitoring dashboards.\n- **User Feedback:** Provides clear messages to the user about the license extraction process and the used licenses.\n</details>\n",
       "examples": [
         "$ sf hardis:org:diagnose:licenses"
       ],
@@ -6486,7 +6486,7 @@
     "hardis:org:diagnose:unused-connected-apps": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Identifies and reports on potentially unused Connected Apps in a Salesforce org, suggesting candidates for deletion or deactivation.**\n\nThis command helps improve org security and reduce technical debt by pinpointing Connected Apps that are no longer actively used. Connected Apps can pose security risks if left unmonitored, and cleaning them up contributes to a healthier Salesforce environment.\n\nKey functionalities:\n\n- **Connected App Data Collection:** Gathers information about all Connected Apps in the org, including creation and last modified dates, and associated users.\n- **Usage Analysis:** Analyzes `LoginHistory` and `OAuthToken` records to determine the last usage date of each Connected App.\n- **Inactivity Detection:** Flags Connected Apps as potentially unused if they have no recent login history or OAuth token usage.\n- **Accessibility Check:** Examines Connected App metadata to identify if they are accessible (e.g., if they require admin approval and have no profiles or permission sets assigned).\n- **Ignored Apps:** Automatically ignores a predefined list of common Salesforce Connected Apps (e.g., `Salesforce CLI`, `Salesforce Mobile Dashboards`). You can extend this list by defining the `ALLOWED_INACTIVE_CONNECTED_APPS` environment variable.\n- **CSV Report Generation:** Generates a CSV file containing details of all analyzed Connected Apps, including their usage status, last usage date, and reasons for being flagged as potentially unused.\n- **Notifications:** Sends notifications to configured channels (Grafana, Slack, MS Teams) with a summary of potentially unused Connected Apps.\n\n**Default Ignored Connected Apps:**\n\n- Ant Migration Tool\n- Chatter Desktop\n- Chatter Mobile for BlackBerry\n- Force.com IDE\n- OIQ_Integration\n- Salesforce CLI\n- Salesforce Files\n- Salesforce Mobile Dashboards\n- Salesforce Touch\n- Salesforce for Outlook\n- SalesforceA\n- SalesforceA for Android\n- SalesforceA for iOS\n- SalesforceDX Namespace Registry\n- SalesforceIQ\n\nYou can add more ignored apps by defining a comma-separated list of names in the `ALLOWED_INACTIVE_CONNECTED_APPS` environment variable.\n\n_Example: \nALLOWED_INACTIVE_CONNECTED_APPS=My App 1,My App 2, My App 3_\n\nThis command is part of [sfdx-hardis Monitoring](https://sfdx-hardis.cloudity.com/salesforce-monitoring-unused-connected-apps/) and can output Grafana, Slack and MsTeams Notifications.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Salesforce SOQL Queries:** It performs SOQL queries against `ConnectedApplication`, `LoginHistory`, and `OAuthToken` objects to gather comprehensive data about Connected Apps and their usage.\n- **Temporary SFDX Project:** It creates a temporary SFDX project to retrieve Connected App metadata, allowing for local parsing and analysis of their XML files.\n- **Metadata Parsing:** It parses the `connectedApp-meta.xml` files to check for `isAdminApproved` and the presence of `profileName` or `permissionsetName` to determine accessibility.\n- **Data Correlation:** It correlates data from various Salesforce objects to build a complete picture of each Connected App's usage and status.\n- **Date Calculation:** Uses `moment` to calculate the time since the last OAuth token usage.\n- **Report Generation:** It uses `generateCsvFile` to create the CSV report of unused Connected Apps.\n- **Notification Integration:** It integrates with the `NotifProvider` to send notifications, including attachments of the generated CSV report and metrics for monitoring dashboards.\n- **File System Operations:** Uses `fs-extra` for creating and removing temporary directories and files.\n- **Environment Variable Reading:** Reads the `ALLOWED_INACTIVE_CONNECTED_APPS` environment variable to customize the list of ignored Connected Apps.\n",
+      "description": "\n## Command Behavior\n\n**Identifies and reports on potentially unused Connected Apps in a Salesforce org, suggesting candidates for deletion or deactivation.**\n\nThis command helps improve org security and reduce technical debt by pinpointing Connected Apps that are no longer actively used. Connected Apps can pose security risks if left unmonitored, and cleaning them up contributes to a healthier Salesforce environment.\n\nKey functionalities:\n\n- **Connected App Data Collection:** Gathers information about all Connected Apps in the org, including creation and last modified dates, and associated users.\n- **Usage Analysis:** Analyzes `LoginHistory` and `OAuthToken` records to determine the last usage date of each Connected App.\n- **Inactivity Detection:** Flags Connected Apps as potentially unused if they have no recent login history or OAuth token usage.\n- **Accessibility Check:** Examines Connected App metadata to identify if they are accessible (e.g., if they require admin approval and have no profiles or permission sets assigned).\n- **Ignored Apps:** Automatically ignores a predefined list of common Salesforce Connected Apps (e.g., `Salesforce CLI`, `Salesforce Mobile Dashboards`). You can extend this list by defining the `ALLOWED_INACTIVE_CONNECTED_APPS` environment variable.\n- **CSV Report Generation:** Generates a CSV file containing details of all analyzed Connected Apps, including their usage status, last usage date, and reasons for being flagged as potentially unused.\n- **Notifications:** Sends notifications to configured channels (Grafana, Slack, MS Teams) with a summary of potentially unused Connected Apps.\n\n**Default Ignored Connected Apps:**\n\n- Ant Migration Tool\n- Chatter Desktop\n- Chatter Mobile for BlackBerry\n- Force.com IDE\n- OIQ_Integration\n- Salesforce CLI\n- Salesforce Files\n- Salesforce Mobile Dashboards\n- Salesforce Touch\n- Salesforce for Outlook\n- SalesforceA\n- SalesforceA for Android\n- SalesforceA for iOS\n- SalesforceDX Namespace Registry\n- SalesforceIQ\n\nYou can add more ignored apps by defining a comma-separated list of names in the `ALLOWED_INACTIVE_CONNECTED_APPS` environment variable.\n\n_Example: \nALLOWED_INACTIVE_CONNECTED_APPS=My App 1,My App 2, My App 3_\n\nThis command is part of [sfdx-hardis Monitoring](https://sfdx-hardis.cloudity.com/salesforce-monitoring-unused-connected-apps/) and can output Grafana, Slack and MsTeams Notifications.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Salesforce SOQL Queries:** It performs SOQL queries against `ConnectedApplication`, `LoginHistory`, and `OAuthToken` objects to gather comprehensive data about Connected Apps and their usage.\n- **Temporary SFDX Project:** It creates a temporary SFDX project to retrieve Connected App metadata, allowing for local parsing and analysis of their XML files.\n- **Metadata Parsing:** It parses the `connectedApp-meta.xml` files to check for `isAdminApproved` and the presence of `profileName` or `permissionsetName` to determine accessibility.\n- **Data Correlation:** It correlates data from various Salesforce objects to build a complete picture of each Connected App's usage and status.\n- **Date Calculation:** Uses `moment` to calculate the time since the last OAuth token usage.\n- **Report Generation:** It uses `generateCsvFile` to create the CSV report of unused Connected Apps.\n- **Notification Integration:** It integrates with the `NotifProvider` to send notifications, including attachments of the generated CSV report and metrics for monitoring dashboards.\n- **File System Operations:** Uses `fs-extra` for creating and removing temporary directories and files.\n- **Environment Variable Reading:** Reads the `ALLOWED_INACTIVE_CONNECTED_APPS` environment variable to customize the list of ignored Connected Apps.\n</details>\n",
       "examples": [
         "$ sf hardis:org:diagnose:unused-connected-apps"
       ],
@@ -6617,7 +6617,7 @@
     "hardis:org:diagnose:unusedlicenses": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Detects and suggests the deletion of unused Permission Set License Assignments in a Salesforce org.**\n\nWhen a Permission Set (PS) linked to a Permission Set License (PSL) is assigned to a user, a Permission Set License Assignment (PSLA) is automatically created. However, when that PS is unassigned from the user, the PSLA is *not* automatically deleted. This can lead to organizations being charged for unused PSLAs, representing a hidden cost and technical debt.\n\nThis command identifies such useless PSLAs and provides options to delete them, helping to optimize license usage and reduce unnecessary expenses.\n\nKey functionalities:\n\n- **PSLA Detection:** Queries the Salesforce org to find all active PSLAs.\n- **Usage Verification:** Correlates PSLAs with actual Permission Set Assignments and Permission Set Group Assignments to determine if the underlying Permission Sets are still assigned to the user.\n- **Special Case Handling:** Accounts for specific scenarios where profiles might implicitly assign PSLAs (e.g., `Salesforce API Only` profile assigning `SalesforceAPIIntegrationPsl`) and allows for always excluding certain PSLAs from the unused check.\n- **Reporting:** Generates a CSV report of all identified unused PSLAs, including the user and the associated Permission Set License.\n- **Notifications:** Sends notifications to configured channels (Grafana, Slack, MS Teams) with a summary of unused PSLAs.\n- **Interactive Deletion:** In non-CI environments, it offers an interactive prompt to bulk delete the identified unused PSLAs.\n\nMany thanks to [Vincent Finet](https://www.linkedin.com/in/vincentfinet/) for the inspiration during his great speaker session at [French Touch Dreamin '23](https://frenchtouchdreamin.com/), and his kind agreement for reusing such inspiration in this command :)\n\nThis command is part of [sfdx-hardis Monitoring](https://sfdx-hardis.cloudity.com/salesforce-monitoring-unused-licenses/) and can output Grafana, Slack and MsTeams Notifications.\n\n## Technical explanations\n\nThe command's technical implementation involves extensive querying of Salesforce objects and data correlation:\n\n- **SOQL Queries (Bulk API):** It uses `bulkQuery` and `bulkQueryChunksIn` to efficiently retrieve large volumes of data from `PermissionSetLicenseAssign`, `PermissionSetLicense`, `PermissionSet`, `PermissionSetGroupComponent`, and `PermissionSetAssignment` objects.\n- **Data Correlation:** It meticulously correlates data across these objects to determine if a `PermissionSetLicenseAssign` record has a corresponding active assignment to a Permission Set or Permission Set Group for the same user.\n- **Filtering Logic:** It applies complex filtering logic to exclude PSLAs that are genuinely in use or are part of predefined exceptions (e.g., `alwaysExcludeForActiveUsersPermissionSetLicenses`).\n- **Bulk Deletion:** If the user opts to delete unused PSLAs, it uses `bulkUpdate` with the `delete` operation to efficiently remove multiple records.\n- **Report Generation:** It uses `generateCsvFile` to create the CSV report of unused PSLAs.\n- **Notification Integration:** It integrates with the `NotifProvider` to send notifications, including attachments of the generated CSV report and metrics for monitoring dashboards.\n- **User Interaction:** Uses `prompts` for interactive confirmation before performing deletion operations.\n",
+      "description": "\n## Command Behavior\n\n**Detects and suggests the deletion of unused Permission Set License Assignments in a Salesforce org.**\n\nWhen a Permission Set (PS) linked to a Permission Set License (PSL) is assigned to a user, a Permission Set License Assignment (PSLA) is automatically created. However, when that PS is unassigned from the user, the PSLA is *not* automatically deleted. This can lead to organizations being charged for unused PSLAs, representing a hidden cost and technical debt.\n\nThis command identifies such useless PSLAs and provides options to delete them, helping to optimize license usage and reduce unnecessary expenses.\n\nKey functionalities:\n\n- **PSLA Detection:** Queries the Salesforce org to find all active PSLAs.\n- **Usage Verification:** Correlates PSLAs with actual Permission Set Assignments and Permission Set Group Assignments to determine if the underlying Permission Sets are still assigned to the user.\n- **Special Case Handling:** Accounts for specific scenarios where profiles might implicitly assign PSLAs (e.g., `Salesforce API Only` profile assigning `SalesforceAPIIntegrationPsl`) and allows for always excluding certain PSLAs from the unused check.\n- **Reporting:** Generates a CSV report of all identified unused PSLAs, including the user and the associated Permission Set License.\n- **Notifications:** Sends notifications to configured channels (Grafana, Slack, MS Teams) with a summary of unused PSLAs.\n- **Interactive Deletion:** In non-CI environments, it offers an interactive prompt to bulk delete the identified unused PSLAs.\n\nMany thanks to [Vincent Finet](https://www.linkedin.com/in/vincentfinet/) for the inspiration during his great speaker session at [French Touch Dreamin '23](https://frenchtouchdreamin.com/), and his kind agreement for reusing such inspiration in this command :)\n\nThis command is part of [sfdx-hardis Monitoring](https://sfdx-hardis.cloudity.com/salesforce-monitoring-unused-licenses/) and can output Grafana, Slack and MsTeams Notifications.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves extensive querying of Salesforce objects and data correlation:\n\n- **SOQL Queries (Bulk API):** It uses `bulkQuery` and `bulkQueryChunksIn` to efficiently retrieve large volumes of data from `PermissionSetLicenseAssign`, `PermissionSetLicense`, `PermissionSet`, `PermissionSetGroupComponent`, and `PermissionSetAssignment` objects.\n- **Data Correlation:** It meticulously correlates data across these objects to determine if a `PermissionSetLicenseAssign` record has a corresponding active assignment to a Permission Set or Permission Set Group for the same user.\n- **Filtering Logic:** It applies complex filtering logic to exclude PSLAs that are genuinely in use or are part of predefined exceptions (e.g., `alwaysExcludeForActiveUsersPermissionSetLicenses`).\n- **Bulk Deletion:** If the user opts to delete unused PSLAs, it uses `bulkUpdate` with the `delete` operation to efficiently remove multiple records.\n- **Report Generation:** It uses `generateCsvFile` to create the CSV report of unused PSLAs.\n- **Notification Integration:** It integrates with the `NotifProvider` to send notifications, including attachments of the generated CSV report and metrics for monitoring dashboards.\n- **User Interaction:** Uses `prompts` for interactive confirmation before performing deletion operations.\n</details>\n",
       "examples": [
         "$ sf hardis:org:diagnose:unusedlicenses",
         "$ sf hardis:org:diagnose:unusedlicenses --fix"
@@ -6750,7 +6750,7 @@
     "hardis:org:diagnose:unusedusers": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Detects and reports on inactive or unused Salesforce user accounts, helping to optimize license usage and enhance security.**\n\nEfficient user management is vital in Salesforce to ensure resources are optimized and costs are controlled. However, inactive or unused user accounts can often go unnoticed, leading to wasted licenses and potential security risks. This tool addresses this challenge by enabling administrators to identify users who haven't logged in within a specified period.\n\nBy analyzing user login activity and last login timestamps, this feature highlights inactive user accounts, allowing administrators to take appropriate action. Whether it's deactivating dormant accounts, freeing up licenses, or ensuring compliance with security policies, this functionality empowers administrators to maintain a lean and secure Salesforce environment.\n\nKey functionalities:\n\n- **Inactivity Detection:** Identifies users who have not logged in for a specified number of days (`--days` flag, default 180 days in CI, 365 days otherwise).\n- **License Type Filtering:** Allows filtering users by license type using `--licensetypes` (e.g., `all-crm`, `all-paying`) or specific license identifiers using `--licenseidentifiers`.\n  - `all-crm`: Includes `SFDC`, `AUL`, `AUL1`, `AULL_IGHT` licenses.\n  - `all-paying`: Includes `SFDC`, `AUL`, `AUL1`, `AULL_IGHT`, `PID_Customer_Community`, `PID_Customer_Community_Login`, `PID_Partner_Community`, `PID_Partner_Community_Login` licenses.\n  - Note: You can see the full list of available license identifiers in [Salesforce Documentation](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/sfdx_cli_reference/sforce_api_objects_userlicense.htm).\n- **Active User Retrieval:** The `--returnactiveusers` flag inverts the command, allowing you to retrieve active users who *have* logged in during the specified period.\n- **CSV Report Generation:** Generates a CSV file containing details of all identified users (inactive or active), including their last login date, profile, and license information.\n- **Notifications:** Sends notifications to configured channels (Grafana, Slack, MS Teams) with a summary of inactive or active users.\n\nThis command is part of [sfdx-hardis Monitoring](https://sfdx-hardis.cloudity.com/salesforce-monitoring-inactive-users/) and can output Grafana, Slack and MsTeams Notifications.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **SOQL Query (Bulk API):** It uses `bulkQuery` to efficiently retrieve user records from the Salesforce `User` object. The SOQL query dynamically constructs its WHERE clause based on the `--days`, `--licensetypes`, `--licenseidentifiers`, and `--returnactiveusers` flags.\n- **Interactive Prompts:** Uses `prompts` to interactively ask the user for the number of inactive days and license types if not provided via flags.\n- **License Mapping:** Internally maps common license type aliases (e.g., `all-crm`) to their corresponding Salesforce `LicenseDefinitionKey` values.\n- **Report Generation:** It uses `generateCsvFile` to create the CSV report of users.\n- **Notification Integration:** It integrates with the `NotifProvider` to send notifications, including attachments of the generated CSV report and metrics for monitoring dashboards.\n- **User Feedback:** Provides a summary of the findings in the console, indicating the number of inactive or active users found.\n",
+      "description": "\n## Command Behavior\n\n**Detects and reports on inactive or unused Salesforce user accounts, helping to optimize license usage and enhance security.**\n\nEfficient user management is vital in Salesforce to ensure resources are optimized and costs are controlled. However, inactive or unused user accounts can often go unnoticed, leading to wasted licenses and potential security risks. This tool addresses this challenge by enabling administrators to identify users who haven't logged in within a specified period.\n\nBy analyzing user login activity and last login timestamps, this feature highlights inactive user accounts, allowing administrators to take appropriate action. Whether it's deactivating dormant accounts, freeing up licenses, or ensuring compliance with security policies, this functionality empowers administrators to maintain a lean and secure Salesforce environment.\n\nKey functionalities:\n\n- **Inactivity Detection:** Identifies users who have not logged in for a specified number of days (`--days` flag, default 180 days in CI, 365 days otherwise).\n- **License Type Filtering:** Allows filtering users by license type using `--licensetypes` (e.g., `all-crm`, `all-paying`) or specific license identifiers using `--licenseidentifiers`.\n  - `all-crm`: Includes `SFDC`, `AUL`, `AUL1`, `AULL_IGHT` licenses.\n  - `all-paying`: Includes `SFDC`, `AUL`, `AUL1`, `AULL_IGHT`, `PID_Customer_Community`, `PID_Customer_Community_Login`, `PID_Partner_Community`, `PID_Partner_Community_Login` licenses.\n  - Note: You can see the full list of available license identifiers in [Salesforce Documentation](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/sfdx_cli_reference/sforce_api_objects_userlicense.htm).\n- **Active User Retrieval:** The `--returnactiveusers` flag inverts the command, allowing you to retrieve active users who *have* logged in during the specified period.\n- **CSV Report Generation:** Generates a CSV file containing details of all identified users (inactive or active), including their last login date, profile, and license information.\n- **Notifications:** Sends notifications to configured channels (Grafana, Slack, MS Teams) with a summary of inactive or active users.\n\nThis command is part of [sfdx-hardis Monitoring](https://sfdx-hardis.cloudity.com/salesforce-monitoring-inactive-users/) and can output Grafana, Slack and MsTeams Notifications.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **SOQL Query (Bulk API):** It uses `bulkQuery` to efficiently retrieve user records from the Salesforce `User` object. The SOQL query dynamically constructs its WHERE clause based on the `--days`, `--licensetypes`, `--licenseidentifiers`, and `--returnactiveusers` flags.\n- **Interactive Prompts:** Uses `prompts` to interactively ask the user for the number of inactive days and license types if not provided via flags.\n- **License Mapping:** Internally maps common license type aliases (e.g., `all-crm`) to their corresponding Salesforce `LicenseDefinitionKey` values.\n- **Report Generation:** It uses `generateCsvFile` to create the CSV report of users.\n- **Notification Integration:** It integrates with the `NotifProvider` to send notifications, including attachments of the generated CSV report and metrics for monitoring dashboards.\n- **User Feedback:** Provides a summary of the findings in the console, indicating the number of inactive or active users found.\n</details>",
       "examples": [
         "$ sf hardis:org:diagnose:unusedusers",
         "$ sf hardis:org:diagnose:unusedusers --days 365",
@@ -7018,7 +7018,7 @@
     "hardis:org:generate:packagexmlfull": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Generates a comprehensive `package.xml` file for a Salesforce org, including all metadata components, even managed ones.**\n\nThis command is essential for various Salesforce development and administration tasks, especially when you need a complete snapshot of an org's metadata. It goes beyond typical source tracking by including managed package components, which is crucial for understanding the full metadata footprint of an org.\n\nKey functionalities:\n\n- **Full Org Metadata Retrieval:** Connects to a specified Salesforce org (or prompts for one if not provided) and retrieves a complete list of all metadata types and their members.\n- **Managed Package Inclusion:** Unlike standard source retrieval, this command explicitly includes metadata from managed packages, providing a truly comprehensive `package.xml`.\n- **Customizable Output:** Allows you to specify the output file path for the generated `package.xml`.\n- **Interactive Org Selection:** If no target org is specified, it interactively prompts the user to choose an org. (or use --no-prompt to skip this step)\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Salesforce Metadata API Interaction:** It leverages the Salesforce Metadata API to list all available metadata types and then retrieve all components for each type.\n- **`buildOrgManifest` Utility:** The core logic for querying the org's metadata and constructing the `package.xml` is encapsulated within the `buildOrgManifest` utility function.\n- **XML Generation:** It dynamically builds the XML structure of the `package.xml` file, including the `types` and `members` elements for all retrieved metadata.\n- **File System Operations:** It writes the generated `package.xml` file to the specified output path.\n- **Interactive Prompts:** Uses `promptOrgUsernameDefault` to guide the user in selecting the target Salesforce org.\n",
+      "description": "\n## Command Behavior\n\n**Generates a comprehensive `package.xml` file for a Salesforce org, including all metadata components, even managed ones.**\n\nThis command is essential for various Salesforce development and administration tasks, especially when you need a complete snapshot of an org's metadata. It goes beyond typical source tracking by including managed package components, which is crucial for understanding the full metadata footprint of an org.\n\nKey functionalities:\n\n- **Full Org Metadata Retrieval:** Connects to a specified Salesforce org (or prompts for one if not provided) and retrieves a complete list of all metadata types and their members.\n- **Managed Package Inclusion:** Unlike standard source retrieval, this command explicitly includes metadata from managed packages, providing a truly comprehensive `package.xml`.\n- **Customizable Output:** Allows you to specify the output file path for the generated `package.xml`.\n- **Interactive Org Selection:** If no target org is specified, it interactively prompts the user to choose an org. (or use --no-prompt to skip this step)\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Salesforce Metadata API Interaction:** It leverages the Salesforce Metadata API to list all available metadata types and then retrieve all components for each type.\n- **`buildOrgManifest` Utility:** The core logic for querying the org's metadata and constructing the `package.xml` is encapsulated within the `buildOrgManifest` utility function.\n- **XML Generation:** It dynamically builds the XML structure of the `package.xml` file, including the `types` and `members` elements for all retrieved metadata.\n- **File System Operations:** It writes the generated `package.xml` file to the specified output path.\n- **Interactive Prompts:** Uses `promptOrgUsernameDefault` to guide the user in selecting the target Salesforce org.\n</details>\n",
       "examples": [
         "$ sf hardis:org:generate:packagexmlfull",
         "$ sf hardis:org:generate:packagexmlfull --outputfile /tmp/packagexmlfull.xml",
@@ -7500,7 +7500,7 @@
     "hardis:org:monitor:limits": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Checks the current usage of various Salesforce org limits and sends notifications if thresholds are exceeded.**\n\nThis command is a critical component of proactive Salesforce org management, helping administrators and developers monitor resource consumption and prevent hitting critical limits that could impact performance or functionality. It provides early warnings when limits are approaching their capacity.\n\nKey functionalities:\n\n- **Limit Retrieval:** Fetches a comprehensive list of all Salesforce org limits using the Salesforce CLI.\n- **Usage Calculation:** Calculates the percentage of each limit that is currently being used.\n- **Threshold-Based Alerting:** Assigns a severity (success, warning, or error) to each limit based on configurable thresholds:\n  - **Warning:** If usage exceeds 50% (configurable via `LIMIT_THRESHOLD_WARNING` environment variable).\n  - **Error:** If usage exceeds 75% (configurable via `LIMIT_THRESHOLD_ERROR` environment variable).\n- **CSV Report Generation:** Generates a CSV file containing all org limits, their current usage, maximum allowed, and calculated percentage used, along with the assigned severity.\n- **Notifications:** Sends notifications to configured channels (Grafana, Slack, MS Teams) with a summary of limits that have exceeded the warning or error thresholds.\n\nThis command is part of [sfdx-hardis Monitoring](https://sfdx-hardis.cloudity.com/salesforce-monitoring-org-limits/) and can output Grafana, Slack and MsTeams Notifications.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Salesforce CLI Integration:** It executes the `sf org limits list` command to retrieve the current org limits. It parses the JSON output of this command.\n- **Data Processing:** It iterates through the retrieved limits, calculates the `used` and `percentUsed` values, and assigns a `severity` (success, warning, error) based on the configured thresholds.\n- **Environment Variable Configuration:** Reads `LIMIT_THRESHOLD_WARNING` and `LIMIT_THRESHOLD_ERROR` environment variables to set the warning and error thresholds for limit usage.\n- **Report Generation:** It uses `generateCsvFile` to create the CSV report of org limits.\n- **Notification Integration:** It integrates with the `NotifProvider` to send notifications, including attachments of the generated CSV report and detailed metrics for each limit, which can be consumed by monitoring dashboards like Grafana.\n- **Exit Code Management:** Sets the process exit code to 1 if any limit is in an 'error' state, indicating a critical issue.\n",
+      "description": "\n## Command Behavior\n\n**Checks the current usage of various Salesforce org limits and sends notifications if thresholds are exceeded.**\n\nThis command is a critical component of proactive Salesforce org management, helping administrators and developers monitor resource consumption and prevent hitting critical limits that could impact performance or functionality. It provides early warnings when limits are approaching their capacity.\n\nKey functionalities:\n\n- **Limit Retrieval:** Fetches a comprehensive list of all Salesforce org limits using the Salesforce CLI.\n- **Usage Calculation:** Calculates the percentage of each limit that is currently being used.\n- **Threshold-Based Alerting:** Assigns a severity (success, warning, or error) to each limit based on configurable thresholds:\n  - **Warning:** If usage exceeds 50% (configurable via `LIMIT_THRESHOLD_WARNING` environment variable).\n  - **Error:** If usage exceeds 75% (configurable via `LIMIT_THRESHOLD_ERROR` environment variable).\n- **CSV Report Generation:** Generates a CSV file containing all org limits, their current usage, maximum allowed, and calculated percentage used, along with the assigned severity.\n- **Notifications:** Sends notifications to configured channels (Grafana, Slack, MS Teams) with a summary of limits that have exceeded the warning or error thresholds.\n\nThis command is part of [sfdx-hardis Monitoring](https://sfdx-hardis.cloudity.com/salesforce-monitoring-org-limits/) and can output Grafana, Slack and MsTeams Notifications.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Salesforce CLI Integration:** It executes the `sf org limits list` command to retrieve the current org limits. It parses the JSON output of this command.\n- **Data Processing:** It iterates through the retrieved limits, calculates the `used` and `percentUsed` values, and assigns a `severity` (success, warning, error) based on the configured thresholds.\n- **Environment Variable Configuration:** Reads `LIMIT_THRESHOLD_WARNING` and `LIMIT_THRESHOLD_ERROR` environment variables to set the warning and error thresholds for limit usage.\n- **Report Generation:** It uses `generateCsvFile` to create the CSV report of org limits.\n- **Notification Integration:** It integrates with the `NotifProvider` to send notifications, including attachments of the generated CSV report and detailed metrics for each limit, which can be consumed by monitoring dashboards like Grafana.\n- **Exit Code Management:** Sets the process exit code to 1 if any limit is in an 'error' state, indicating a critical issue.\n</details>\n",
       "examples": [
         "$ sf hardis:org:monitor:limits"
       ],
@@ -7615,7 +7615,7 @@
     "hardis:org:purge:apexlog": {
       "aliases": [],
       "args": {},
-      "description": "\n**Purges Apex debug logs from a Salesforce org.**\n\nThis command provides a quick and efficient way to clear out accumulated Apex debug logs from your Salesforce environment. This is particularly useful for:\n\n- **Storage Management:** Freeing up valuable data storage space in your Salesforce org.\n- **Performance Optimization:** Reducing the overhead associated with large volumes of debug logs.\n- **Troubleshooting:** Ensuring that new debug logs are generated cleanly without interference from old, irrelevant logs.\n\nKey functionalities:\n\n- **Log Identification:** Queries the `ApexLog` object to identify all existing debug logs.\n- **Confirmation Prompt:** Before deletion, it prompts for user confirmation, displaying the number of Apex logs that will be deleted.\n- **Bulk Deletion:** Uses the Salesforce Bulk API to efficiently delete a large number of Apex logs.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **SOQL Query:** It executes a SOQL query (`SELECT Id FROM ApexLog LIMIT 50000`) to retrieve the IDs of Apex logs to be deleted. The limit is set to 50,000 to handle large volumes of logs.\n- **CSV Export:** The retrieved log IDs are temporarily exported to a CSV file (`ApexLogsToDelete_*.csv`) in the `./tmp` directory.\n- **User Confirmation:** It uses the `prompts` library to ask for user confirmation before proceeding with the deletion, displaying the count of logs to be purged.\n- **Bulk API Deletion:** It then uses the Salesforce CLI's `sf data delete bulk` command, pointing to the generated CSV file, to perform the mass deletion of Apex logs.\n- **File System Operations:** It uses `fs-extra` to create the temporary directory and manage the CSV file.\n- **Error Handling:** Includes error handling for the query and deletion operations.\n",
+      "description": "\n**Purges Apex debug logs from a Salesforce org.**\n\nThis command provides a quick and efficient way to clear out accumulated Apex debug logs from your Salesforce environment. This is particularly useful for:\n\n- **Storage Management:** Freeing up valuable data storage space in your Salesforce org.\n- **Performance Optimization:** Reducing the overhead associated with large volumes of debug logs.\n- **Troubleshooting:** Ensuring that new debug logs are generated cleanly without interference from old, irrelevant logs.\n\nKey functionalities:\n\n- **Log Identification:** Queries the `ApexLog` object to identify all existing debug logs.\n- **Confirmation Prompt:** Before deletion, it prompts for user confirmation, displaying the number of Apex logs that will be deleted.\n- **Bulk Deletion:** Uses the Salesforce Bulk API to efficiently delete a large number of Apex logs.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **SOQL Query:** It executes a SOQL query (`SELECT Id FROM ApexLog LIMIT 50000`) to retrieve the IDs of Apex logs to be deleted. The limit is set to 50,000 to handle large volumes of logs.\n- **CSV Export:** The retrieved log IDs are temporarily exported to a CSV file (`ApexLogsToDelete_*.csv`) in the `./tmp` directory.\n- **User Confirmation:** It uses the `prompts` library to ask for user confirmation before proceeding with the deletion, displaying the count of logs to be purged.\n- **Bulk API Deletion:** It then uses the Salesforce CLI's `sf data delete bulk` command, pointing to the generated CSV file, to perform the mass deletion of Apex logs.\n- **File System Operations:** It uses `fs-extra` to create the temporary directory and manage the CSV file.\n- **Error Handling:** Includes error handling for the query and deletion operations.\n</details>\n",
       "examples": [
         "$ sf hardis:org:purge:apexlog",
         "$ sf hardis:org:purge:apexlog --target-org nicolas.vuillamy@gmail.com"
@@ -7729,7 +7729,7 @@
     "hardis:org:purge:flow": {
       "aliases": [],
       "args": {},
-      "description": "\n**Purges old or unwanted Flow versions from a Salesforce org, with an option to delete related Flow Interviews.**\n\nThis command helps maintain a clean and performant Salesforce org by removing obsolete Flow versions. Over time, multiple versions of Flows can accumulate, consuming storage and potentially impacting performance. This tool provides a controlled way to clean up these versions.\n\nKey functionalities:\n\n- **Targeted Flow Selection:** Allows you to filter Flow versions to delete by name (`--name`) and status (`--status`, e.g., `Obsolete`, `Draft`, `Inactive`).\n- **Flow Interview Deletion:** If a Flow version cannot be deleted due to active Flow Interviews, the `--delete-flow-interviews` flag (or interactive prompt) allows you to delete these interviews first, then retry the Flow version deletion.\n- **Confirmation Prompt:** In interactive mode, it prompts for confirmation before proceeding with the deletion of Flow versions and Flow Interviews.\n- **Partial Success Handling:** The `--allowpurgefailure` flag (default `true`) allows the command to continue even if some deletions fail, reporting the errors.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **SOQL Queries (Tooling API):** It queries the `Flow` object (using the Tooling API) to list Flow versions based on the provided filters (name, status, manageable state).\n- **Bulk Deletion (Tooling API):** It uses `bulkDeleteTooling` to perform mass deletions of Flow versions. If deletion fails due to active interviews, it extracts the interview IDs.\n- **Flow Interview Management:** If `delete-flow-interviews` is enabled, it queries `FlowInterview` objects, performs bulk deletion of the identified interviews using `bulkDelete`, and then retries the Flow version deletion.\n- **Interactive Prompts:** Uses the `prompts` library to interact with the user for selecting Flows, statuses, and confirming deletion actions.\n- **Error Reporting:** Logs detailed error messages for failed deletions, including the specific reasons.\n- **Command-Line Execution:** Uses `execSfdxJson` to execute Salesforce CLI commands for querying Flow data.\n",
+      "description": "\n**Purges old or unwanted Flow versions from a Salesforce org, with an option to delete related Flow Interviews.**\n\nThis command helps maintain a clean and performant Salesforce org by removing obsolete Flow versions. Over time, multiple versions of Flows can accumulate, consuming storage and potentially impacting performance. This tool provides a controlled way to clean up these versions.\n\nKey functionalities:\n\n- **Targeted Flow Selection:** Allows you to filter Flow versions to delete by name (`--name`) and status (`--status`, e.g., `Obsolete`, `Draft`, `Inactive`).\n- **Flow Interview Deletion:** If a Flow version cannot be deleted due to active Flow Interviews, the `--delete-flow-interviews` flag (or interactive prompt) allows you to delete these interviews first, then retry the Flow version deletion.\n- **Confirmation Prompt:** In interactive mode, it prompts for confirmation before proceeding with the deletion of Flow versions and Flow Interviews.\n- **Partial Success Handling:** The `--allowpurgefailure` flag (default `true`) allows the command to continue even if some deletions fail, reporting the errors.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **SOQL Queries (Tooling API):** It queries the `Flow` object (using the Tooling API) to list Flow versions based on the provided filters (name, status, manageable state).\n- **Bulk Deletion (Tooling API):** It uses `bulkDeleteTooling` to perform mass deletions of Flow versions. If deletion fails due to active interviews, it extracts the interview IDs.\n- **Flow Interview Management:** If `delete-flow-interviews` is enabled, it queries `FlowInterview` objects, performs bulk deletion of the identified interviews using `bulkDelete`, and then retries the Flow version deletion.\n- **Interactive Prompts:** Uses the `prompts` library to interact with the user for selecting Flows, statuses, and confirming deletion actions.\n- **Error Reporting:** Logs detailed error messages for failed deletions, including the specific reasons.\n- **Command-Line Execution:** Uses `execSfdxJson` to execute Salesforce CLI commands for querying Flow data.\n</details>\n",
       "examples": [
         "$ sf hardis:org:purge:flow",
         "$ sf hardis:org:purge:flow --target-org nicolas.vuillamy@gmail.com --no-prompt --delete-flow-interviews",
@@ -7880,10 +7880,249 @@
         "flow:purge:org:hardis"
       ]
     },
+    "hardis:org:refresh:after-refresh": {
+      "aliases": [],
+      "args": {},
+      "description": "\n## Command Behavior\n\n**Restores all previously backed-up Connected Apps (including Consumer Secrets) to a Salesforce org after a sandbox refresh.**\n\nThis command is the second step in the sandbox refresh process. It scans the backup folder created before the refresh, allows selection of which Connected Apps to restore, and automates their deletion and redeployment to the refreshed org, ensuring all credentials and configuration are preserved.\n\nKey functionalities:\n\n- **Backup Folder Selection:** Prompts the user to select the correct backup folder for the sandbox instance.\n- **Connected App Discovery:** Scans the backup for all Connected App metadata files.\n- **User Selection:** Allows interactive or flag-based selection of which Connected Apps to restore.\n- **Validation:** Ensures all selected apps exist in the backup and validates user input.\n- **Org Cleanup:** Deletes existing Connected Apps from the refreshed org to allow clean redeployment.\n- **Deployment:** Deploys the selected Connected Apps (with secrets) to the org.\n- **Summary and Reporting:** Provides a summary of restored apps and their status.\n\nThis command is part of [sfdx-hardis Sandbox Refresh](https://sfdx-hardis.cloudity.com/salesforce-sandbox-refresh/) and is designed to be run after a sandbox refresh, using the backup created by the before-refresh command.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\n- **Backup Folder Handling:** Prompts for and validates the backup folder under `scripts/sandbox-refresh/`.\n- **Metadata Scanning:** Uses glob patterns to find all `*.connectedApp - meta.xml` files in the backup.\n- **Selection Logic:** Supports `--all`, `--name`, and interactive selection of apps to restore.\n- **Validation:** Checks that all requested apps exist in the backup and provides clear errors if not.\n- **Org Operations:** Deletes existing Connected Apps from the org before redeployment to avoid conflicts.\n- **Deployment:** Uses utility functions to deploy Connected Apps and their secrets to the org.\n- **Error Handling:** Handles and reports errors at each step, including parsing and deployment issues.\n\n</details>\n",
+      "examples": [
+        "$ sf hardis:org:refresh:after-refresh",
+        "$ sf hardis:org:refresh:after-refresh --name \"MyConnectedApp\" // Process specific app, no selection prompt",
+        "$ sf hardis:org:refresh:after-refresh --name \"App1,App2,App3\" // Process multiple apps, no selection prompt",
+        "$ sf hardis:org:refresh:after-refresh --all // Process all apps, no selection prompt",
+        "$ sf hardis:org:refresh:after-refresh --target-org myDevOrg"
+      ],
+      "flags": {
+        "json": {
+          "description": "Format output as json.",
+          "helpGroup": "GLOBAL",
+          "name": "json",
+          "allowNo": false,
+          "type": "boolean"
+        },
+        "flags-dir": {
+          "helpGroup": "GLOBAL",
+          "name": "flags-dir",
+          "summary": "Import flag values from a directory.",
+          "hasDynamicHelp": false,
+          "multiple": false,
+          "type": "option"
+        },
+        "target-org": {
+          "char": "o",
+          "name": "target-org",
+          "noCacheDefault": true,
+          "required": true,
+          "summary": "Username or alias of the target org. Not required if the `target-org` configuration variable is already set.",
+          "hasDynamicHelp": true,
+          "multiple": false,
+          "type": "option"
+        },
+        "name": {
+          "char": "n",
+          "description": "Connected App name(s) to process (bypasses selection prompt). For multiple apps, separate with commas (e.g., \"App1,App2\")",
+          "name": "name",
+          "summary": "Filter according to Name criteria",
+          "hasDynamicHelp": false,
+          "multiple": false,
+          "type": "option"
+        },
+        "all": {
+          "char": "a",
+          "description": "If set, all Connected Apps from the local repository will be processed. Takes precedence over --name if both are specified.",
+          "name": "all",
+          "summary": "Process all Connected Apps without selection prompt",
+          "allowNo": false,
+          "type": "boolean"
+        },
+        "websocket": {
+          "description": "Websocket host:port for VsCode SFDX Hardis UI integration",
+          "name": "websocket",
+          "summary": "Websocket host:port for VsCode SFDX Hardis UI integration",
+          "hasDynamicHelp": false,
+          "multiple": false,
+          "type": "option"
+        },
+        "skipauth": {
+          "description": "Skip authentication check when a default username is required",
+          "name": "skipauth",
+          "summary": "Skip authentication check when a default username is required",
+          "allowNo": false,
+          "type": "boolean"
+        }
+      },
+      "hasDynamicHelp": true,
+      "hiddenAliases": [],
+      "id": "hardis:org:refresh:after-refresh",
+      "pluginAlias": "sfdx-hardis",
+      "pluginName": "sfdx-hardis",
+      "pluginType": "core",
+      "strict": true,
+      "enableJsonFlag": true,
+      "title": "Restore Connected Apps after org refresh",
+      "requiresProject": true,
+      "isESM": true,
+      "relativePath": [
+        "lib",
+        "commands",
+        "hardis",
+        "org",
+        "refresh",
+        "after-refresh.js"
+      ],
+      "aliasPermutations": [],
+      "permutations": [
+        "hardis:org:refresh:after-refresh",
+        "org:hardis:refresh:after-refresh",
+        "org:refresh:hardis:after-refresh",
+        "org:refresh:after-refresh:hardis",
+        "hardis:refresh:org:after-refresh",
+        "refresh:hardis:org:after-refresh",
+        "refresh:org:hardis:after-refresh",
+        "refresh:org:after-refresh:hardis",
+        "hardis:refresh:after-refresh:org",
+        "refresh:hardis:after-refresh:org",
+        "refresh:after-refresh:hardis:org",
+        "refresh:after-refresh:org:hardis",
+        "hardis:org:after-refresh:refresh",
+        "org:hardis:after-refresh:refresh",
+        "org:after-refresh:hardis:refresh",
+        "org:after-refresh:refresh:hardis",
+        "hardis:after-refresh:org:refresh",
+        "after-refresh:hardis:org:refresh",
+        "after-refresh:org:hardis:refresh",
+        "after-refresh:org:refresh:hardis",
+        "hardis:after-refresh:refresh:org",
+        "after-refresh:hardis:refresh:org",
+        "after-refresh:refresh:hardis:org",
+        "after-refresh:refresh:org:hardis"
+      ]
+    },
+    "hardis:org:refresh:before-refresh": {
+      "aliases": [],
+      "args": {},
+      "description": "\n## Command Behavior\n\n**Backs up all Connected Apps, their secrets, certificates, and custom settings from a Salesforce org before a sandbox refresh, enabling full restoration after the refresh.**\n\nThis command is essential for Salesforce sandbox refresh operations where Connected Apps (and their Consumer Secrets), certificates, and custom settings would otherwise be lost. It automates the extraction, secure storage, and (optionally) deletion of Connected Apps, ensuring that all credentials and configuration can be restored post-refresh.\n\nKey functionalities:\n\n- **Connected App Discovery:** Lists all Connected Apps in the org, with options to filter by name, process all, or interactively select.\n- **User Selection:** Allows interactive or flag-based selection of which Connected Apps to back up.\n- **Metadata Retrieval:** Retrieves Connected App metadata and saves it in a dedicated project folder for the sandbox instance.\n- **Consumer Secret Extraction:** Attempts to extract Consumer Secrets automatically using browser automation (Puppeteer), or prompts for manual entry if automation fails.\n- **Config Persistence:** Stores the list of selected apps in the project config for use during restoration.\n- **Optional Deletion:** Can delete the Connected Apps from the org after backup, as required for re-upload after refresh.\n- **Certificate Backup:** Retrieves all org certificates and their definitions, saving them for later restoration.\n- **Custom Settings Backup:** Lists all custom settings in the org, allows user selection, and exports their data to JSON files for backup.\n- **Summary and Reporting:** Provides a summary of actions, including which apps, certificates, and custom settings were saved and whether secrets were captured.\n\nThis command is part of [sfdx-hardis Sandbox Refresh](https://sfdx-hardis.cloudity.com/salesforce-sandbox-refresh/) and is designed to be run before a sandbox refresh. It ensures that all Connected Apps, secrets, certificates, and custom settings are safely stored for later restoration.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\n- **Salesforce CLI Integration:** Uses `sf org list metadata`, `sf project retrieve start`, and other CLI commands to discover and retrieve Connected Apps, certificates, and custom settings.\n- **Metadata Handling:** Saves Connected App XML files and certificate files in a dedicated folder under `scripts/sandbox-refresh/<sandbox-folder>`.\n- **Consumer Secret Handling:** Uses Puppeteer to automate browser login and extraction of Consumer Secrets, falling back to manual prompts if needed.\n- **Custom Settings Handling:** Lists all custom settings, allows user selection, and exports their data using `sf data tree export` to JSON files.\n- **Config Management:** Updates `config/.sfdx-hardis.yml` with the list of selected apps for later use.\n- **Deletion Logic:** Optionally deletes Connected Apps from the org (required for re-upload after refresh), with user confirmation unless running in CI or with `--delete` flag.\n- **Error Handling:** Provides detailed error messages and guidance if retrieval or extraction fails.\n- **Reporting:** Sends summary and configuration files to the WebSocket client for reporting and traceability.\n\n</details>\n",
+      "examples": [
+        "$ sf hardis:org:refresh:before-refresh",
+        "$ sf hardis:org:refresh:before-refresh --name \"MyConnectedApp\"",
+        "$ sf hardis:org:refresh:before-refresh --name \"App1,App2,App3\"",
+        "$ sf hardis:org:refresh:before-refresh --all",
+        "$ sf hardis:org:refresh:before-refresh --delete"
+      ],
+      "flags": {
+        "json": {
+          "description": "Format output as json.",
+          "helpGroup": "GLOBAL",
+          "name": "json",
+          "allowNo": false,
+          "type": "boolean"
+        },
+        "flags-dir": {
+          "helpGroup": "GLOBAL",
+          "name": "flags-dir",
+          "summary": "Import flag values from a directory.",
+          "hasDynamicHelp": false,
+          "multiple": false,
+          "type": "option"
+        },
+        "target-org": {
+          "char": "o",
+          "name": "target-org",
+          "noCacheDefault": true,
+          "required": true,
+          "summary": "Username or alias of the target org. Not required if the `target-org` configuration variable is already set.",
+          "hasDynamicHelp": true,
+          "multiple": false,
+          "type": "option"
+        },
+        "delete": {
+          "char": "d",
+          "description": "By default, Connected Apps are not deleted from the org after saving. Set this flag to force their deletion so they will be able to be reuploaded again after refreshing the org.",
+          "name": "delete",
+          "summary": "Delete Connected Apps from org after saving",
+          "allowNo": false,
+          "type": "boolean"
+        },
+        "name": {
+          "char": "n",
+          "description": "Connected App name(s) to process. For multiple apps, separate with commas (e.g., \"App1,App2\")",
+          "name": "name",
+          "summary": "Filter according to Name criteria",
+          "hasDynamicHelp": false,
+          "multiple": false,
+          "type": "option"
+        },
+        "all": {
+          "char": "a",
+          "description": "If set, all Connected Apps from the org will be processed. Takes precedence over --name if both are specified.",
+          "name": "all",
+          "summary": "Process all Connected Apps without selection prompt",
+          "allowNo": false,
+          "type": "boolean"
+        },
+        "websocket": {
+          "description": "Websocket host:port for VsCode SFDX Hardis UI integration",
+          "name": "websocket",
+          "hasDynamicHelp": false,
+          "multiple": false,
+          "type": "option"
+        },
+        "skipauth": {
+          "description": "Skip authentication check when a default username is required",
+          "name": "skipauth",
+          "allowNo": false,
+          "type": "boolean"
+        }
+      },
+      "hasDynamicHelp": true,
+      "hiddenAliases": [],
+      "id": "hardis:org:refresh:before-refresh",
+      "pluginAlias": "sfdx-hardis",
+      "pluginName": "sfdx-hardis",
+      "pluginType": "core",
+      "strict": true,
+      "enableJsonFlag": true,
+      "requiresProject": true,
+      "isESM": true,
+      "relativePath": [
+        "lib",
+        "commands",
+        "hardis",
+        "org",
+        "refresh",
+        "before-refresh.js"
+      ],
+      "aliasPermutations": [],
+      "permutations": [
+        "hardis:org:refresh:before-refresh",
+        "org:hardis:refresh:before-refresh",
+        "org:refresh:hardis:before-refresh",
+        "org:refresh:before-refresh:hardis",
+        "hardis:refresh:org:before-refresh",
+        "refresh:hardis:org:before-refresh",
+        "refresh:org:hardis:before-refresh",
+        "refresh:org:before-refresh:hardis",
+        "hardis:refresh:before-refresh:org",
+        "refresh:hardis:before-refresh:org",
+        "refresh:before-refresh:hardis:org",
+        "refresh:before-refresh:org:hardis",
+        "hardis:org:before-refresh:refresh",
+        "org:hardis:before-refresh:refresh",
+        "org:before-refresh:hardis:refresh",
+        "org:before-refresh:refresh:hardis",
+        "hardis:before-refresh:org:refresh",
+        "before-refresh:hardis:org:refresh",
+        "before-refresh:org:hardis:refresh",
+        "before-refresh:org:refresh:hardis",
+        "hardis:before-refresh:refresh:org",
+        "before-refresh:hardis:refresh:org",
+        "before-refresh:refresh:hardis:org",
+        "before-refresh:refresh:org:hardis"
+      ]
+    },
     "hardis:org:retrieve:packageconfig": {
       "aliases": [],
       "args": {},
-      "description": "\n**Retrieves the installed package configuration from a Salesforce org and optionally updates the local project configuration.**\n\nThis command is useful for maintaining an accurate record of installed packages within your Salesforce project, which is crucial for managing dependencies and ensuring consistent deployments across environments.\n\nKey functionalities:\n\n- **Package Listing:** Connects to a specified Salesforce org (or prompts for one if not provided) and retrieves a list of all installed packages.\n- **Configuration Update:** Offers the option to update your local project's configuration with the retrieved list of installed packages. This can be beneficial for automating package installations during environment setup or CI/CD processes.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Org Connection:** It establishes a connection to the target Salesforce org using the provided or prompted username.\n- **Metadata Retrieval:** It utilizes `MetadataUtils.listInstalledPackages` to query the Salesforce org and obtain details about the installed packages.\n- **Interactive Prompt:** It uses the `prompts` library to ask the user whether they want to update their local project configuration with the retrieved package list.\n- **Configuration Management:** If the user confirms, it calls `managePackageConfig` to update the project's configuration file (likely `.sfdx-hardis.yml`) with the new package information.\n- **User Feedback:** Provides clear messages to the user about the success of the package retrieval and configuration update.\n",
+      "description": "\n**Retrieves the installed package configuration from a Salesforce org and optionally updates the local project configuration.**\n\nThis command is useful for maintaining an accurate record of installed packages within your Salesforce project, which is crucial for managing dependencies and ensuring consistent deployments across environments.\n\nKey functionalities:\n\n- **Package Listing:** Connects to a specified Salesforce org (or prompts for one if not provided) and retrieves a list of all installed packages.\n- **Configuration Update:** Offers the option to update your local project's configuration with the retrieved list of installed packages. This can be beneficial for automating package installations during environment setup or CI/CD processes.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Org Connection:** It establishes a connection to the target Salesforce org using the provided or prompted username.\n- **Metadata Retrieval:** It utilizes `MetadataUtils.listInstalledPackages` to query the Salesforce org and obtain details about the installed packages.\n- **Interactive Prompt:** It uses the `prompts` library to ask the user whether they want to update their local project configuration with the retrieved package list.\n- **Configuration Management:** If the user confirms, it calls `managePackageConfig` to update the project's configuration file (likely `.sfdx-hardis.yml`) with the new package information.\n- **User Feedback:** Provides clear messages to the user about the success of the package retrieval and configuration update.\n</details>\n",
       "examples": [
         "$ sf hardis:org:retrieve:packageconfig",
         "sf hardis:org:retrieve:packageconfig -u myOrg"
@@ -8226,7 +8465,7 @@
     "hardis:org:user:freeze": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Freezes Salesforce user logins, temporarily revoking access for selected users.**\n\nThis command allows administrators to freeze Salesforce user logins. It provides a controlled way to temporarily revoke user access without deactivating the user record itself. This is useful for managing user access during leaves, security incidents, or when a user's access needs to be temporarily suspended.\n\nKey functionalities:\n\n- **User Selection:** You can select users to freeze based on their assigned profiles.\n  - `--includeprofiles`: Freeze users belonging to a comma-separated list of specified profiles.\n  - `--excludeprofiles`: Freeze users belonging to all profiles *except* those specified in a comma-separated list.\n  - If no profile flags are provided, an interactive menu will allow you to select profiles.\n- **Interactive Confirmation:** In non-CI environments, it prompts for confirmation before freezing the selected users.\n- **Bulk Freezing:** Efficiently freezes multiple user logins using Salesforce's Bulk API.\n- **Reporting:** Generates CSV and XLSX reports of the users that are about to be frozen.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **SOQL Queries (Bulk API):** It executes SOQL queries against the `User` and `Profile` objects to identify active users based on the provided profile filters. It then queries the `UserLogin` object to find active login sessions for these users.\n- **Interactive Prompts:** Uses the `prompts` library to guide the user through profile selection and to confirm the freezing operation.\n- **Bulk Update:** It constructs an array of `UserLogin` records with their `Id` and `IsFrozen` set to `true`, then uses `bulkUpdate` to perform the mass update operation on the Salesforce org.\n- **Reporting:** It uses `generateReports` to create CSV and XLSX files containing details of the users to be frozen.\n- **Logging:** Provides clear messages about the number of users found and the success of the freezing process.\n",
+      "description": "\n## Command Behavior\n\n**Freezes Salesforce user logins, temporarily revoking access for selected users.**\n\nThis command allows administrators to freeze Salesforce user logins. It provides a controlled way to temporarily revoke user access without deactivating the user record itself. This is useful for managing user access during leaves, security incidents, or when a user's access needs to be temporarily suspended.\n\nKey functionalities:\n\n- **User Selection:** You can select users to freeze based on their assigned profiles.\n  - `--includeprofiles`: Freeze users belonging to a comma-separated list of specified profiles.\n  - `--excludeprofiles`: Freeze users belonging to all profiles *except* those specified in a comma-separated list.\n  - If no profile flags are provided, an interactive menu will allow you to select profiles.\n- **Interactive Confirmation:** In non-CI environments, it prompts for confirmation before freezing the selected users.\n- **Bulk Freezing:** Efficiently freezes multiple user logins using Salesforce's Bulk API.\n- **Reporting:** Generates CSV and XLSX reports of the users that are about to be frozen.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **SOQL Queries (Bulk API):** It executes SOQL queries against the `User` and `Profile` objects to identify active users based on the provided profile filters. It then queries the `UserLogin` object to find active login sessions for these users.\n- **Interactive Prompts:** Uses the `prompts` library to guide the user through profile selection and to confirm the freezing operation.\n- **Bulk Update:** It constructs an array of `UserLogin` records with their `Id` and `IsFrozen` set to `true`, then uses `bulkUpdate` to perform the mass update operation on the Salesforce org.\n- **Reporting:** It uses `generateReports` to create CSV and XLSX files containing details of the users to be frozen.\n- **Logging:** Provides clear messages about the number of users found and the success of the freezing process.\n</details>\n",
       "examples": [
         "$ sf hardis:org:user:freeze",
         "$ sf hardis:org:user:freeze --target-org my-user@myorg.com",
@@ -8368,7 +8607,7 @@
     "hardis:org:user:unfreeze": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Unfreezes Salesforce user logins, restoring access for selected users.**\n\nThis command allows administrators to unfreeze Salesforce user logins, reactivating their access to the Salesforce org. This is the counterpart to the `freeze` command and is used to restore access after a temporary suspension.\n\nKey functionalities:\n\n- **User Selection:** You can select users to unfreeze based on their assigned profiles.\n  - `--includeprofiles`: Unfreeze users belonging to a comma-separated list of specified profiles.\n  - `--excludeprofiles`: Unfreeze users belonging to all profiles *except* those specified in a comma-separated list.\n  - If no profile flags are provided, an interactive menu will allow you to select profiles.\n- **Interactive Confirmation:** In non-CI environments, it prompts for confirmation before unfreezing the selected users.\n- **Bulk Unfreezing:** Efficiently unfreezes multiple user logins using Salesforce's Bulk API.\n- **Reporting:** Generates CSV and XLSX reports of the users that are about to be unfrozen.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **SOQL Queries (Bulk API):** It executes SOQL queries against the `User` and `Profile` objects to identify active users based on the provided profile filters. It then queries the `UserLogin` object to find frozen login sessions for these users.\n- **Interactive Prompts:** Uses the `prompts` library to guide the user through profile selection and to confirm the unfreezing operation.\n- **Bulk Update:** It constructs an array of `UserLogin` records with their `Id` and `IsFrozen` set to `false`, then uses `bulkUpdate` to perform the mass update operation on the Salesforce org.\n- **Reporting:** It uses `generateReports` to create CSV and XLSX files containing details of the users to be unfrozen.\n- **Logging:** Provides clear messages about the number of users found and the success of the unfreezing process.\n",
+      "description": "\n## Command Behavior\n\n**Unfreezes Salesforce user logins, restoring access for selected users.**\n\nThis command allows administrators to unfreeze Salesforce user logins, reactivating their access to the Salesforce org. This is the counterpart to the `freeze` command and is used to restore access after a temporary suspension.\n\nKey functionalities:\n\n- **User Selection:** You can select users to unfreeze based on their assigned profiles.\n  - `--includeprofiles`: Unfreeze users belonging to a comma-separated list of specified profiles.\n  - `--excludeprofiles`: Unfreeze users belonging to all profiles *except* those specified in a comma-separated list.\n  - If no profile flags are provided, an interactive menu will allow you to select profiles.\n- **Interactive Confirmation:** In non-CI environments, it prompts for confirmation before unfreezing the selected users.\n- **Bulk Unfreezing:** Efficiently unfreezes multiple user logins using Salesforce's Bulk API.\n- **Reporting:** Generates CSV and XLSX reports of the users that are about to be unfrozen.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **SOQL Queries (Bulk API):** It executes SOQL queries against the `User` and `Profile` objects to identify active users based on the provided profile filters. It then queries the `UserLogin` object to find frozen login sessions for these users.\n- **Interactive Prompts:** Uses the `prompts` library to guide the user through profile selection and to confirm the unfreezing operation.\n- **Bulk Update:** It constructs an array of `UserLogin` records with their `Id` and `IsFrozen` set to `false`, then uses `bulkUpdate` to perform the mass update operation on the Salesforce org.\n- **Reporting:** It uses `generateReports` to create CSV and XLSX files containing details of the users to be unfrozen.\n- **Logging:** Provides clear messages about the number of users found and the success of the unfreezing process.\n</details>\n",
       "examples": [
         "$ sf hardis:org:user:unfreeze",
         "$ sf hardis:org:user:unfreeze --target-org my-user@myorg.com",
@@ -8510,7 +8749,7 @@
     "hardis:package:version:create": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Creates a new version of a Salesforce package (2GP or Unlocked) in your Dev Hub.**\n\nThis command is a crucial step in the package development lifecycle, allowing you to iterate on your Salesforce functionalities and prepare them for deployment or distribution. It automates the process of creating a new, immutable package version.\n\nKey functionalities:\n\n- **Package Selection:** Prompts you to select an existing package from your `sfdx-project.json` file if not specified via the `--package` flag.\n- **Installation Key:** Allows you to set an installation key (password) for the package version, protecting it from unauthorized installations. This can be provided via the `--installkey` flag or interactively.\n- **Code Coverage:** Automatically includes code coverage checks during package version creation.\n- **Post-Creation Actions:**\n  - **Delete After Creation (`--deleteafter`):** Deletes the newly created package version immediately after its creation. This is useful for testing the package creation process without accumulating unnecessary versions.\n  - **Install After Creation (`--install`):** Installs the newly created package version on your default Salesforce org. This is convenient for immediate testing or validation.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Package Directory Identification:** It identifies the package directory from your `sfdx-project.json` based on the selected package name.\n- **Interactive Prompts:** Uses the `prompts` library to guide the user through package selection and installation key input if not provided as command-line arguments.\n- **Configuration Persistence:** Stores the `defaultPackageInstallationKey` in your project's configuration (`.sfdx-hardis.yml`) for future use.\n- **Salesforce CLI Integration:** It constructs and executes the `sf package version create` command, passing the package ID, installation key, and other flags.\n- **`execSfdxJson`:** This utility is used to execute the Salesforce CLI command and capture its JSON output, which includes the `SubscriberPackageVersionId` of the newly created version.\n- **Post-Creation Command Execution:** If `--deleteafter` or `--install` flags are set, it executes `sf package version delete` or delegates to `MetadataUtils.installPackagesOnOrg` respectively.\n- **Error Handling:** Includes checks for missing package arguments and handles errors during package version creation or post-creation actions.\n",
+      "description": "\n## Command Behavior\n\n**Creates a new version of a Salesforce package (2GP or Unlocked) in your Dev Hub.**\n\nThis command is a crucial step in the package development lifecycle, allowing you to iterate on your Salesforce functionalities and prepare them for deployment or distribution. It automates the process of creating a new, immutable package version.\n\nKey functionalities:\n\n- **Package Selection:** Prompts you to select an existing package from your `sfdx-project.json` file if not specified via the `--package` flag.\n- **Installation Key:** Allows you to set an installation key (password) for the package version, protecting it from unauthorized installations. This can be provided via the `--installkey` flag or interactively.\n- **Code Coverage:** Automatically includes code coverage checks during package version creation.\n- **Post-Creation Actions:**\n  - **Delete After Creation (`--deleteafter`):** Deletes the newly created package version immediately after its creation. This is useful for testing the package creation process without accumulating unnecessary versions.\n  - **Install After Creation (`--install`):** Installs the newly created package version on your default Salesforce org. This is convenient for immediate testing or validation.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Package Directory Identification:** It identifies the package directory from your `sfdx-project.json` based on the selected package name.\n- **Interactive Prompts:** Uses the `prompts` library to guide the user through package selection and installation key input if not provided as command-line arguments.\n- **Configuration Persistence:** Stores the `defaultPackageInstallationKey` in your project's configuration (`.sfdx-hardis.yml`) for future use.\n- **Salesforce CLI Integration:** It constructs and executes the `sf package version create` command, passing the package ID, installation key, and other flags.\n- **`execSfdxJson`:** This utility is used to execute the Salesforce CLI command and capture its JSON output, which includes the `SubscriberPackageVersionId` of the newly created version.\n- **Post-Creation Command Execution:** If `--deleteafter` or `--install` flags are set, it executes `sf package version delete` or delegates to `MetadataUtils.installPackagesOnOrg` respectively.\n- **Error Handling:** Includes checks for missing package arguments and handles errors during package version creation or post-creation actions.\n</details>\n",
       "examples": [
         "$ sf hardis:package:version:create"
       ],
@@ -8646,7 +8885,7 @@
     "hardis:package:version:list": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Lists all Salesforce package versions associated with your Dev Hub.**\n\nThis command provides a comprehensive overview of your Salesforce packages and their versions, including details such as package ID, version number, installation key status, and creation date. It's an essential tool for managing your package development lifecycle, tracking releases, and identifying available versions for installation or promotion.\n\nKey functionalities:\n\n- **Comprehensive Listing:** Displays all package versions, regardless of their status (e.g., released, beta).\n- **Dev Hub Integration:** Retrieves package version information directly from your connected Dev Hub.\n\n## Technical explanations\n\nThe command's technical implementation is straightforward:\n\n- **Salesforce CLI Integration:** It directly executes the `sf package version list` command.\n- **`execCommand`:** This utility is used to run the Salesforce CLI command and capture its output.\n- **Output Display:** The raw output from the Salesforce CLI command is displayed to the user, providing all the details about the package versions.\n",
+      "description": "\n## Command Behavior\n\n**Lists all Salesforce package versions associated with your Dev Hub.**\n\nThis command provides a comprehensive overview of your Salesforce packages and their versions, including details such as package ID, version number, installation key status, and creation date. It's an essential tool for managing your package development lifecycle, tracking releases, and identifying available versions for installation or promotion.\n\nKey functionalities:\n\n- **Comprehensive Listing:** Displays all package versions, regardless of their status (e.g., released, beta).\n- **Dev Hub Integration:** Retrieves package version information directly from your connected Dev Hub.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation is straightforward:\n\n- **Salesforce CLI Integration:** It directly executes the `sf package version list` command.\n- **`execCommand`:** This utility is used to run the Salesforce CLI command and capture its output.\n- **Output Display:** The raw output from the Salesforce CLI command is displayed to the user, providing all the details about the package versions.\n</details>\n",
       "examples": [
         "$ sf hardis:package:version:list"
       ],
@@ -8751,7 +8990,7 @@
     "hardis:package:version:promote": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Promotes a Salesforce package version from beta to released status in your Dev Hub.**\n\nThis command is a critical step in the package development lifecycle, marking a package version as stable and ready for production use. Once promoted, a package version can be installed in production organizations.\n\nKey functionalities:\n\n- **Package Version Selection:** Allows you to select a specific package version to promote. If the `--auto` flag is used, it automatically identifies package versions that are not yet released and promotes them.\n- **Automated Promotion:** When `--auto` is enabled, it queries for all unreleased package versions and promotes them without further user interaction.\n- **Dev Hub Integration:** Interacts with your connected Dev Hub to change the status of the package version.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Package Alias Retrieval:** It retrieves package aliases from your `sfdx-project.json` to identify available packages.\n- **Automated Promotion Logic:** If `--auto` is used, it executes `sf package version list --released` to get a list of already released packages and then filters the available package aliases to find those that are not yet released.\n- **Interactive Prompts:** If not in auto mode, it uses the `prompts` library to allow the user to select a package version to promote.\n- **Salesforce CLI Integration:** It constructs and executes the `sf package version promote` command, passing the package version ID.\n- **`execSfdxJson`:** This utility is used to execute the Salesforce CLI command and capture its JSON output.\n- **Error Handling:** It handles cases where a package version might already be promoted or if other errors occur during the promotion process.\n",
+      "description": "\n## Command Behavior\n\n**Promotes a Salesforce package version from beta to released status in your Dev Hub.**\n\nThis command is a critical step in the package development lifecycle, marking a package version as stable and ready for production use. Once promoted, a package version can be installed in production organizations.\n\nKey functionalities:\n\n- **Package Version Selection:** Allows you to select a specific package version to promote. If the `--auto` flag is used, it automatically identifies package versions that are not yet released and promotes them.\n- **Automated Promotion:** When `--auto` is enabled, it queries for all unreleased package versions and promotes them without further user interaction.\n- **Dev Hub Integration:** Interacts with your connected Dev Hub to change the status of the package version.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Package Alias Retrieval:** It retrieves package aliases from your `sfdx-project.json` to identify available packages.\n- **Automated Promotion Logic:** If `--auto` is used, it executes `sf package version list --released` to get a list of already released packages and then filters the available package aliases to find those that are not yet released.\n- **Interactive Prompts:** If not in auto mode, it uses the `prompts` library to allow the user to select a package version to promote.\n- **Salesforce CLI Integration:** It constructs and executes the `sf package version promote` command, passing the package version ID.\n- **`execSfdxJson`:** This utility is used to execute the Salesforce CLI command and capture its JSON output.\n- **Error Handling:** It handles cases where a package version might already be promoted or if other errors occur during the promotion process.\n</details>\n",
       "examples": [
         "$ sf hardis:package:version:promote",
         "$ sf hardis:package:version:promote --auto"
@@ -8995,7 +9234,7 @@
     "hardis:project:audit:callincallout": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Audits Apex classes for inbound (Call-In) and outbound (Call-Out) API calls, providing insights into integration points.**\n\nThis command helps developers and architects understand the integration landscape of their Salesforce project by identifying where Apex code interacts with external systems or exposes functionality for external consumption. It's useful for security reviews, refactoring efforts, and documenting system integrations.\n\nKey functionalities:\n\n- **Inbound Call Detection:** Identifies Apex methods exposed as web services (`webservice static`) or REST resources (`@RestResource`).\n- **Outbound Call Detection:** Detects HTTP callouts (`new HttpRequest`).\n- **Detailed Information:** Extracts relevant details for each detected call, such as endpoint URLs for outbound calls or resource names for inbound calls.\n- **Test Class Exclusion:** Automatically skips test classes (`@isTest`) to focus on production code.\n- **CSV Report Generation:** Generates a CSV report summarizing all detected call-ins and call-outs, including their type, subtype (protocol), file name, namespace, and extracted details.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **File Discovery:** Uses `glob` to find all Apex class (`.cls`) and trigger (`.trigger`) files within the project.\n- **Content Analysis:** Reads the content of each Apex file and uses regular expressions to identify patterns indicative of inbound or outbound calls.\n- **Pattern Matching:** Defines a set of `catchers`, each with a `type` (INBOUND/OUTBOUND), `subType` (SOAP/REST/HTTP), and `regex` to match specific API call patterns. It also includes `detail` regexes to extract additional information.\n- **`catchMatches` Utility:** This utility function is used to apply the defined `catchers` to each Apex file and extract all matching occurrences.\n- **Data Structuring:** Organizes the extracted information into a structured format, including the file name, namespace, and detailed matches.\n- **Reporting:** Uses `generateReports` to create a CSV report and display a table in the console, summarizing the audit findings.\n- **Filtering:** Filters out files that start with 'hidden' or contain `@isTest` to focus on relevant code.\n",
+      "description": "\n## Command Behavior\n\n**Audits Apex classes for inbound (Call-In) and outbound (Call-Out) API calls, providing insights into integration points.**\n\nThis command helps developers and architects understand the integration landscape of their Salesforce project by identifying where Apex code interacts with external systems or exposes functionality for external consumption. It's useful for security reviews, refactoring efforts, and documenting system integrations.\n\nKey functionalities:\n\n- **Inbound Call Detection:** Identifies Apex methods exposed as web services (`webservice static`) or REST resources (`@RestResource`).\n- **Outbound Call Detection:** Detects HTTP callouts (`new HttpRequest`).\n- **Detailed Information:** Extracts relevant details for each detected call, such as endpoint URLs for outbound calls or resource names for inbound calls.\n- **Test Class Exclusion:** Automatically skips test classes (`@isTest`) to focus on production code.\n- **CSV Report Generation:** Generates a CSV report summarizing all detected call-ins and call-outs, including their type, subtype (protocol), file name, namespace, and extracted details.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **File Discovery:** Uses `glob` to find all Apex class (`.cls`) and trigger (`.trigger`) files within the project.\n- **Content Analysis:** Reads the content of each Apex file and uses regular expressions to identify patterns indicative of inbound or outbound calls.\n- **Pattern Matching:** Defines a set of `catchers`, each with a `type` (INBOUND/OUTBOUND), `subType` (SOAP/REST/HTTP), and `regex` to match specific API call patterns. It also includes `detail` regexes to extract additional information.\n- **`catchMatches` Utility:** This utility function is used to apply the defined `catchers` to each Apex file and extract all matching occurrences.\n- **Data Structuring:** Organizes the extracted information into a structured format, including the file name, namespace, and detailed matches.\n- **Reporting:** Uses `generateReports` to create a CSV report and display a table in the console, summarizing the audit findings.\n- **Filtering:** Filters out files that start with 'hidden' or contain `@isTest` to focus on relevant code.\n</details>\n",
       "examples": [
         "$ sf hardis:project:audit:callouts"
       ],
@@ -9086,7 +9325,7 @@
     "hardis:project:audit:duplicatefiles": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Identifies and reports on duplicate file names within your Salesforce DX project folder.**\n\nThis command helps detect instances where files with the same name exist in different directories within your SFDX project. While some duplicates are expected (e.g., metadata files for different components of the same object), others can be a result of past Salesforce CLI bugs or improper source control practices, leading to confusion and potential deployment issues.\n\nKey functionalities:\n\n- **File Scan:** Recursively scans a specified root path (defaults to the current working directory) for all files.\n- **Duplicate Detection:** Identifies files that share the same name but reside in different locations.\n- **Intelligent Filtering:** Accounts for known patterns where duplicate file names are legitimate (e.g., `field-meta.xml`, `listView-meta.xml`, `recordType-meta.xml`, `webLink-meta.xml` files within object subdirectories).\n- **Reporting:** Outputs a JSON object detailing the detected duplicates, including the file name and the full paths of its occurrences.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **File System Traversal:** Uses `fs-readdir-recursive` to list all files within the specified directory, excluding `node_modules`.\n- **Duplicate Logic:** Iterates through the list of all files and compares their base names. If two files have the same base name but different full paths, they are considered potential duplicates.\n- **Exclusion Logic:** The `checkDoublingAllowed` function contains regular expressions to identify specific file path patterns where duplicate names are acceptable (e.g., `objects/Account/fields/MyField__c.field-meta.xml` and `objects/Contact/fields/MyField__c.field-meta.xml`). This prevents false positives.\n- **Data Structuring:** Organizes the results into a JavaScript object where keys are duplicate file names and values are arrays of their full paths.\n",
+      "description": "\n## Command Behavior\n\n**Identifies and reports on duplicate file names within your Salesforce DX project folder.**\n\nThis command helps detect instances where files with the same name exist in different directories within your SFDX project. While some duplicates are expected (e.g., metadata files for different components of the same object), others can be a result of past Salesforce CLI bugs or improper source control practices, leading to confusion and potential deployment issues.\n\nKey functionalities:\n\n- **File Scan:** Recursively scans a specified root path (defaults to the current working directory) for all files.\n- **Duplicate Detection:** Identifies files that share the same name but reside in different locations.\n- **Intelligent Filtering:** Accounts for known patterns where duplicate file names are legitimate (e.g., `field-meta.xml`, `listView-meta.xml`, `recordType-meta.xml`, `webLink-meta.xml` files within object subdirectories).\n- **Reporting:** Outputs a JSON object detailing the detected duplicates, including the file name and the full paths of its occurrences.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **File System Traversal:** Uses `fs-readdir-recursive` to list all files within the specified directory, excluding `node_modules`.\n- **Duplicate Logic:** Iterates through the list of all files and compares their base names. If two files have the same base name but different full paths, they are considered potential duplicates.\n- **Exclusion Logic:** The `checkDoublingAllowed` function contains regular expressions to identify specific file path patterns where duplicate names are acceptable (e.g., `objects/Account/fields/MyField__c.field-meta.xml` and `objects/Contact/fields/MyField__c.field-meta.xml`). This prevents false positives.\n- **Data Structuring:** Organizes the results into a JavaScript object where keys are duplicate file names and values are arrays of their full paths.\n</details>\n",
       "examples": [
         "$ sf hardis:project:audit:duplicatefiles"
       ],
@@ -9186,7 +9425,7 @@
     "hardis:project:audit:remotesites": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Audits Salesforce Remote Site Settings in your project, providing a comprehensive overview of external endpoints accessed by your Salesforce org.**\n\nThis command is crucial for security reviews, compliance checks, and understanding the external integrations of your Salesforce environment. It helps identify all configured remote sites, their URLs, activity status, and associated protocols.\n\nKey functionalities:\n\n- **Remote Site Discovery:** Scans your project for RemoteSiteSetting metadata files (.remoteSite-meta.xml or .remoteSite).\n- **URL Extraction:** Extracts the URL, active status, and description for each remote site.\n- **Protocol and Domain Identification:** Determines the protocol (HTTP/HTTPS) and extracts the domain from each URL, providing a clearer picture of the external systems being accessed.\n- **Reporting:** Generates a CSV report summarizing all detected remote sites, including their protocol, domain, name, URL, active status, and description.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **File Discovery:** Uses `glob` to find all RemoteSiteSetting metadata files within the project.\n- **Content Analysis:** Reads the content of each XML file and uses regular expressions (/<url>(.*?)<\\/url>/gim, /<isActive>(.*?)<\\/isActive>/gim, /<description>(.*?)<\\/description>/gim) to extract relevant details.\n- **`catchMatches` Utility:** This utility function is used to apply the defined regular expressions to each file and extract all matching occurrences.\n- **URL Parsing:** Uses Node.js's `url` module to parse the extracted URLs and `psl` (Public Suffix List) to extract the domain name from the hostname.\n- **Data Structuring:** Organizes the extracted information into a structured format, including the remote site's name, file name, namespace, URL, active status, description, protocol, and domain.\n- **Reporting:** Uses `generateReports` to create a CSV report and display a table in the console, summarizing the audit findings.\n",
+      "description": "\n## Command Behavior\n\n**Audits Salesforce Remote Site Settings in your project, providing a comprehensive overview of external endpoints accessed by your Salesforce org.**\n\nThis command is crucial for security reviews, compliance checks, and understanding the external integrations of your Salesforce environment. It helps identify all configured remote sites, their URLs, activity status, and associated protocols.\n\nKey functionalities:\n\n- **Remote Site Discovery:** Scans your project for RemoteSiteSetting metadata files (.remoteSite-meta.xml or .remoteSite).\n- **URL Extraction:** Extracts the URL, active status, and description for each remote site.\n- **Protocol and Domain Identification:** Determines the protocol (HTTP/HTTPS) and extracts the domain from each URL, providing a clearer picture of the external systems being accessed.\n- **Reporting:** Generates a CSV report summarizing all detected remote sites, including their protocol, domain, name, URL, active status, and description.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **File Discovery:** Uses `glob` to find all RemoteSiteSetting metadata files within the project.\n- **Content Analysis:** Reads the content of each XML file and uses regular expressions (/<url>(.*?)<\\/url>/gim, /<isActive>(.*?)<\\/isActive>/gim, /<description>(.*?)<\\/description>/gim) to extract relevant details.\n- **`catchMatches` Utility:** This utility function is used to apply the defined regular expressions to each file and extract all matching occurrences.\n- **URL Parsing:** Uses Node.js's `url` module to parse the extracted URLs and `psl` (Public Suffix List) to extract the domain name from the hostname.\n- **Data Structuring:** Organizes the extracted information into a structured format, including the remote site's name, file name, namespace, URL, active status, description, protocol, and domain.\n- **Reporting:** Uses `generateReports` to create a CSV report and display a table in the console, summarizing the audit findings.\n</details>\n",
       "examples": [
         "$ sf hardis:project:audit:remotesites"
       ],
@@ -9277,7 +9516,7 @@
     "hardis:project:configure:auth": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Configures authentication between a Git branch and a target Salesforce org for CI/CD deployments.**\n\nThis command facilitates the setup of automated CI/CD pipelines, enabling seamless deployments from specific Git branches to designated Salesforce orgs. It supports both standard Salesforce orgs and Dev Hub configurations, catering to various enterprise deployment workflows.\n\nKey functionalities include:\n\n- **Org Selection/Login:** Guides the user to select an existing Salesforce org or log in to a new one.\n- **Git Branch Association:** Allows associating a specific Git branch with the chosen Salesforce org.\n- **Merge Target Definition:** Enables defining target Git branches into which the configured branch can merge, ensuring controlled deployment flows.\n- **Salesforce Username Configuration:** Prompts for the Salesforce username to be used by the CI server for deployments.\n- **SSL Certificate Generation:** Automatically generates an SSL certificate for secure authentication.\n\n## Technical explanations\n\nThe command's implementation involves several key technical aspects:\n\n- **SF CLI Integration:** Utilizes \n@salesforce/sf-plugins-core\n for command structure and flag parsing.\n- **Interactive Prompts:** Employs the \nprompts\n library for interactive user input, guiding the configuration process.\n- **Git Integration:** Interacts with Git to retrieve branch information using \n`git().branch([\"--list\", \"-r\"])`\n.\n- **Configuration Management:** Leverages internal utilities (`checkConfig`, `getConfig`, `setConfig`, `setInConfigFile`) to read from and write to project-specific configuration files (e.g., `.sfdx-hardis.<branchName>.yml`).\n- **Salesforce CLI Execution:** Executes Salesforce CLI commands programmatically via `execSfdxJson` for org interactions.\n- **SSL Certificate Generation:** Calls `generateSSLCertificate` to create necessary SSL certificates for JWT-based authentication.\n- **WebSocket Communication:** Uses `WebSocketClient` for potential communication with external tools or processes, such as restarting the command in VS Code.\n- **Dependency Check:** Ensures the presence of `openssl` on the system, which is required for SSL certificate generation.\n",
+      "description": "\n## Command Behavior\n\n**Configures authentication between a Git branch and a target Salesforce org for CI/CD deployments.**\n\nThis command facilitates the setup of automated CI/CD pipelines, enabling seamless deployments from specific Git branches to designated Salesforce orgs. It supports both standard Salesforce orgs and Dev Hub configurations, catering to various enterprise deployment workflows.\n\nKey functionalities include:\n\n- **Org Selection/Login:** Guides the user to select an existing Salesforce org or log in to a new one.\n- **Git Branch Association:** Allows associating a specific Git branch with the chosen Salesforce org.\n- **Merge Target Definition:** Enables defining target Git branches into which the configured branch can merge, ensuring controlled deployment flows.\n- **Salesforce Username Configuration:** Prompts for the Salesforce username to be used by the CI server for deployments.\n- **SSL Certificate Generation:** Automatically generates an SSL certificate for secure authentication.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's implementation involves several key technical aspects:\n\n- **SF CLI Integration:** Utilizes \n@salesforce/sf-plugins-core\n for command structure and flag parsing.\n- **Interactive Prompts:** Employs the \nprompts\n library for interactive user input, guiding the configuration process.\n- **Git Integration:** Interacts with Git to retrieve branch information using \n`git().branch([\"--list\", \"-r\"])`\n.\n- **Configuration Management:** Leverages internal utilities (`checkConfig`, `getConfig`, `setConfig`, `setInConfigFile`) to read from and write to project-specific configuration files (e.g., `.sfdx-hardis.<branchName>.yml`).\n- **Salesforce CLI Execution:** Executes Salesforce CLI commands programmatically via `execSfdxJson` for org interactions.\n- **SSL Certificate Generation:** Calls `generateSSLCertificate` to create necessary SSL certificates for JWT-based authentication.\n- **WebSocket Communication:** Uses `WebSocketClient` for potential communication with external tools or processes, such as restarting the command in VS Code.\n- **Dependency Check:** Ensures the presence of `openssl` on the system, which is required for SSL certificate generation.\n",
       "examples": [
         "$ sf hardis:project:configure:auth"
       ],
@@ -9403,113 +9642,10 @@
         "auth:configure:project:hardis"
       ]
     },
-    "hardis:project:convert:profilestopermsets": {
-      "aliases": [],
-      "args": {},
-      "description": "\n## Command Behavior\n\n**Converts existing Salesforce Profiles into Permission Sets, facilitating a more granular and recommended security model.**\n\nThis command helps in migrating permissions from Profiles to Permission Sets, which is a best practice for managing user access in Salesforce. It creates a new Permission Set for each specified Profile, adopting a naming convention of `PS_PROFILENAME`.\n\nKey functionalities:\n\n- **Profile to Permission Set Conversion:** Automatically extracts permissions from a Profile and creates a corresponding Permission Set.\n- **Naming Convention:** New Permission Sets are named with a `PS_` prefix followed by the Profile name (e.g., `PS_Standard_User`).\n- **Exclusion Filter:** Allows you to exclude specific Profiles from the conversion process using the `--except` flag.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **External Plugin Integration:** It relies on the `shane-sfdx-plugins` (specifically the `sf shane:profile:convert` command) to perform the actual conversion.\n- **File System Scan:** It reads the contents of the `force-app/main/default/profiles` directory to identify all available Profile metadata files.\n- **Command Execution:** For each identified Profile (that is not excluded), it constructs and executes the `sf shane:profile:convert` command with the appropriate Profile name and desired Permission Set name.\n- **Error Handling:** Includes basic error handling for the external command execution.\n",
-      "examples": [
-        "$ sf hardis:project:convert:profilestopermsets"
-      ],
-      "flags": {
-        "json": {
-          "description": "Format output as json.",
-          "helpGroup": "GLOBAL",
-          "name": "json",
-          "allowNo": false,
-          "type": "boolean"
-        },
-        "flags-dir": {
-          "helpGroup": "GLOBAL",
-          "name": "flags-dir",
-          "summary": "Import flag values from a directory.",
-          "hasDynamicHelp": false,
-          "multiple": false,
-          "type": "option"
-        },
-        "except": {
-          "char": "e",
-          "description": "List of filters",
-          "name": "except",
-          "default": [],
-          "hasDynamicHelp": false,
-          "multiple": true,
-          "type": "option"
-        },
-        "debug": {
-          "char": "d",
-          "description": "Activate debug mode (more logs)",
-          "name": "debug",
-          "allowNo": false,
-          "type": "boolean"
-        },
-        "websocket": {
-          "description": "Websocket host:port for VsCode SFDX Hardis UI integration",
-          "name": "websocket",
-          "hasDynamicHelp": false,
-          "multiple": false,
-          "type": "option"
-        },
-        "skipauth": {
-          "description": "Skip authentication check when a default username is required",
-          "name": "skipauth",
-          "allowNo": false,
-          "type": "boolean"
-        }
-      },
-      "hasDynamicHelp": false,
-      "hiddenAliases": [],
-      "id": "hardis:project:convert:profilestopermsets",
-      "pluginAlias": "sfdx-hardis",
-      "pluginName": "sfdx-hardis",
-      "pluginType": "core",
-      "strict": true,
-      "enableJsonFlag": true,
-      "title": "Convert Profiles into Permission Sets",
-      "requiresProject": true,
-      "requiresSfdxPlugins": [
-        "shane-sfdx-plugins"
-      ],
-      "isESM": true,
-      "relativePath": [
-        "lib",
-        "commands",
-        "hardis",
-        "project",
-        "convert",
-        "profilestopermsets.js"
-      ],
-      "aliasPermutations": [],
-      "permutations": [
-        "hardis:project:convert:profilestopermsets",
-        "project:hardis:convert:profilestopermsets",
-        "project:convert:hardis:profilestopermsets",
-        "project:convert:profilestopermsets:hardis",
-        "hardis:convert:project:profilestopermsets",
-        "convert:hardis:project:profilestopermsets",
-        "convert:project:hardis:profilestopermsets",
-        "convert:project:profilestopermsets:hardis",
-        "hardis:convert:profilestopermsets:project",
-        "convert:hardis:profilestopermsets:project",
-        "convert:profilestopermsets:hardis:project",
-        "convert:profilestopermsets:project:hardis",
-        "hardis:project:profilestopermsets:convert",
-        "project:hardis:profilestopermsets:convert",
-        "project:profilestopermsets:hardis:convert",
-        "project:profilestopermsets:convert:hardis",
-        "hardis:profilestopermsets:project:convert",
-        "profilestopermsets:hardis:project:convert",
-        "profilestopermsets:project:hardis:convert",
-        "profilestopermsets:project:convert:hardis",
-        "hardis:profilestopermsets:convert:project",
-        "profilestopermsets:hardis:convert:project",
-        "profilestopermsets:convert:hardis:project",
-        "profilestopermsets:convert:project:hardis"
-      ]
-    },
     "hardis:project:clean:emptyitems": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Removes empty or irrelevant metadata items from your Salesforce DX project sources.**\n\nThis command helps maintain a clean and efficient Salesforce codebase by deleting metadata files that are essentially empty or contain no meaningful configuration. These files can sometimes be generated during retrieval processes or remain after refactoring, contributing to unnecessary clutter in your project.\n\nKey functionalities:\n\n- **Targeted Cleaning:** Specifically targets and removes empty instances of:\n  - Global Value Set Translations (`.globalValueSetTranslation-meta.xml`)\n  - Standard Value Sets (`.standardValueSet-meta.xml`)\n  - Sharing Rules (`.sharingRules-meta.xml`)\n- **Content-Based Deletion:** It checks the XML content of these files for the presence of specific tags (e.g., `valueTranslation` for Global Value Set Translations) to determine if they are truly empty or lack relevant data.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **File Discovery:** Uses `glob` to find files matching predefined patterns for Global Value Set Translations, Standard Value Sets, and Sharing Rules within the specified root folder (defaults to `force-app`).\n- **XML Parsing:** For each matching file, it reads and parses the XML content using `parseXmlFile`.\n- **Content Validation:** It then checks the parsed XML object for the existence of specific nested properties (e.g., `xmlContent.GlobalValueSetTranslation.valueTranslation`). If these properties are missing or empty, the file is considered empty.\n- **File Deletion:** If a file is determined to be empty, it is removed from the file system using `fs.remove`.\n- **Logging:** Provides clear messages about which files are being removed and a summary of the total number of items cleaned.\n",
+      "description": "\n## Command Behavior\n\n**Removes empty or irrelevant metadata items from your Salesforce DX project sources.**\n\nThis command helps maintain a clean and efficient Salesforce codebase by deleting metadata files that are essentially empty or contain no meaningful configuration. These files can sometimes be generated during retrieval processes or remain after refactoring, contributing to unnecessary clutter in your project.\n\nKey functionalities:\n\n- **Targeted Cleaning:** Specifically targets and removes empty instances of:\n  - Global Value Set Translations (`.globalValueSetTranslation-meta.xml`)\n  - Standard Value Sets (`.standardValueSet-meta.xml`)\n  - Sharing Rules (`.sharingRules-meta.xml`)\n- **Content-Based Deletion:** It checks the XML content of these files for the presence of specific tags (e.g., `valueTranslation` for Global Value Set Translations) to determine if they are truly empty or lack relevant data.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **File Discovery:** Uses `glob` to find files matching predefined patterns for Global Value Set Translations, Standard Value Sets, and Sharing Rules within the specified root folder (defaults to `force-app`).\n- **XML Parsing:** For each matching file, it reads and parses the XML content using `parseXmlFile`.\n- **Content Validation:** It then checks the parsed XML object for the existence of specific nested properties (e.g., `xmlContent.GlobalValueSetTranslation.valueTranslation`). If these properties are missing or empty, the file is considered empty.\n- **File Deletion:** If a file is determined to be empty, it is removed from the file system using `fs.remove`.\n- **Logging:** Provides clear messages about which files are being removed and a summary of the total number of items cleaned.\n</details>\n",
       "examples": [
         "$ sf hardis:project:clean:emptyitems"
       ],
@@ -9609,7 +9745,7 @@
     "hardis:project:clean:filter-xml-content": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Filters the content of Salesforce metadata XML files to remove specific elements, enabling more granular deployments.**\n\nThis command addresses a common challenge in Salesforce development: deploying only a subset of metadata from an XML file when the target org might not support all elements or when certain elements are not desired. It allows you to define rules in a JSON configuration file to remove unwanted XML nodes.\n\nKey functionalities:\n\n- **Configurable Filtering:** Uses a JSON configuration file (e.g., `filter-config.json`) to define which XML elements to remove. This configuration specifies the XML tags to target and the values within those tags that should trigger removal.\n- **Targeted File Processing:** Processes XML files within a specified input folder (defaults to current directory) and writes the filtered content to an output folder.\n- **Example Use Cases:** Useful for scenarios like:\n  - Removing references to features not enabled in the target org.\n  - Stripping out specific profile permissions or field-level security settings.\n  - Cleaning up metadata that is not relevant to a particular deployment.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Configuration Loading:** Reads the `filter-config.json` file, which contains an array of `filters`. Each filter defines a `name`, `description`, `folders` (where to apply the filter), `file_extensions`, and an `exclude_list`.\n- **File System Operations:** Copies the input folder to an output folder (if different) to avoid modifying original files directly. It then iterates through the files in the output folder that match the specified file extensions.\n- **XML Parsing and Manipulation:** For each matching XML file:\n  - It uses `xml2js.Parser` to parse the XML content into a JavaScript object.\n  - It recursively traverses the JavaScript object, applying the `filterElement` function.\n  - The `filterElement` function checks for `type_tag` and `identifier_tag` defined in the `exclude_list`. If a match is found and the value is in the `excludeDef.values`, the element is removed from the XML structure.\n  - After filtering, it uses `writeXmlFile` to write the modified JavaScript object back to the XML file.\n- **Logging:** Provides detailed logs about the filtering process, including which files are being processed and which elements are being filtered.\n- **Summary Reporting:** Tracks and reports on the files that have been updated due to filtering.\n",
+      "description": "\n## Command Behavior\n\n**Filters the content of Salesforce metadata XML files to remove specific elements, enabling more granular deployments.**\n\nThis command addresses a common challenge in Salesforce development: deploying only a subset of metadata from an XML file when the target org might not support all elements or when certain elements are not desired. It allows you to define rules in a JSON configuration file to remove unwanted XML nodes.\n\nKey functionalities:\n\n- **Configurable Filtering:** Uses a JSON configuration file (e.g., `filter-config.json`) to define which XML elements to remove. This configuration specifies the XML tags to target and the values within those tags that should trigger removal.\n- **Targeted File Processing:** Processes XML files within a specified input folder (defaults to current directory) and writes the filtered content to an output folder.\n- **Example Use Cases:** Useful for scenarios like:\n  - Removing references to features not enabled in the target org.\n  - Stripping out specific profile permissions or field-level security settings.\n  - Cleaning up metadata that is not relevant to a particular deployment.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Configuration Loading:** Reads the `filter-config.json` file, which contains an array of `filters`. Each filter defines a `name`, `description`, `folders` (where to apply the filter), `file_extensions`, and an `exclude_list`.\n- **File System Operations:** Copies the input folder to an output folder (if different) to avoid modifying original files directly. It then iterates through the files in the output folder that match the specified file extensions.\n- **XML Parsing and Manipulation:** For each matching XML file:\n  - It uses `xml2js.Parser` to parse the XML content into a JavaScript object.\n  - It recursively traverses the JavaScript object, applying the `filterElement` function.\n  - The `filterElement` function checks for `type_tag` and `identifier_tag` defined in the `exclude_list`. If a match is found and the value is in the `excludeDef.values`, the element is removed from the XML structure.\n  - After filtering, it uses `writeXmlFile` to write the modified JavaScript object back to the XML file.\n- **Logging:** Provides detailed logs about the filtering process, including which files are being processed and which elements are being filtered.\n- **Summary Reporting:** Tracks and reports on the files that have been updated due to filtering.\n</details>\n",
       "examples": [
         "sf hardis:project:clean:filter-xml-content -i \"./mdapi_output\"",
         "sf hardis:project:clean:filter-xml-content -i \"retrieveUnpackaged\""
@@ -9817,7 +9953,7 @@
     "hardis:project:clean:hiddenitems": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Removes hidden or temporary metadata items from your Salesforce DX project sources.**\n\nThis command helps clean up your local Salesforce project by deleting files that are marked as hidden or are temporary artifacts. These files can sometimes be generated by Salesforce CLI or other tools and are not intended to be part of your version-controlled source.\n\nKey functionalities:\n\n- **Targeted File Scan:** Scans for files with specific extensions (`.app`, `.cmp`, `.evt`, `.tokens`, `.html`, `.css`, `.js`, `.xml`) within the specified root folder (defaults to `force-app`).\n- **Hidden Content Detection:** Identifies files whose content starts with (hidden). This is a convention used by some Salesforce tools to mark temporary or internal files.\n- **Component Folder Removal:** If a hidden file is part of a Lightning Web Component (LWC) or Aura component folder, the entire component folder is removed to ensure a complete cleanup.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **File Discovery:** Uses `glob` to find files matching the specified patterns within the `folder`.\n- **Content Reading:** Reads the content of each file.\n- **Hidden Marker Check:** Checks if the file content starts with the literal string (hidden).\n- **Folder or File Removal:** If a file is identified as hidden:\n  - If it's within an lwc or aura component folder, the entire component folder is removed using `fs.remove`.\n  - Otherwise, only the individual file is removed.\n- **Logging:** Provides clear messages about which items are being removed and a summary of the total number of hidden items cleaned.\n",
+      "description": "\n## Command Behavior\n\n**Removes hidden or temporary metadata items from your Salesforce DX project sources.**\n\nThis command helps clean up your local Salesforce project by deleting files that are marked as hidden or are temporary artifacts. These files can sometimes be generated by Salesforce CLI or other tools and are not intended to be part of your version-controlled source.\n\nKey functionalities:\n\n- **Targeted File Scan:** Scans for files with specific extensions (`.app`, `.cmp`, `.evt`, `.tokens`, `.html`, `.css`, `.js`, `.xml`) within the specified root folder (defaults to `force-app`).\n- **Hidden Content Detection:** Identifies files whose content starts with (hidden). This is a convention used by some Salesforce tools to mark temporary or internal files.\n- **Component Folder Removal:** If a hidden file is part of a Lightning Web Component (LWC) or Aura component folder, the entire component folder is removed to ensure a complete cleanup.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **File Discovery:** Uses `glob` to find files matching the specified patterns within the `folder`.\n- **Content Reading:** Reads the content of each file.\n- **Hidden Marker Check:** Checks if the file content starts with the literal string (hidden).\n- **Folder or File Removal:** If a file is identified as hidden:\n  - If it's within an lwc or aura component folder, the entire component folder is removed using `fs.remove`.\n  - Otherwise, only the individual file is removed.\n- **Logging:** Provides clear messages about which items are being removed and a summary of the total number of hidden items cleaned.\n</details>\n",
       "examples": [
         "$ sf hardis:project:clean:hiddenitems"
       ],
@@ -10017,7 +10153,7 @@
     "hardis:project:clean:manageditems": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Removes unwanted managed package items from your Salesforce DX project sources.**\n\nThis command helps clean up your local Salesforce project by deleting metadata files that belong to a specific managed package namespace. This is particularly useful when you retrieve metadata from an org that contains managed packages, and you only want to keep the unmanaged or custom metadata in your local repository.\n\nKey functionalities:\n\n- **Namespace-Based Filtering:** Requires a `--namespace` flag to specify which managed package namespace's files should be removed.\n- **Targeted File Deletion:** Scans for files and folders that start with the specified namespace prefix (e.g., `yourNamespace__*`).\n- **Intelligent Folder Handling:** Prevents the deletion of managed folders if they contain local custom items. This ensures that if you have custom metadata within a managed package's folder structure, only the managed components are removed, preserving your local customizations.\n- **Object Metadata Preservation:** Specifically, it will not remove .object-meta.xml files if there are local custom items defined within that object's folder.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Namespace Validation:** Ensures that a namespace is provided, throwing an `SfError` if it's missing.\n- **File Discovery:** Uses `glob` to find all files and directories within the specified `folder` (defaults to `force-app`) that match the managed package namespace pattern (`**/${this.namespace}__*`).\n- **Folder Content Check:** For identified managed folders, the `folderContainsLocalItems` function is called. This function uses `glob` again to check for the presence of any files within that folder that *do not* start with the managed package namespace, indicating local customizations.\n- **Conditional Deletion:** Based on the `folderContainsLocalItems` check, it conditionally removes files and folders using `fs.remove`. If a managed folder contains local items, it is skipped to prevent accidental deletion of custom work.\n- **Logging:** Provides clear messages about which managed items are being removed.\n",
+      "description": "\n## Command Behavior\n\n**Removes unwanted managed package items from your Salesforce DX project sources.**\n\nThis command helps clean up your local Salesforce project by deleting metadata files that belong to a specific managed package namespace. This is particularly useful when you retrieve metadata from an org that contains managed packages, and you only want to keep the unmanaged or custom metadata in your local repository.\n\nKey functionalities:\n\n- **Namespace-Based Filtering:** Requires a `--namespace` flag to specify which managed package namespace's files should be removed.\n- **Targeted File Deletion:** Scans for files and folders that start with the specified namespace prefix (e.g., `yourNamespace__*`).\n- **Intelligent Folder Handling:** Prevents the deletion of managed folders if they contain local custom items. This ensures that if you have custom metadata within a managed package's folder structure, only the managed components are removed, preserving your local customizations.\n- **Object Metadata Preservation:** Specifically, it will not remove .object-meta.xml files if there are local custom items defined within that object's folder.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Namespace Validation:** Ensures that a namespace is provided, throwing an `SfError` if it's missing.\n- **File Discovery:** Uses `glob` to find all files and directories within the specified `folder` (defaults to `force-app`) that match the managed package namespace pattern (`**/${this.namespace}__*`).\n- **Folder Content Check:** For identified managed folders, the `folderContainsLocalItems` function is called. This function uses `glob` again to check for the presence of any files within that folder that *do not* start with the managed package namespace, indicating local customizations.\n- **Conditional Deletion:** Based on the `folderContainsLocalItems` check, it conditionally removes files and folders using `fs.remove`. If a managed folder contains local items, it is skipped to prevent accidental deletion of custom work.\n- **Logging:** Provides clear messages about which managed items are being removed.\n</details>\n",
       "examples": [
         "$ sf hardis:project:clean:manageditems --namespace crta"
       ],
@@ -10226,7 +10362,7 @@
     "hardis:project:clean:orgmissingitems": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Cleans Salesforce DX project sources by removing metadata components that are not present in a target Salesforce org or the local `package.xml` file.**\n\nThis command helps maintain a lean and accurate codebase by identifying and removing metadata that is either obsolete in the target org or not explicitly included in your project's `package.xml`. This is particularly useful for:\n\n- **Reducing Deployment Size:** Eliminating unnecessary metadata reduces the size of deployments, leading to faster deployments and fewer conflicts.\n- **Ensuring Consistency:** Synchronizing your local codebase with the actual state of a Salesforce org.\n- **Cleaning Up Orphaned Metadata:** Removing components that might have been deleted from the org but still exist in your local project.\n\nKey features:\n\n- **Target Org Integration:** Connects to a specified Salesforce org (or prompts for one) to retrieve its metadata manifest.\n- **`package.xml` Comparison:** Compares your local project's metadata with the target org's metadata and your local `package.xml` to identify missing items.\n- **Report Type Cleaning:** Specifically targets and cleans `reportType-meta.xml` files by removing references to fields or objects that are not present in the target org or your `package.xml`.\n\n## Technical explanations\n\nThe command's technical implementation involves several steps:\n\n- **Org Manifest Generation:** If not provided, it generates a full `package.xml` from the target Salesforce org using `buildOrgManifest`.\n- **XML Parsing and Merging:** It parses the generated org manifest and merges it with the local `package.xml` and `destructiveChanges.xml` files to create a comprehensive list of existing and deleted metadata.\n- **Metadata Analysis:** It iterates through specific metadata types (currently `reportType-meta.xml` files) within the configured source folder.\n- **Field and Object Validation:** For each `reportType-meta.xml` file, it examines the columns and filters out references to custom fields or objects that are not found in the merged `package.xml` content or are marked for destruction.\n- **XML Modification:** If changes are detected, it updates the `reportType-meta.xml` file by writing the modified XML content back to the file using `writeXmlFile`.\n- **File System Operations:** It uses `fs-extra` for file system operations and `glob` for pattern matching to find relevant metadata files.\n- **SOQL Queries:** The `buildOrgManifest` utility (used internally) performs SOQL queries to retrieve metadata information from the Salesforce org.\n",
+      "description": "\n## Command Behavior\n\n**Cleans Salesforce DX project sources by removing metadata components that are not present in a target Salesforce org or the local `package.xml` file.**\n\nThis command helps maintain a lean and accurate codebase by identifying and removing metadata that is either obsolete in the target org or not explicitly included in your project's `package.xml`. This is particularly useful for:\n\n- **Reducing Deployment Size:** Eliminating unnecessary metadata reduces the size of deployments, leading to faster deployments and fewer conflicts.\n- **Ensuring Consistency:** Synchronizing your local codebase with the actual state of a Salesforce org.\n- **Cleaning Up Orphaned Metadata:** Removing components that might have been deleted from the org but still exist in your local project.\n\nKey features:\n\n- **Target Org Integration:** Connects to a specified Salesforce org (or prompts for one) to retrieve its metadata manifest.\n- **`package.xml` Comparison:** Compares your local project's metadata with the target org's metadata and your local `package.xml` to identify missing items.\n- **Report Type Cleaning:** Specifically targets and cleans `reportType-meta.xml` files by removing references to fields or objects that are not present in the target org or your `package.xml`.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves several steps:\n\n- **Org Manifest Generation:** If not provided, it generates a full `package.xml` from the target Salesforce org using `buildOrgManifest`.\n- **XML Parsing and Merging:** It parses the generated org manifest and merges it with the local `package.xml` and `destructiveChanges.xml` files to create a comprehensive list of existing and deleted metadata.\n- **Metadata Analysis:** It iterates through specific metadata types (currently `reportType-meta.xml` files) within the configured source folder.\n- **Field and Object Validation:** For each `reportType-meta.xml` file, it examines the columns and filters out references to custom fields or objects that are not found in the merged `package.xml` content or are marked for destruction.\n- **XML Modification:** If changes are detected, it updates the `reportType-meta.xml` file by writing the modified XML content back to the file using `writeXmlFile`.\n- **File System Operations:** It uses `fs-extra` for file system operations and `glob` for pattern matching to find relevant metadata files.\n- **SOQL Queries:** The `buildOrgManifest` utility (used internally) performs SOQL queries to retrieve metadata information from the Salesforce org.\n</details>\n",
       "examples": [
         "$ sf hardis:project:clean:orgmissingitems"
       ],
@@ -10342,7 +10478,7 @@
     "hardis:project:clean:references": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Removes unwanted references and cleans up metadata within your Salesforce DX project sources.**\n\nThis command provides a powerful way to maintain a clean and efficient Salesforce codebase by eliminating unnecessary or problematic metadata. It supports various cleaning types, from removing hardcoded user references in dashboards to minimizing profile attributes.\n\nKey functionalities include:\n\n- **Configurable Cleaning Types:** You can specify a particular cleaning type (e.g., \n- **JSON/XML Configuration:** Cleaning operations can be driven by a JSON configuration file or a \n- **Interactive Selection:** If no cleaning type is specified, the command interactively prompts you to select which references to clean.\n- **Persistent Configuration:** You can choose to save your cleaning selections in your project's configuration (`.sfdx-hardis.yml`) so they are automatically applied during future Work Save operations.\n- **File Deletion:** Beyond just cleaning XML content, it can also delete related files (e.g., custom field files and their translations when a custom field is marked for deletion).\n\n## Technical explanations\n\nThe command's technical implementation involves several steps:\n\n- **Configuration Loading:** It reads the project's configuration to determine default cleaning types and user preferences.\n- **Cleaning Type Processing:** For each selected cleaning type, it either executes a dedicated sub-command (e.g., \n- **XML Filtering:** For template-based cleanings, it constructs a temporary JSON configuration file based on predefined templates or user-provided \n- **Package.xml Cleanup:** It iterates through \n- **Object Property Removal:** The \n",
+      "description": "\n## Command Behavior\n\n**Removes unwanted references and cleans up metadata within your Salesforce DX project sources.**\n\nThis command provides a powerful way to maintain a clean and efficient Salesforce codebase by eliminating unnecessary or problematic metadata. It supports various cleaning types, from removing hardcoded user references in dashboards to minimizing profile attributes.\n\nKey functionalities include:\n\n- **Configurable Cleaning Types:** You can specify a particular cleaning type (e.g., \n- **JSON/XML Configuration:** Cleaning operations can be driven by a JSON configuration file or a \n- **Interactive Selection:** If no cleaning type is specified, the command interactively prompts you to select which references to clean.\n- **Persistent Configuration:** You can choose to save your cleaning selections in your project's configuration (`.sfdx-hardis.yml`) so they are automatically applied during future Work Save operations.\n- **File Deletion:** Beyond just cleaning XML content, it can also delete related files (e.g., custom field files and their translations when a custom field is marked for deletion).\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves several steps:\n\n- **Configuration Loading:** It reads the project's configuration to determine default cleaning types and user preferences.\n- **Cleaning Type Processing:** For each selected cleaning type, it either executes a dedicated sub-command (e.g., \n- **XML Filtering:** For template-based cleanings, it constructs a temporary JSON configuration file based on predefined templates or user-provided \n- **Package.xml Cleanup:** It iterates through \n- **Object Property Removal:** The \n</details>\n",
       "examples": [
         "$ sf hardis:project:clean:references",
         "$ sf hardis:project:clean:references --type all",
@@ -10465,7 +10601,7 @@
     "hardis:project:clean:retrievefolders": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Retrieves specific folders of Dashboards, Documents, Email Templates, and Reports from a Salesforce org into your DX project sources.**\n\nThis command is designed to help developers and administrators synchronize their local Salesforce DX project with the latest versions of these folder-based metadata types. It's particularly useful for:\n\n- **Selective Retrieval:** Instead of retrieving all dashboards or reports, it allows you to retrieve specific folders, which can be more efficient for targeted development or backup.\n- **Maintaining Folder Structure:** Ensures that the folder structure of these metadata types is preserved in your local project.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Folder Iteration:** It defines a list of folder-based metadata types (`dashboards`, `documents`, `email`, `reports`).\n- **File System Check:** For each type, it checks if the corresponding folder exists in `force-app/main/default/`.\n- **Recursive Retrieval:** It iterates through subfolders within these main folders. For each subfolder, it constructs and executes a `sf project retrieve start` command.\n- **Salesforce CLI Integration:** It uses `sf project retrieve start -m <MetadataType>:<FolderName>` to retrieve the content of individual folders. This ensures that only the specified folder and its contents are retrieved.\n- **Error Handling:** It includes basic error handling for the `execCommand` calls.\n",
+      "description": "\n## Command Behavior\n\n**Retrieves specific folders of Dashboards, Documents, Email Templates, and Reports from a Salesforce org into your DX project sources.**\n\nThis command is designed to help developers and administrators synchronize their local Salesforce DX project with the latest versions of these folder-based metadata types. It's particularly useful for:\n\n- **Selective Retrieval:** Instead of retrieving all dashboards or reports, it allows you to retrieve specific folders, which can be more efficient for targeted development or backup.\n- **Maintaining Folder Structure:** Ensures that the folder structure of these metadata types is preserved in your local project.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Folder Iteration:** It defines a list of folder-based metadata types (`dashboards`, `documents`, `email`, `reports`).\n- **File System Check:** For each type, it checks if the corresponding folder exists in `force-app/main/default/`.\n- **Recursive Retrieval:** It iterates through subfolders within these main folders. For each subfolder, it constructs and executes a `sf project retrieve start` command.\n- **Salesforce CLI Integration:** It uses `sf project retrieve start -m <MetadataType>:<FolderName>` to retrieve the content of individual folders. This ensures that only the specified folder and its contents are retrieved.\n- **Error Handling:** It includes basic error handling for the `execCommand` calls.\n</details>\n",
       "examples": [
         "$ sf hardis:project:clean:retrievefolders"
       ],
@@ -10671,7 +10807,7 @@
     "hardis:project:clean:standarditems": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Removes unwanted standard Salesforce items from your Salesforce DX project sources.**\n\nThis command helps maintain a clean and focused Salesforce codebase by deleting metadata files that represent standard Salesforce objects or fields, especially when they are retrieved but not intended to be managed in your version control system. This is useful for reducing repository size and avoiding conflicts with standard Salesforce metadata.\n\nKey functionalities:\n\n- **Standard Object Cleaning:** Scans for standard objects (those without a `__c` suffix) within your `force-app/main/default/objects` folder.\n- **Conditional Folder Deletion:** If a standard object folder contains no custom fields (fields with a `__c` suffix), the entire folder and its associated sharing rules (`.sharingRules-meta.xml`) are removed.\n- **Standard Field Deletion:** If a standard object folder *does* contain custom fields, only the standard fields within that object are removed, preserving your custom metadata.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **File System Traversal:** It starts by listing the contents of the `force-app/main/default/objects` directory.\n- **Standard Object Identification:** It iterates through each directory within `objects` and identifies standard objects by checking if their name does not contain `__` (the custom object suffix).\n- **Custom Field Detection:** For each standard object, it uses `glob` to search for custom fields (`*__*.field-meta.xml`) within its `fields` subdirectory.\n- **Conditional Removal:**\n  - If no custom fields are found, it removes the entire object directory and any corresponding sharing rules file using `fs.remove`.\n  - If custom fields are found, it then uses `glob` again to find all standard fields (`*.field-meta.xml` without `__`) within the object's `fields` directory and removes only those standard field files.\n- **Logging:** Provides clear messages about which folders and files are being removed or kept.\n",
+      "description": "\n## Command Behavior\n\n**Removes unwanted standard Salesforce items from your Salesforce DX project sources.**\n\nThis command helps maintain a clean and focused Salesforce codebase by deleting metadata files that represent standard Salesforce objects or fields, especially when they are retrieved but not intended to be managed in your version control system. This is useful for reducing repository size and avoiding conflicts with standard Salesforce metadata.\n\nKey functionalities:\n\n- **Standard Object Cleaning:** Scans for standard objects (those without a `__c` suffix) within your `force-app/main/default/objects` folder.\n- **Conditional Folder Deletion:** If a standard object folder contains no custom fields (fields with a `__c` suffix), the entire folder and its associated sharing rules (`.sharingRules-meta.xml`) are removed.\n- **Standard Field Deletion:** If a standard object folder *does* contain custom fields, only the standard fields within that object are removed, preserving your custom metadata.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **File System Traversal:** It starts by listing the contents of the `force-app/main/default/objects` directory.\n- **Standard Object Identification:** It iterates through each directory within `objects` and identifies standard objects by checking if their name does not contain `__` (the custom object suffix).\n- **Custom Field Detection:** For each standard object, it uses `glob` to search for custom fields (`*__*.field-meta.xml`) within its `fields` subdirectory.\n- **Conditional Removal:**\n  - If no custom fields are found, it removes the entire object directory and any corresponding sharing rules file using `fs.remove`.\n  - If custom fields are found, it then uses `glob` again to find all standard fields (`*.field-meta.xml` without `__`) within the object's `fields` directory and removes only those standard field files.\n- **Logging:** Provides clear messages about which folders and files are being removed or kept.\n</details>\n",
       "examples": [
         "$ sf hardis:project:clean:standarditems"
       ],
@@ -10762,7 +10898,7 @@
     "hardis:project:clean:systemdebug": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Removes or comments out `System.debug()` statements from Apex classes and triggers in your Salesforce DX project.**\n\nThis command helps maintain clean and optimized Apex code by eliminating debug statements that are often left in production code. While `System.debug()` is invaluable during development, it can impact performance and expose sensitive information if left in deployed code.\n\nKey functionalities:\n\n- **Targeted File Scan:** Scans all Apex class (.cls) and trigger (.trigger) files within the specified root folder (defaults to `force-app`).\n- **Conditional Action:**\n  - **Comment Out (default):** By default, it comments out `System.debug()` lines by prepending // to them.\n  - **Delete (`--delete` flag):** If the `--delete` flag is used, it completely removes the lines containing `System.debug()`.\n- **Exclusion:** Lines containing `NOPMD` are ignored, allowing developers to intentionally keep specific debug statements.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **File Discovery:** Uses `glob` to find all Apex class and trigger files.\n- **Content Reading:** Reads the content of each Apex file line by line.\n- **Pattern Matching:** Checks each line for the presence of `System.debug` (case-insensitive).\n- **Line Modification:**\n  - If `System.debug` is found and the `--delete` flag is not used, it modifies the line to comment out the debug statement.\n  - If `System.debug` is found and the `--delete` flag is used, it removes the line entirely.\n- **File Writing:** If any changes are made to a file, the modified content is written back to the file using `fs.writeFile`.\n- **Logging:** Provides a summary of how many files were cleaned.\n",
+      "description": "\n## Command Behavior\n\n**Removes or comments out `System.debug()` statements from Apex classes and triggers in your Salesforce DX project.**\n\nThis command helps maintain clean and optimized Apex code by eliminating debug statements that are often left in production code. While `System.debug()` is invaluable during development, it can impact performance and expose sensitive information if left in deployed code.\n\nKey functionalities:\n\n- **Targeted File Scan:** Scans all Apex class (.cls) and trigger (.trigger) files within the specified root folder (defaults to `force-app`).\n- **Conditional Action:**\n  - **Comment Out (default):** By default, it comments out `System.debug()` lines by prepending // to them.\n  - **Delete (`--delete` flag):** If the `--delete` flag is used, it completely removes the lines containing `System.debug()`.\n- **Exclusion:** Lines containing `NOPMD` are ignored, allowing developers to intentionally keep specific debug statements.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **File Discovery:** Uses `glob` to find all Apex class and trigger files.\n- **Content Reading:** Reads the content of each Apex file line by line.\n- **Pattern Matching:** Checks each line for the presence of `System.debug` (case-insensitive).\n- **Line Modification:**\n  - If `System.debug` is found and the `--delete` flag is not used, it modifies the line to comment out the debug statement.\n  - If `System.debug` is found and the `--delete` flag is used, it removes the line entirely.\n- **File Writing:** If any changes are made to a file, the modified content is written back to the file using `fs.writeFile`.\n- **Logging:** Provides a summary of how many files were cleaned.\n</details>\n",
       "examples": [
         "$ sf hardis:project:clean:systemdebug"
       ],
@@ -10991,6 +11127,109 @@
         "xml:clean:project:hardis"
       ]
     },
+    "hardis:project:convert:profilestopermsets": {
+      "aliases": [],
+      "args": {},
+      "description": "\n## Command Behavior\n\n**Converts existing Salesforce Profiles into Permission Sets, facilitating a more granular and recommended security model.**\n\nThis command helps in migrating permissions from Profiles to Permission Sets, which is a best practice for managing user access in Salesforce. It creates a new Permission Set for each specified Profile, adopting a naming convention of `PS_PROFILENAME`.\n\nKey functionalities:\n\n- **Profile to Permission Set Conversion:** Automatically extracts permissions from a Profile and creates a corresponding Permission Set.\n- **Naming Convention:** New Permission Sets are named with a `PS_` prefix followed by the Profile name (e.g., `PS_Standard_User`).\n- **Exclusion Filter:** Allows you to exclude specific Profiles from the conversion process using the `--except` flag.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **External Plugin Integration:** It relies on the `shane-sfdx-plugins` (specifically the `sf shane:profile:convert` command) to perform the actual conversion.\n- **File System Scan:** It reads the contents of the `force-app/main/default/profiles` directory to identify all available Profile metadata files.\n- **Command Execution:** For each identified Profile (that is not excluded), it constructs and executes the `sf shane:profile:convert` command with the appropriate Profile name and desired Permission Set name.\n- **Error Handling:** Includes basic error handling for the external command execution.\n</details>\n",
+      "examples": [
+        "$ sf hardis:project:convert:profilestopermsets"
+      ],
+      "flags": {
+        "json": {
+          "description": "Format output as json.",
+          "helpGroup": "GLOBAL",
+          "name": "json",
+          "allowNo": false,
+          "type": "boolean"
+        },
+        "flags-dir": {
+          "helpGroup": "GLOBAL",
+          "name": "flags-dir",
+          "summary": "Import flag values from a directory.",
+          "hasDynamicHelp": false,
+          "multiple": false,
+          "type": "option"
+        },
+        "except": {
+          "char": "e",
+          "description": "List of filters",
+          "name": "except",
+          "default": [],
+          "hasDynamicHelp": false,
+          "multiple": true,
+          "type": "option"
+        },
+        "debug": {
+          "char": "d",
+          "description": "Activate debug mode (more logs)",
+          "name": "debug",
+          "allowNo": false,
+          "type": "boolean"
+        },
+        "websocket": {
+          "description": "Websocket host:port for VsCode SFDX Hardis UI integration",
+          "name": "websocket",
+          "hasDynamicHelp": false,
+          "multiple": false,
+          "type": "option"
+        },
+        "skipauth": {
+          "description": "Skip authentication check when a default username is required",
+          "name": "skipauth",
+          "allowNo": false,
+          "type": "boolean"
+        }
+      },
+      "hasDynamicHelp": false,
+      "hiddenAliases": [],
+      "id": "hardis:project:convert:profilestopermsets",
+      "pluginAlias": "sfdx-hardis",
+      "pluginName": "sfdx-hardis",
+      "pluginType": "core",
+      "strict": true,
+      "enableJsonFlag": true,
+      "title": "Convert Profiles into Permission Sets",
+      "requiresProject": true,
+      "requiresSfdxPlugins": [
+        "shane-sfdx-plugins"
+      ],
+      "isESM": true,
+      "relativePath": [
+        "lib",
+        "commands",
+        "hardis",
+        "project",
+        "convert",
+        "profilestopermsets.js"
+      ],
+      "aliasPermutations": [],
+      "permutations": [
+        "hardis:project:convert:profilestopermsets",
+        "project:hardis:convert:profilestopermsets",
+        "project:convert:hardis:profilestopermsets",
+        "project:convert:profilestopermsets:hardis",
+        "hardis:convert:project:profilestopermsets",
+        "convert:hardis:project:profilestopermsets",
+        "convert:project:hardis:profilestopermsets",
+        "convert:project:profilestopermsets:hardis",
+        "hardis:convert:profilestopermsets:project",
+        "convert:hardis:profilestopermsets:project",
+        "convert:profilestopermsets:hardis:project",
+        "convert:profilestopermsets:project:hardis",
+        "hardis:project:profilestopermsets:convert",
+        "project:hardis:profilestopermsets:convert",
+        "project:profilestopermsets:hardis:convert",
+        "project:profilestopermsets:convert:hardis",
+        "hardis:profilestopermsets:project:convert",
+        "profilestopermsets:hardis:project:convert",
+        "profilestopermsets:project:hardis:convert",
+        "profilestopermsets:project:convert:hardis",
+        "hardis:profilestopermsets:convert:project",
+        "profilestopermsets:hardis:convert:project",
+        "profilestopermsets:convert:hardis:project",
+        "profilestopermsets:convert:project:hardis"
+      ]
+    },
     "hardis:project:deploy:notify": {
       "aliases": [],
       "args": {},
@@ -11275,7 +11514,7 @@
     "hardis:project:deploy:simulate": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Simulates the deployment of Salesforce metadata to a target org, primarily used by the VS Code Extension for quick validation.**\n\nThis command allows developers to perform a dry run of a metadata deployment without actually committing changes to the Salesforce org. This is incredibly useful for:\n\n- **Pre-Deployment Validation:** Identifying potential errors, warnings, or conflicts before a full deployment.\n- **Troubleshooting:** Quickly testing metadata changes and debugging issues in a safe environment.\n- **Local Development:** Validating changes to individual metadata components (e.g., a Permission Set) without needing to run a full CI/CD pipeline.\n\nKey functionalities:\n\n- **Source Specification:** Takes a source file or directory (`--source-dir`) containing the metadata to be simulated.\n- **Target Org Selection:** Prompts the user to select a Salesforce org for the simulation. This allows for flexible testing across different environments.\n- **Dry Run Execution:** Executes the Salesforce CLI's `sf project deploy start --dry-run` command, which performs all validation steps but does not save any changes to the org.\n\nThis command is primarily used by the VS Code Extension to provide immediate feedback to developers.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Interactive Org Prompt:** Uses `promptOrgUsernameDefault` to allow the user to select the target Salesforce org for the deployment simulation.\n- **Salesforce CLI Integration:** It constructs and executes the `sf project deploy start` command with the `--dry-run` and `--ignore-conflicts` flags. The `--source-dir` and `--target-org` flags are dynamically populated based on user input.\n- **`wrapSfdxCoreCommand`:** This utility is used to execute the Salesforce CLI command and capture its output.\n- **Connection Variables:** Ensures Salesforce connection variables are set using `setConnectionVariables`.\n",
+      "description": "\n## Command Behavior\n\n**Simulates the deployment of Salesforce metadata to a target org, primarily used by the VS Code Extension for quick validation.**\n\nThis command allows developers to perform a dry run of a metadata deployment without actually committing changes to the Salesforce org. This is incredibly useful for:\n\n- **Pre-Deployment Validation:** Identifying potential errors, warnings, or conflicts before a full deployment.\n- **Troubleshooting:** Quickly testing metadata changes and debugging issues in a safe environment.\n- **Local Development:** Validating changes to individual metadata components (e.g., a Permission Set) without needing to run a full CI/CD pipeline.\n\nKey functionalities:\n\n- **Source Specification:** Takes a source file or directory (`--source-dir`) containing the metadata to be simulated.\n- **Target Org Selection:** Prompts the user to select a Salesforce org for the simulation. This allows for flexible testing across different environments.\n- **Dry Run Execution:** Executes the Salesforce CLI's `sf project deploy start --dry-run` command, which performs all validation steps but does not save any changes to the org.\n\nThis command is primarily used by the VS Code Extension to provide immediate feedback to developers.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Interactive Org Prompt:** Uses `promptOrgUsernameDefault` to allow the user to select the target Salesforce org for the deployment simulation.\n- **Salesforce CLI Integration:** It constructs and executes the `sf project deploy start` command with the `--dry-run` and `--ignore-conflicts` flags. The `--source-dir` and `--target-org` flags are dynamically populated based on user input.\n- **`wrapSfdxCoreCommand`:** This utility is used to execute the Salesforce CLI command and capture its output.\n- **Connection Variables:** Ensures Salesforce connection variables are set using `setConnectionVariables`.\n</details>\n",
       "examples": [
         "$ sf hardis:project:deploy:simulate --source-dir force-app/defaut/main/permissionset/PS_Admin.permissionset-meta.xml"
       ],
@@ -12169,7 +12408,7 @@
     "hardis:project:fix:profiletabs": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Interactively updates tab visibility settings in Salesforce profiles, addressing a common issue where tab visibilities are not correctly retrieved by `sf project retrieve start`.**\n\nThis command provides a user-friendly interface to manage tab settings within your profile XML files, ensuring that your local project accurately reflects the intended tab configurations in your Salesforce org.\n\nKey functionalities:\n\n- **Interactive Tab Selection:** Displays a multi-select menu of all available tabs in your org, allowing you to choose which tabs to update.\n- **Visibility Control:** Lets you set the visibility for the selected tabs to either `DefaultOn` (Visible) or `Hidden`.\n- **Profile Selection:** Presents a multi-select menu of all .profile-meta.xml files in your project, allowing you to apply the tab visibility changes to specific profiles.\n- **XML Updates:** Modifies the <tabVisibilities> section of the selected profile XML files to reflect the chosen tab settings. If a tab visibility setting already exists for a selected tab, it will be updated; otherwise, a new one will be added.\n- **Sorted Output:** The <tabVisibilities> in the updated profile XML files are sorted alphabetically for consistency and readability.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **SOQL Queries (Tooling API):** It queries the `TabDefinition` object using `soqlQueryTooling` to retrieve a list of all available tabs in the target org.\n- **File Discovery:** Uses `glob` to find all .profile-meta.xml files within the specified project path.\n- **Interactive Prompts:** Leverages the `prompts` library to create interactive menus for selecting tabs, visibility settings, and profiles.\n- **XML Parsing and Manipulation:** Uses `parseXmlFile` to read the content of profile XML files and `writeXmlFile` to write the modified content back. It manipulates the `tabVisibilities` array within the parsed XML to add or update tab settings.\n- **Array Sorting:** Employs the `sort-array` library to sort the `tabVisibilities` alphabetically by tab name.\n- **Logging:** Provides feedback to the user about which profiles have been updated and a summary of the changes.\n",
+      "description": "\n## Command Behavior\n\n**Interactively updates tab visibility settings in Salesforce profiles, addressing a common issue where tab visibilities are not correctly retrieved by `sf project retrieve start`.**\n\nThis command provides a user-friendly interface to manage tab settings within your profile XML files, ensuring that your local project accurately reflects the intended tab configurations in your Salesforce org.\n\nKey functionalities:\n\n- **Interactive Tab Selection:** Displays a multi-select menu of all available tabs in your org, allowing you to choose which tabs to update.\n- **Visibility Control:** Lets you set the visibility for the selected tabs to either `DefaultOn` (Visible) or `Hidden`.\n- **Profile Selection:** Presents a multi-select menu of all .profile-meta.xml files in your project, allowing you to apply the tab visibility changes to specific profiles.\n- **XML Updates:** Modifies the <tabVisibilities> section of the selected profile XML files to reflect the chosen tab settings. If a tab visibility setting already exists for a selected tab, it will be updated; otherwise, a new one will be added.\n- **Sorted Output:** The <tabVisibilities> in the updated profile XML files are sorted alphabetically for consistency and readability.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **SOQL Queries (Tooling API):** It queries the `TabDefinition` object using `soqlQueryTooling` to retrieve a list of all available tabs in the target org.\n- **File Discovery:** Uses `glob` to find all .profile-meta.xml files within the specified project path.\n- **Interactive Prompts:** Leverages the `prompts` library to create interactive menus for selecting tabs, visibility settings, and profiles.\n- **XML Parsing and Manipulation:** Uses `parseXmlFile` to read the content of profile XML files and `writeXmlFile` to write the modified content back. It manipulates the `tabVisibilities` array within the parsed XML to add or update tab settings.\n- **Array Sorting:** Employs the `sort-array` library to sort the `tabVisibilities` alphabetically by tab name.\n- **Logging:** Provides feedback to the user about which profiles have been updated and a summary of the changes.\n</details>\n",
       "examples": [
         "$ sf hardis:project:fix:profiletabs"
       ],
@@ -12284,7 +12523,7 @@
     "hardis:project:fix:v53flexipages": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Fixes Salesforce FlexiPages for compatibility with API Version 53.0 (Winter '22 release) by adding missing identifiers to component instances.**\n\nSalesforce introduced a change in API Version 53.0 that requires `identifier` tags within `componentInstance` and `fieldInstance` elements in FlexiPage metadata. If these identifiers are missing, deployments to orgs with API version 53.0 or higher will fail. This command automates the process of adding these missing identifiers, ensuring your FlexiPages remain deployable.\n\nKey functionalities:\n\n- **Targeted FlexiPage Processing:** Scans all .flexipage-meta.xml files within the specified root folder (defaults to current working directory).\n- **Identifier Injection:** Inserts a unique `identifier` tag (e.g., `SFDX_HARDIS_REPLACEMENT_ID`) into `componentInstance` and `fieldInstance` elements that lack one.\n\n**Important Note:** After running this command, ensure you update your `apiVersion` to `53.0` (or higher) in your `package.xml` and `sfdx-project.json` files.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **File Discovery:** Uses `glob` to find all .flexipage-meta.xml files.\n- **Content Reading:** Reads the XML content of each FlexiPage file.\n- **Regular Expression Replacement:** Employs a set of regular expressions to identify specific XML patterns (componentName.../componentName.../componentInstance, componentName.../componentName.../visibilityRule, fieldItem.../fieldItem.../fieldInstance) that are missing the `identifier` tag.\n- **Dynamic ID Generation:** For each match, it generates a unique identifier (e.g., `sfdxHardisIdX`) and injects it into the XML structure.\n- **File Writing:** If changes are made, the modified XML content is written back to the FlexiPage file using `fs.writeFile`.\n- **Logging:** Provides messages about which FlexiPages are being processed and a summary of the total number of identifiers added.\n",
+      "description": "\n## Command Behavior\n\n**Fixes Salesforce FlexiPages for compatibility with API Version 53.0 (Winter '22 release) by adding missing identifiers to component instances.**\n\nSalesforce introduced a change in API Version 53.0 that requires `identifier` tags within `componentInstance` and `fieldInstance` elements in FlexiPage metadata. If these identifiers are missing, deployments to orgs with API version 53.0 or higher will fail. This command automates the process of adding these missing identifiers, ensuring your FlexiPages remain deployable.\n\nKey functionalities:\n\n- **Targeted FlexiPage Processing:** Scans all .flexipage-meta.xml files within the specified root folder (defaults to current working directory).\n- **Identifier Injection:** Inserts a unique `identifier` tag (e.g., `SFDX_HARDIS_REPLACEMENT_ID`) into `componentInstance` and `fieldInstance` elements that lack one.\n\n**Important Note:** After running this command, ensure you update your `apiVersion` to `53.0` (or higher) in your `package.xml` and `sfdx-project.json` files.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **File Discovery:** Uses `glob` to find all .flexipage-meta.xml files.\n- **Content Reading:** Reads the XML content of each FlexiPage file.\n- **Regular Expression Replacement:** Employs a set of regular expressions to identify specific XML patterns (componentName.../componentName.../componentInstance, componentName.../componentName.../visibilityRule, fieldItem.../fieldItem.../fieldInstance) that are missing the `identifier` tag.\n- **Dynamic ID Generation:** For each match, it generates a unique identifier (e.g., `sfdxHardisIdX`) and injects it into the XML structure.\n- **File Writing:** If changes are made, the modified XML content is written back to the FlexiPage file using `fs.writeFile`.\n- **Logging:** Provides messages about which FlexiPages are being processed and a summary of the total number of identifiers added.\n</details>\n",
       "examples": [
         "$ sf hardis:project:fix:v53flexipages"
       ],
@@ -12384,7 +12623,7 @@
     "hardis:project:generate:bypass": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Generates custom permissions and permission sets to bypass specified Salesforce automations (Flows, Triggers, and Validation Rules) for specific sObjects.**\n\nThis command provides a controlled mechanism to temporarily or permanently disable automations for certain sObjects, which is invaluable for:\n\n- **Data Loading:** Bypassing validation rules or triggers during large data imports.\n- **Troubleshooting:** Isolating automation issues by temporarily disabling them.\n- **Development:** Allowing developers to work on specific sObjects without triggering complex automations.\n\nKey functionalities:\n\n- **sObject Selection:** You can specify a comma-separated list of sObjects to bypass (e.g., `Account,Contact`). If omitted, an interactive prompt will allow you to select from available sObjects.\n- **Automation Type Selection:** Choose which types of automations to bypass: `Flow`, `Trigger`, or `VR` (Validation Rules). If omitted, an interactive prompt will guide your selection.\n- **Automatic Bypass Application:** Optionally, the command can automatically inject bypass logic into Validation Rules and Triggers. This involves modifying the Apex code for Triggers and the XML for Validation Rules.\n- **Metadata Source:** You can choose to retrieve the metadata elements (Validation Rules, Triggers) from the org (`--metadata-source org`) or use local files (`--metadata-source local`). Retrieving from the org is recommended for accuracy.\n- **Custom Permission and Permission Set Generation:** For each selected sObject and automation type, it generates:\n  - A **Custom Permission** (e.g., `BypassAccountFlows`) that acts as the bypass switch.\n  - A **Permission Set** (e.g., `BypassAccountFlows`) that grants the generated Custom Permission.\n- **Credits Inclusion:** By default, generated XML files include a comment indicating they were generated by sfdx-hardis. This can be skipped using `--skip-credits`.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **SOQL Queries (Tooling API):** It queries `EntityDefinition` to list customizable sObjects and `ValidationRule` and `ApexTrigger` to find existing automations.\n- **Interactive Prompts:** Uses the `prompts` library to guide the user through selecting sObjects, automation types, and bypass application options.\n- **XML Generation:** Dynamically generates XML content for Custom Permissions and Permission Sets, including descriptions and labels that clearly indicate their purpose.\n- **File System Operations:** Uses `fs-extra` to create directories and write the generated Custom Permission and Permission Set XML files.\n- **Metadata Retrieval (for Bypass Application):** If `apply-to-vrs` or `apply-to-triggers` is used and `metadata-source` is `org`, it retrieves the relevant Validation Rule or Apex Trigger metadata from the org using `sf project retrieve start`.\n- **XML/Apex Code Modification:**\n  - For Validation Rules, it modifies the `errorConditionFormula` in the XML to include a check for the bypass Custom Permission.\n  - For Apex Triggers, it injects an `if` statement at the beginning of the trigger body to check for the bypass Custom Permission.\n- **`parseXmlFile` and `writeXmlFile`:** Used for reading and writing XML metadata files.\n- **`execCommand`:** Used for executing Salesforce CLI commands, particularly for metadata retrieval.\n- **Error Handling:** Includes checks for invalid sObject or automation selections and provides informative error messages.\n",
+      "description": "\n## Command Behavior\n\n**Generates custom permissions and permission sets to bypass specified Salesforce automations (Flows, Triggers, and Validation Rules) for specific sObjects.**\n\nThis command provides a controlled mechanism to temporarily or permanently disable automations for certain sObjects, which is invaluable for:\n\n- **Data Loading:** Bypassing validation rules or triggers during large data imports.\n- **Troubleshooting:** Isolating automation issues by temporarily disabling them.\n- **Development:** Allowing developers to work on specific sObjects without triggering complex automations.\n\nKey functionalities:\n\n- **sObject Selection:** You can specify a comma-separated list of sObjects to bypass (e.g., `Account,Contact`). If omitted, an interactive prompt will allow you to select from available sObjects.\n- **Automation Type Selection:** Choose which types of automations to bypass: `Flow`, `Trigger`, or `VR` (Validation Rules). If omitted, an interactive prompt will guide your selection.\n- **Automatic Bypass Application:** Optionally, the command can automatically inject bypass logic into Validation Rules and Triggers. This involves modifying the Apex code for Triggers and the XML for Validation Rules.\n- **Metadata Source:** You can choose to retrieve the metadata elements (Validation Rules, Triggers) from the org (`--metadata-source org`) or use local files (`--metadata-source local`). Retrieving from the org is recommended for accuracy.\n- **Custom Permission and Permission Set Generation:** For each selected sObject and automation type, it generates:\n  - A **Custom Permission** (e.g., `BypassAccountFlows`) that acts as the bypass switch.\n  - A **Permission Set** (e.g., `BypassAccountFlows`) that grants the generated Custom Permission.\n- **Credits Inclusion:** By default, generated XML files include a comment indicating they were generated by sfdx-hardis. This can be skipped using `--skip-credits`.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **SOQL Queries (Tooling API):** It queries `EntityDefinition` to list customizable sObjects and `ValidationRule` and `ApexTrigger` to find existing automations.\n- **Interactive Prompts:** Uses the `prompts` library to guide the user through selecting sObjects, automation types, and bypass application options.\n- **XML Generation:** Dynamically generates XML content for Custom Permissions and Permission Sets, including descriptions and labels that clearly indicate their purpose.\n- **File System Operations:** Uses `fs-extra` to create directories and write the generated Custom Permission and Permission Set XML files.\n- **Metadata Retrieval (for Bypass Application):** If `apply-to-vrs` or `apply-to-triggers` is used and `metadata-source` is `org`, it retrieves the relevant Validation Rule or Apex Trigger metadata from the org using `sf project retrieve start`.\n- **XML/Apex Code Modification:**\n  - For Validation Rules, it modifies the `errorConditionFormula` in the XML to include a check for the bypass Custom Permission.\n  - For Apex Triggers, it injects an `if` statement at the beginning of the trigger body to check for the bypass Custom Permission.\n- **`parseXmlFile` and `writeXmlFile`:** Used for reading and writing XML metadata files.\n- **`execCommand`:** Used for executing Salesforce CLI commands, particularly for metadata retrieval.\n- **Error Handling:** Includes checks for invalid sObject or automation selections and provides informative error messages.\n</details>\n",
       "examples": [
         "$ sf hardis:project:generate:bypass",
         "$ sf hardis:project:generate:bypass --sObjects Account,Contact,Opportunity",
@@ -12667,7 +12906,7 @@
     "hardis:project:generate:gitdelta": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Generates a `package.xml` and `destructiveChanges.xml` representing the metadata differences between two Git commits.**\n\nThis command is a powerful tool for managing Salesforce metadata deployments by focusing only on the changes between specific points in your version control history. It leverages `sfdx-git-delta` to accurately identify added, modified, and deleted metadata components.\n\nKey functionalities:\n\n- **Commit-Based Comparison:** Allows you to specify a starting commit (`--fromcommit`) and an ending commit (`--tocommit`) to define the scope of the delta. If not provided, interactive prompts will guide you through selecting commits from your Git history.\n- **Branch Selection:** You can specify a Git branch (`--branch`) to work with. If not provided, it will prompt you to select one.\n- **`package.xml` Generation:** Creates a `package.xml` file that lists all metadata components that have been added or modified between the specified commits.\n- **`destructiveChanges.xml` Generation:** Creates a `destructiveChanges.xml` file that lists all metadata components that have been deleted between the specified commits.\n- **Temporary File Output:** The generated `package.xml` and `destructiveChanges.xml` files are placed in a temporary directory.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Git Integration:** Uses `simple-git` (`git()`) to interact with the Git repository, including fetching branches (`git().fetch()`), checking out branches (`git().checkoutBranch()`), and listing commit history (`git().log()`).\n- **Interactive Prompts:** Leverages the `prompts` library to guide the user through selecting a Git branch and specific commits for delta generation if they are not provided as command-line arguments.\n- **`sfdx-git-delta` Integration:** The core of the delta generation is handled by the `callSfdxGitDelta` utility function, which wraps the `sfdx-git-delta` tool. This tool performs the actual Git comparison and generates the `package.xml` and `destructiveChanges.xml` files.\n- **Temporary Directory Management:** Uses `createTempDir` to create a temporary directory for storing the generated XML files, ensuring a clean working environment.\n- **File System Operations:** Uses `fs-extra` to manage temporary files and directories.\n- **User Feedback:** Provides clear messages to the user about the generated files and their locations.\n",
+      "description": "\n## Command Behavior\n\n**Generates a `package.xml` and `destructiveChanges.xml` representing the metadata differences between two Git commits.**\n\nThis command is a powerful tool for managing Salesforce metadata deployments by focusing only on the changes between specific points in your version control history. It leverages `sfdx-git-delta` to accurately identify added, modified, and deleted metadata components.\n\nKey functionalities:\n\n- **Commit-Based Comparison:** Allows you to specify a starting commit (`--fromcommit`) and an ending commit (`--tocommit`) to define the scope of the delta. If not provided, interactive prompts will guide you through selecting commits from your Git history.\n- **Branch Selection:** You can specify a Git branch (`--branch`) to work with. If not provided, it will prompt you to select one.\n- **`package.xml` Generation:** Creates a `package.xml` file that lists all metadata components that have been added or modified between the specified commits.\n- **`destructiveChanges.xml` Generation:** Creates a `destructiveChanges.xml` file that lists all metadata components that have been deleted between the specified commits.\n- **Temporary File Output:** The generated `package.xml` and `destructiveChanges.xml` files are placed in a temporary directory.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Git Integration:** Uses `simple-git` (`git()`) to interact with the Git repository, including fetching branches (`git().fetch()`), checking out branches (`git().checkoutBranch()`), and listing commit history (`git().log()`).\n- **Interactive Prompts:** Leverages the `prompts` library to guide the user through selecting a Git branch and specific commits for delta generation if they are not provided as command-line arguments.\n- **`sfdx-git-delta` Integration:** The core of the delta generation is handled by the `callSfdxGitDelta` utility function, which wraps the `sfdx-git-delta` tool. This tool performs the actual Git comparison and generates the `package.xml` and `destructiveChanges.xml` files.\n- **Temporary Directory Management:** Uses `createTempDir` to create a temporary directory for storing the generated XML files, ensuring a clean working environment.\n- **File System Operations:** Uses `fs-extra` to manage temporary files and directories.\n- **User Feedback:** Provides clear messages to the user about the generated files and their locations.\n</details>\n",
       "examples": [
         "$ sf hardis:project:generate:gitdelta"
       ],
@@ -12997,7 +13236,7 @@
     "hardis:scratch:pool:localauth": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Authenticates a local user to the configured scratch org pool storage service, enabling them to fetch and manage scratch orgs from the pool.**\n\nThis command is essential for developers who want to utilize a shared scratch org pool for their local development. It establishes the necessary authentication with the backend storage service (e.g., Salesforce Custom Object, Redis) that manages the pool's state, allowing the user to retrieve available scratch orgs for their work.\n\nKey functionalities:\n\n- **Storage Service Authentication:** Initiates the authentication process with the chosen storage service to obtain the required API keys or secrets.\n- **Enables Pool Access:** Once authenticated, the local user can then use other sfdx-hardis commands to fetch, use, and return scratch orgs from the pool.\n- **Configuration Check:** Verifies if a scratch org pool is already configured for the current project and provides guidance if it's not.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Configuration Loading:** It retrieves the `poolConfig` from the project's .sfdx-hardis.yml file to identify the configured storage service.\n- **Provider Instantiation:** It uses the `instantiateProvider` utility function to create an instance of the `KeyValueProviderInterface` corresponding to the configured storage service.\n- **User Authentication:** It then calls the `userAuthenticate()` method on the instantiated provider. This method encapsulates the specific logic for authenticating with the chosen storage service (e.g., prompting for API keys, performing OAuth flows).\n- **Error Handling:** It checks for the absence of a configured scratch org pool and provides a user-friendly message.\n",
+      "description": "\n## Command Behavior\n\n**Authenticates a local user to the configured scratch org pool storage service, enabling them to fetch and manage scratch orgs from the pool.**\n\nThis command is essential for developers who want to utilize a shared scratch org pool for their local development. It establishes the necessary authentication with the backend storage service (e.g., Salesforce Custom Object, Redis) that manages the pool's state, allowing the user to retrieve available scratch orgs for their work.\n\nKey functionalities:\n\n- **Storage Service Authentication:** Initiates the authentication process with the chosen storage service to obtain the required API keys or secrets.\n- **Enables Pool Access:** Once authenticated, the local user can then use other sfdx-hardis commands to fetch, use, and return scratch orgs from the pool.\n- **Configuration Check:** Verifies if a scratch org pool is already configured for the current project and provides guidance if it's not.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Configuration Loading:** It retrieves the `poolConfig` from the project's .sfdx-hardis.yml file to identify the configured storage service.\n- **Provider Instantiation:** It uses the `instantiateProvider` utility function to create an instance of the `KeyValueProviderInterface` corresponding to the configured storage service.\n- **User Authentication:** It then calls the `userAuthenticate()` method on the instantiated provider. This method encapsulates the specific logic for authenticating with the chosen storage service (e.g., prompting for API keys, performing OAuth flows).\n- **Error Handling:** It checks for the absence of a configured scratch org pool and provides a user-friendly message.\n</details>\n",
       "examples": [
         "$ sf hardis:scratch:pool:localauth"
       ],
@@ -13102,7 +13341,7 @@
     "hardis:scratch:pool:refresh": {
       "aliases": [],
       "args": {},
-      "description": "## Command Behavior\n\n**Refreshes a scratch org pool by creating new scratch orgs to fill the pool and deleting expired ones.**\n\nThis command is designed to maintain a healthy and adequately sized scratch org pool, ensuring that developers and CI/CD pipelines always have access to ready-to-use scratch orgs. It automates the lifecycle management of scratch orgs within the pool.\n\nKey functionalities:\n\n- **Expired Org Cleanup:** Identifies and deletes scratch orgs from the pool that are nearing their expiration date (configurable via `minScratchOrgRemainingDays` in `.sfdx-hardis.yml`).\n- **Pool Replenishment:** Creates new scratch orgs to replace expired ones and to reach the `maxScratchOrgsNumber` defined in the pool configuration.\n- **Parallel Creation:** New scratch orgs are created in parallel using child processes, optimizing the replenishment process.\n- **Authentication Handling:** Authenticates to scratch orgs before deletion or creation, ensuring proper access.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Configuration Loading:** It retrieves the `poolConfig` from the project's `.sfdx-hardis.yml` file to get parameters like `maxScratchOrgsNumber`, `maxScratchOrgsNumberToCreateOnce`, and `minScratchOrgRemainingDays`.\n- **Pool Storage Interaction:** It uses `getPoolStorage` and `setPoolStorage` to interact with the configured storage service (e.g., Salesforce Custom Object, Redis) to retrieve and update the list of scratch orgs in the pool.\n- **Expiration Check:** It calculates the remaining days for each scratch org in the pool using moment and flags those below the `minScratchOrgRemainingDays` threshold for deletion.\n- **Scratch Org Deletion:** For expired orgs, it authenticates to them using `authenticateWithSfdxUrlStore` and then executes `sf org delete scratch` via `execCommand`.\n- **Scratch Org Creation:** To replenish the pool, it spawns new child processes that run the `sf hardis:scratch:create --pool` command. This allows for parallel creation of multiple scratch orgs.\n- **Error Handling:** It includes error handling for scratch org creation failures, logging them and updating the pool storage accordingly.\n- **Logging:** Provides detailed logs about the status of scratch orgs (kept, deleted, created, failed creations) and a summary of the refresh operation.\n",
+      "description": "## Command Behavior\n\n**Refreshes a scratch org pool by creating new scratch orgs to fill the pool and deleting expired ones.**\n\nThis command is designed to maintain a healthy and adequately sized scratch org pool, ensuring that developers and CI/CD pipelines always have access to ready-to-use scratch orgs. It automates the lifecycle management of scratch orgs within the pool.\n\nKey functionalities:\n\n- **Expired Org Cleanup:** Identifies and deletes scratch orgs from the pool that are nearing their expiration date (configurable via `minScratchOrgRemainingDays` in `.sfdx-hardis.yml`).\n- **Pool Replenishment:** Creates new scratch orgs to replace expired ones and to reach the `maxScratchOrgsNumber` defined in the pool configuration.\n- **Parallel Creation:** New scratch orgs are created in parallel using child processes, optimizing the replenishment process.\n- **Authentication Handling:** Authenticates to scratch orgs before deletion or creation, ensuring proper access.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Configuration Loading:** It retrieves the `poolConfig` from the project's `.sfdx-hardis.yml` file to get parameters like `maxScratchOrgsNumber`, `maxScratchOrgsNumberToCreateOnce`, and `minScratchOrgRemainingDays`.\n- **Pool Storage Interaction:** It uses `getPoolStorage` and `setPoolStorage` to interact with the configured storage service (e.g., Salesforce Custom Object, Redis) to retrieve and update the list of scratch orgs in the pool.\n- **Expiration Check:** It calculates the remaining days for each scratch org in the pool using moment and flags those below the `minScratchOrgRemainingDays` threshold for deletion.\n- **Scratch Org Deletion:** For expired orgs, it authenticates to them using `authenticateWithSfdxUrlStore` and then executes `sf org delete scratch` via `execCommand`.\n- **Scratch Org Creation:** To replenish the pool, it spawns new child processes that run the `sf hardis:scratch:create --pool` command. This allows for parallel creation of multiple scratch orgs.\n- **Error Handling:** It includes error handling for scratch org creation failures, logging them and updating the pool storage accordingly.\n- **Logging:** Provides detailed logs about the status of scratch orgs (kept, deleted, created, failed creations) and a summary of the refresh operation.\n</details>\n",
       "examples": [
         "$ sf hardis:scratch:pool:refresh"
       ],
@@ -13207,7 +13446,7 @@
     "hardis:scratch:pool:reset": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Resets the scratch org pool by deleting all existing scratch orgs within it.**\n\nThis command provides a way to clear out the entire scratch org pool, effectively starting fresh. This can be useful for:\n\n- **Troubleshooting:** If the pool becomes corrupted or contains problematic scratch orgs.\n- **Major Changes:** When there are significant changes to the scratch org definition or initialization process that require all existing orgs to be recreated.\n- **Cleanup:** Periodically cleaning up the pool to ensure only the latest and most relevant scratch orgs are available.\n\nKey functionalities:\n\n- **Full Pool Deletion:** Identifies all scratch orgs currently in the pool and initiates their deletion.\n- **Dev Hub Integration:** Works with your configured Dev Hub to manage the scratch orgs within the pool.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Configuration Loading:** It retrieves the `poolConfig` from the project's .sfdx-hardis.yml file to ensure a pool is configured.\n- **Pool Storage Interaction:** It uses `getPoolStorage` to retrieve the current list of scratch orgs in the pool and `setPoolStorage` to clear the pool's record.\n- **Scratch Org Deletion:** It iterates through each scratch org in the retrieved list. For each org, it authenticates to it using `authenticateWithSfdxUrlStore` and then executes `sf org delete scratch` via `execCommand`.\n- **Logging:** Provides clear messages about the deletion process and the status of each scratch org.\n",
+      "description": "\n## Command Behavior\n\n**Resets the scratch org pool by deleting all existing scratch orgs within it.**\n\nThis command provides a way to clear out the entire scratch org pool, effectively starting fresh. This can be useful for:\n\n- **Troubleshooting:** If the pool becomes corrupted or contains problematic scratch orgs.\n- **Major Changes:** When there are significant changes to the scratch org definition or initialization process that require all existing orgs to be recreated.\n- **Cleanup:** Periodically cleaning up the pool to ensure only the latest and most relevant scratch orgs are available.\n\nKey functionalities:\n\n- **Full Pool Deletion:** Identifies all scratch orgs currently in the pool and initiates their deletion.\n- **Dev Hub Integration:** Works with your configured Dev Hub to manage the scratch orgs within the pool.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Configuration Loading:** It retrieves the `poolConfig` from the project's .sfdx-hardis.yml file to ensure a pool is configured.\n- **Pool Storage Interaction:** It uses `getPoolStorage` to retrieve the current list of scratch orgs in the pool and `setPoolStorage` to clear the pool's record.\n- **Scratch Org Deletion:** It iterates through each scratch org in the retrieved list. For each org, it authenticates to it using `authenticateWithSfdxUrlStore` and then executes `sf org delete scratch` via `execCommand`.\n- **Logging:** Provides clear messages about the deletion process and the status of each scratch org.\n</details>\n",
       "examples": [
         "$ sf hardis:scratch:pool:refresh"
       ],
@@ -13312,7 +13551,7 @@
     "hardis:scratch:pool:view": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Displays information about the configured scratch org pool, including its current state and available scratch orgs.**\n\nThis command provides visibility into your scratch org pool, allowing you to monitor its health, check the number of available orgs, and verify its configuration. It's a useful tool for administrators and developers managing shared scratch org environments.\n\nKey functionalities:\n\n- **Pool Configuration Display:** Shows the `poolConfig` defined in your \".sfdx-hardis.yml\" file, including the chosen storage service and the maximum number of scratch orgs.\n- **Pool Storage Content:** Displays the raw content of the pool storage, which includes details about each scratch org in the pool (e.g., alias, username, expiration date).\n- **Available Scratch Org Count:** Provides a summary of how many scratch orgs are currently available in the pool.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Configuration Loading:** It retrieves the `poolConfig` from the project's \".sfdx-hardis.yml\" file using `getConfig`.\n- **Pool Storage Retrieval:** It uses `getPoolStorage` to connect to the configured storage service (e.g., Salesforce Custom Object, Redis) and retrieve the current state of the scratch org pool.\n- **Data Display:** It logs the retrieved pool configuration and pool storage content to the console in a human-readable format.\n- **Error Handling:** It checks if a scratch org pool is configured for the project and provides a warning message if it's not.\n",
+      "description": "\n## Command Behavior\n\n**Displays information about the configured scratch org pool, including its current state and available scratch orgs.**\n\nThis command provides visibility into your scratch org pool, allowing you to monitor its health, check the number of available orgs, and verify its configuration. It's a useful tool for administrators and developers managing shared scratch org environments.\n\nKey functionalities:\n\n- **Pool Configuration Display:** Shows the `poolConfig` defined in your \".sfdx-hardis.yml\" file, including the chosen storage service and the maximum number of scratch orgs.\n- **Pool Storage Content:** Displays the raw content of the pool storage, which includes details about each scratch org in the pool (e.g., alias, username, expiration date).\n- **Available Scratch Org Count:** Provides a summary of how many scratch orgs are currently available in the pool.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Configuration Loading:** It retrieves the `poolConfig` from the project's \".sfdx-hardis.yml\" file using `getConfig`.\n- **Pool Storage Retrieval:** It uses `getPoolStorage` to connect to the configured storage service (e.g., Salesforce Custom Object, Redis) and retrieve the current state of the scratch org pool.\n- **Data Display:** It logs the retrieved pool configuration and pool storage content to the console in a human-readable format.\n- **Error Handling:** It checks if a scratch org pool is configured for the project and provides a warning message if it's not.\n</details>\n",
       "examples": [
         "$ sf hardis:scratch:pool:view"
       ],
@@ -13417,7 +13656,7 @@
     "hardis:org:retrieve:sources:analytics": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Retrieves all CRM Analytics (formerly Tableau CRM or Einstein Analytics) sources from a Salesforce org, including workarounds for known SFDX bugs.**\n\nThis command is designed to extract the complete configuration of your CRM Analytics assets, such as dashboards, dataflows, lenses, and recipes. It's essential for version controlling your Analytics development, migrating assets between environments, or backing up your Analytics configurations.\n\nKey functionalities:\n\n- **Comprehensive Retrieval:** Fetches all supported CRM Analytics metadata types.\n- **SFDX Bug Workarounds:** Incorporates internal logic to handle common issues or limitations encountered when retrieving CRM Analytics metadata using standard Salesforce CLI commands.\n- **Target Org Selection:** Allows you to specify the Salesforce org from which to retrieve the Analytics sources. If not provided, it will prompt for selection.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Full Org Manifest Generation:** It first generates a complete `package.xml` for the target org using `buildOrgManifest`. This ensures that all available metadata, including CRM Analytics components, are identified.\n- **Analytics Metadata Filtering:** It then filters this comprehensive `package.xml` to include only the CRM Analytics-related metadata types (e.g., `WaveApplication`, `WaveDashboard`, `WaveDataflow`, `WaveLens`, `WaveRecipe`, `WaveXmd`).\n- **Filtered `package.xml` Creation:** A new `package.xml` file containing only the filtered CRM Analytics metadata is created temporarily.\n- **Salesforce CLI Retrieval:** It executes the `sf project retrieve start` command, using the newly created Analytics-specific `package.xml` to retrieve the sources to your local project.\n- **Temporary File Management:** It uses `createTempDir` to manage temporary files and directories created during the process.\n- **Interactive Org Selection:** Uses `promptOrgUsernameDefault` to guide the user in selecting the target Salesforce org if not provided via flags.\n",
+      "description": "\n## Command Behavior\n\n**Retrieves all CRM Analytics (formerly Tableau CRM or Einstein Analytics) sources from a Salesforce org, including workarounds for known SFDX bugs.**\n\nThis command is designed to extract the complete configuration of your CRM Analytics assets, such as dashboards, dataflows, lenses, and recipes. It's essential for version controlling your Analytics development, migrating assets between environments, or backing up your Analytics configurations.\n\nKey functionalities:\n\n- **Comprehensive Retrieval:** Fetches all supported CRM Analytics metadata types.\n- **SFDX Bug Workarounds:** Incorporates internal logic to handle common issues or limitations encountered when retrieving CRM Analytics metadata using standard Salesforce CLI commands.\n- **Target Org Selection:** Allows you to specify the Salesforce org from which to retrieve the Analytics sources. If not provided, it will prompt for selection.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Full Org Manifest Generation:** It first generates a complete `package.xml` for the target org using `buildOrgManifest`. This ensures that all available metadata, including CRM Analytics components, are identified.\n- **Analytics Metadata Filtering:** It then filters this comprehensive `package.xml` to include only the CRM Analytics-related metadata types (e.g., `WaveApplication`, `WaveDashboard`, `WaveDataflow`, `WaveLens`, `WaveRecipe`, `WaveXmd`).\n- **Filtered `package.xml` Creation:** A new `package.xml` file containing only the filtered CRM Analytics metadata is created temporarily.\n- **Salesforce CLI Retrieval:** It executes the `sf project retrieve start` command, using the newly created Analytics-specific `package.xml` to retrieve the sources to your local project.\n- **Temporary File Management:** It uses `createTempDir` to manage temporary files and directories created during the process.\n- **Interactive Org Selection:** Uses `promptOrgUsernameDefault` to guide the user in selecting the target Salesforce org if not provided via flags.\n</details>\n",
       "examples": [
         "$ sf hardis:org:retrieve:sources:analytics"
       ],
@@ -13620,7 +13859,7 @@
     "hardis:org:retrieve:sources:dx": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Retrieves Salesforce metadata from an org and converts it into Salesforce DX (SFDX) source format.**\n\nThis command provides a flexible way to pull metadata from any Salesforce org into your local SFDX project. It's particularly useful for:\n\n- **Initial Project Setup:** Populating a new SFDX project with existing org metadata.\n- **Environment Synchronization:** Bringing changes from a Salesforce org (e.g., a sandbox) into your local development environment.\n- **Selective Retrieval:** Allows you to specify which metadata types to retrieve, or to filter out certain types.\n- **Org Shape Creation:** Can optionally create an org shape, which is useful for defining the characteristics of scratch orgs.\n\nKey functionalities:\n\n- **Metadata Retrieval:** Connects to a target Salesforce org and retrieves metadata based on specified filters.\n- **MDAPI to SFDX Conversion:** Converts the retrieved metadata from Metadata API format to SFDX source format.\n- **Org Shape Generation (Optional):** If the `--shape` flag is used, it also captures the org's shape and stores installed package information.\n- **Temporary File Management:** Uses temporary folders for intermediate steps, ensuring a clean working directory.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Temporary Directory Management:** It creates and manages temporary directories (`./tmp`, `mdapipkg`, `sfdx-project`) to stage the retrieved metadata and the converted SFDX sources.\n- **`MetadataUtils.retrieveMetadatas`:** This utility is used to connect to the Salesforce org and retrieve metadata in Metadata API format. It supports filtering by metadata types and excluding certain items.\n- **SFDX Project Creation:** It executes `sf project generate` to create a new SFDX project structure within a temporary directory.\n- **MDAPI to SFDX Conversion:** It then uses `sf project convert mdapi` to convert the retrieved metadata from the MDAPI format to the SFDX source format.\n- **File System Operations:** It uses `fs-extra` to copy the converted SFDX sources to the main project folder, while preserving important project files like `.gitignore` and `sfdx-project.json`.\n- **Org Shape Handling:** If `--shape` is enabled, it copies the generated `package.xml` and stores information about installed packages using `setConfig`.\n- **Error Handling:** Includes robust error handling for Salesforce CLI commands and file system operations.\n- **WebSocket Communication:** Uses `WebSocketClient.sendRefreshCommandsMessage` to notify connected VS Code clients about changes to the project.\n",
+      "description": "\n## Command Behavior\n\n**Retrieves Salesforce metadata from an org and converts it into Salesforce DX (SFDX) source format.**\n\nThis command provides a flexible way to pull metadata from any Salesforce org into your local SFDX project. It's particularly useful for:\n\n- **Initial Project Setup:** Populating a new SFDX project with existing org metadata.\n- **Environment Synchronization:** Bringing changes from a Salesforce org (e.g., a sandbox) into your local development environment.\n- **Selective Retrieval:** Allows you to specify which metadata types to retrieve, or to filter out certain types.\n- **Org Shape Creation:** Can optionally create an org shape, which is useful for defining the characteristics of scratch orgs.\n\nKey functionalities:\n\n- **Metadata Retrieval:** Connects to a target Salesforce org and retrieves metadata based on specified filters.\n- **MDAPI to SFDX Conversion:** Converts the retrieved metadata from Metadata API format to SFDX source format.\n- **Org Shape Generation (Optional):** If the `--shape` flag is used, it also captures the org's shape and stores installed package information.\n- **Temporary File Management:** Uses temporary folders for intermediate steps, ensuring a clean working directory.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Temporary Directory Management:** It creates and manages temporary directories (`./tmp`, `mdapipkg`, `sfdx-project`) to stage the retrieved metadata and the converted SFDX sources.\n- **`MetadataUtils.retrieveMetadatas`:** This utility is used to connect to the Salesforce org and retrieve metadata in Metadata API format. It supports filtering by metadata types and excluding certain items.\n- **SFDX Project Creation:** It executes `sf project generate` to create a new SFDX project structure within a temporary directory.\n- **MDAPI to SFDX Conversion:** It then uses `sf project convert mdapi` to convert the retrieved metadata from the MDAPI format to the SFDX source format.\n- **File System Operations:** It uses `fs-extra` to copy the converted SFDX sources to the main project folder, while preserving important project files like `.gitignore` and `sfdx-project.json`.\n- **Org Shape Handling:** If `--shape` is enabled, it copies the generated `package.xml` and stores information about installed packages using `setConfig`.\n- **Error Handling:** Includes robust error handling for Salesforce CLI commands and file system operations.\n- **WebSocket Communication:** Uses `WebSocketClient.sendRefreshCommandsMessage` to notify connected VS Code clients about changes to the project.\n</details>\n",
       "examples": [
         "$ sf hardis:org:retrieve:sources:dx"
       ],
@@ -13872,7 +14111,7 @@
     "hardis:org:retrieve:sources:dx2": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Retrieves Salesforce metadata from an org into SFDX source format, offering flexible input options for specifying metadata to retrieve.**\n\nThis command provides an alternative and enhanced way to pull metadata from any Salesforce org into your local SFDX project. It's particularly useful when you need fine-grained control over which metadata components are retrieved, either by providing a custom `package.xml` or by using predefined templates.\n\nKey functionalities:\n\n- **`package.xml` Input:** You can specify the path to a `package.xml` file using the `--packagexml` flag, which defines the exact metadata components to retrieve.\n- **Template-Based Retrieval:** Use the `--template` flag to leverage predefined `package.xml` templates provided by sfdx-hardis (e.g., `wave` for CRM Analytics metadata), simplifying common retrieval scenarios.\n- **Interactive Input:** If neither `--packagexml` nor `--template` is provided, the command will interactively prompt you to select a `package.xml` file or a template.\n- **Target Org Selection:** Allows you to specify the Salesforce org from which to retrieve the sources. If not provided, it will prompt for selection.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Org Selection:** It uses `promptOrg` to guide the user in selecting the target Salesforce org if not provided via flags.\n- **`package.xml` Resolution:** It determines the `package.xml` to use based on the provided flags (`--packagexml` or `--template`). If a template is used, it resolves the path to the corresponding template file within the sfdx-hardis installation.\n- **File System Operations:** It checks if the specified `package.xml` file exists. If the file is outside the current project directory, it copies it to a temporary location within the project to ensure proper handling by the Salesforce CLI.\n- **Salesforce CLI Retrieval:** It executes the `sf project retrieve start` command, passing the resolved `package.xml` path and the target username to retrieve the sources.\n- **User Feedback:** Provides clear messages to the user about the retrieval process and its success.\n",
+      "description": "\n## Command Behavior\n\n**Retrieves Salesforce metadata from an org into SFDX source format, offering flexible input options for specifying metadata to retrieve.**\n\nThis command provides an alternative and enhanced way to pull metadata from any Salesforce org into your local SFDX project. It's particularly useful when you need fine-grained control over which metadata components are retrieved, either by providing a custom `package.xml` or by using predefined templates.\n\nKey functionalities:\n\n- **`package.xml` Input:** You can specify the path to a `package.xml` file using the `--packagexml` flag, which defines the exact metadata components to retrieve.\n- **Template-Based Retrieval:** Use the `--template` flag to leverage predefined `package.xml` templates provided by sfdx-hardis (e.g., `wave` for CRM Analytics metadata), simplifying common retrieval scenarios.\n- **Interactive Input:** If neither `--packagexml` nor `--template` is provided, the command will interactively prompt you to select a `package.xml` file or a template.\n- **Target Org Selection:** Allows you to specify the Salesforce org from which to retrieve the sources. If not provided, it will prompt for selection.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Org Selection:** It uses `promptOrg` to guide the user in selecting the target Salesforce org if not provided via flags.\n- **`package.xml` Resolution:** It determines the `package.xml` to use based on the provided flags (`--packagexml` or `--template`). If a template is used, it resolves the path to the corresponding template file within the sfdx-hardis installation.\n- **File System Operations:** It checks if the specified `package.xml` file exists. If the file is outside the current project directory, it copies it to a temporary location within the project to ensure proper handling by the Salesforce CLI.\n- **Salesforce CLI Retrieval:** It executes the `sf project retrieve start` command, passing the resolved `package.xml` path and the target username to retrieve the sources.\n- **User Feedback:** Provides clear messages to the user about the retrieval process and its success.\n</details>\n",
       "examples": [
         "$ sf hardis:org:retrieve:sources:dx2"
       ],
@@ -14091,7 +14330,7 @@
     "hardis:org:retrieve:sources:metadata": {
       "aliases": [],
       "args": {},
-      "description": "\n## Command Behavior\n\n**Retrieves Salesforce metadata from an org into a local directory, primarily for backup and monitoring purposes.**\n\nThis command is designed to pull metadata from any Salesforce org, providing a snapshot of its configuration. It's particularly useful in monitoring contexts where you need to track changes in an org's metadata over time.\n\nKey functionalities:\n\n- **Metadata Retrieval:** Connects to a target Salesforce org and retrieves metadata based on a specified `package.xml`.\n- **Managed Package Filtering:** By default, it filters out metadata from managed packages to reduce the volume of retrieved data. This can be overridden with the `--includemanaged` flag.\n- **Monitoring Integration:** Designed to be used within a monitoring CI/CD job, it performs additional post-retrieval actions like running Apex tests and checking for legacy API usage.\n\n## Technical explanations\n\nThe command's technical implementation involves:\n\n- **Git Repository Check:** Ensures the current directory is a Git repository and initializes it if necessary.\n- **`MetadataUtils.retrieveMetadatas`:** This utility is the core of the retrieval process. It connects to the Salesforce org, retrieves metadata based on the provided `package.xml` and filtering options (e.g., `filterManagedItems`), and places the retrieved files in a specified folder.\n- **File System Operations:** Uses `fs-extra` to manage directories and copy retrieved files to the target folder.\n- **Post-Retrieval Actions (for Monitoring Jobs):** If the command detects it's running within a monitoring CI/CD job (`isMonitoringJob()`):\n  - It updates the `.gitlab-ci.yml` file if `AUTO_UPDATE_GITLAB_CI_YML` is set.\n  - It converts the retrieved metadata into SFDX format using `sf project convert mdapi`.\n  - It executes `sf hardis:org:test:apex` to run Apex tests.\n  - It executes `sf hardis:org:diagnose:legacyapi` to check for legacy API usage.\n  - It logs warnings if post-actions fail or if the monitoring version is deprecated.\n- **Error Handling:** Includes robust error handling for retrieval failures and post-action execution.\n",
+      "description": "\n## Command Behavior\n\n**Retrieves Salesforce metadata from an org into a local directory, primarily for backup and monitoring purposes.**\n\nThis command is designed to pull metadata from any Salesforce org, providing a snapshot of its configuration. It's particularly useful in monitoring contexts where you need to track changes in an org's metadata over time.\n\nKey functionalities:\n\n- **Metadata Retrieval:** Connects to a target Salesforce org and retrieves metadata based on a specified `package.xml`.\n- **Managed Package Filtering:** By default, it filters out metadata from managed packages to reduce the volume of retrieved data. This can be overridden with the `--includemanaged` flag.\n- **Monitoring Integration:** Designed to be used within a monitoring CI/CD job, it performs additional post-retrieval actions like running Apex tests and checking for legacy API usage.\n\n<details markdown=\"1\">\n<summary>Technical explanations</summary>\n\nThe command's technical implementation involves:\n\n- **Git Repository Check:** Ensures the current directory is a Git repository and initializes it if necessary.\n- **`MetadataUtils.retrieveMetadatas`:** This utility is the core of the retrieval process. It connects to the Salesforce org, retrieves metadata based on the provided `package.xml` and filtering options (e.g., `filterManagedItems`), and places the retrieved files in a specified folder.\n- **File System Operations:** Uses `fs-extra` to manage directories and copy retrieved files to the target folder.\n- **Post-Retrieval Actions (for Monitoring Jobs):** If the command detects it's running within a monitoring CI/CD job (`isMonitoringJob()`):\n  - It updates the `.gitlab-ci.yml` file if `AUTO_UPDATE_GITLAB_CI_YML` is set.\n  - It converts the retrieved metadata into SFDX format using `sf project convert mdapi`.\n  - It executes `sf hardis:org:test:apex` to run Apex tests.\n  - It executes `sf hardis:org:diagnose:legacyapi` to check for legacy API usage.\n  - It logs warnings if post-actions fail or if the monitoring version is deprecated.\n- **Error Handling:** Includes robust error handling for retrieval failures and post-action execution.\n</details>\n",
       "examples": [
         "$ sf hardis:org:retrieve:sources:metadata",
         "$ SFDX_RETRIEVE_WAIT_MINUTES=200 sf hardis:org:retrieve:sources:metadata"
@@ -14863,5 +15102,5 @@
       ]
     }
   },
-  "version": "6.0.6-beta202508141313.0"
+  "version": "6.0.7-beta202508191748.0"
 }