update xrefs in vendor

Author: paigecalvert

docs/vendor/ci-workflows.mdx

@@ -8,7 +8,7 @@ This topic provides Replicated's recommended development and release workflows f
 
 Replicated recommends that you maintain unique CI/CD workflows for development (continuous integration) and for releasing your software (continuous delivery). The development and release workflows in this topic describe the recommended steps and jobs to include in your own workflows, including how to integrate Replicated Compatibility Matrix into your workflows for testing. For more information about Compatibility Matrix, see [About Compatibility Matrix](testing-about).
 
-For each step, the corresponding Replicated CLI command is provided. Additionally, for users of the GitHub Actions platform, a corresponding custom GitHub action that is maintained by Replicated is also provided. For more information about using the Replicated CLI, see [Installing the Replicated CLI](/reference/replicated-cli-installing). For more information about the Replicated GitHub actions, see [Integrating Replicated GitHub Actions](ci-workflows-github-actions).
+For each step, the corresponding Replicated CLI command is provided. Additionally, for users of the GitHub Actions platform, a corresponding custom GitHub action that is maintained by Replicated is also provided. For more information about using the Replicated CLI, see [Install the Replicated CLI](/reference/replicated-cli-installing). For more information about the Replicated GitHub actions, see [Integrating Replicated GitHub Actions](ci-workflows-github-actions).
 
 :::note
 How you implement CI/CD workflows varies depending on the platform, such as GitHub, GitLab, CircleCI, TravisCI, or Jenkins. Refer to the documentation for your CI/CD platform for additional guidance on how to create jobs and workflows.
@@ -18,7 +18,7 @@ How you implement CI/CD workflows varies depending on the platform, such as GitH
 
 Replicated recommends using custom RBAC policies to control the actions that can be performed in your CI/CD workflows. For example, you can create a policy using the [`kots/app/[]/channel/[]/promote`](/vendor/team-management-rbac-resource-names#kotsappchannelpromote) resource that blocks the ability to promote releases to your production channel. This allows for using CI/CD for the purpose of testing, without accidentally releasing to customers.
 
-For more information about creating custom RBAC policies in the Vendor Portal, including examples, see [Configuring RBAC Policies](/vendor/team-management-rbac-configuring).
+For more information about creating custom RBAC policies in the Vendor Portal, including examples, see [Configure RBAC Policies](/vendor/team-management-rbac-configuring).
 
 For a full list of available RBAC resources, see [RBAC Resource Names](/vendor/team-management-rbac-resource-names).
 

docs/vendor/config-screen-about.md

@@ -4,7 +4,7 @@ This topic describes the configuration screen on the Config tab in the Replicate
 
 ## About Collecting Configuration Values
 
-When you distribute your application with Replicated KOTS, you can include a configuration screen in the Admin Console. This configuration screen is used to collect required or optional values from your users that are used to run your application. You can use regular expressions to validate user input for some fields, such as passwords and email addresses. For more information about how to add custom fields to the configuration screen, see [Creating and Editing Configuration Fields](admin-console-customize-config-screen).
+When you distribute your application with Replicated KOTS, you can include a configuration screen in the Admin Console. This configuration screen is used to collect required or optional values from your users that are used to run your application. You can use regular expressions to validate user input for some fields, such as passwords and email addresses. For more information about how to add custom fields to the configuration screen, see [Create and Edit Configuration Fields](admin-console-customize-config-screen).
 
 If you use a Helm chart for your application, your users provide any values specific to their environment from the configuration screen, rather than in a Helm chart `values.yaml` file. This means that your users can provide configuration values through a user interface, rather than having to edit a YAML file or use `--set` CLI commands. The Admin Console configuration screen also allows you to control which options you expose to your users.
 

docs/vendor/config-screen-map-inputs.md

@@ -2,7 +2,7 @@
 
 This topic describes how to map the values that your users provide in the Replicated Admin Console configuration screen to your application.
 
-This topic assumes that you have already added custom fields to the Admin Console configuration screen by editing the Config custom resource. For more information, see [Creating and Editing Configuration Fields](admin-console-customize-config-screen).
+This topic assumes that you have already added custom fields to the Admin Console configuration screen by editing the Config custom resource. For more information, see [Create and Edit Configuration Fields](admin-console-customize-config-screen).
 
 ## Overview of Mapping Values
 

docs/vendor/embedded-using.mdx

@@ -80,7 +80,7 @@ To install with Embedded Cluster, you need to download the Embedded Cluster inst
 
 To serve Embedded Cluster installation assets with the Vendor API:
 
-1. If you have not done so already, create an API token for the Vendor API. See [Using the Vendor API v3](/reference/vendor-api-using#api-token-requirement).
+1. If you have not done so already, create an API token for the Vendor API. See [Use the Vendor API v3](/reference/vendor-api-using#api-token-requirement).
 
 1. Call the [Get an Embedded Cluster release](https://replicated-vendor-api.readme.io/reference/getembeddedclusterrelease) endpoint to download the assets needed to install your application with Embedded Cluster. Your customers must take this binary and their license and copy them to the machine where they will install your application.
 
@@ -163,7 +163,7 @@ For more information about creating HA multi-node clusters with Embedded Cluster
 
 <UpdateOverview/>
 
-For more information about updating, see [Performing Updates with Embedded Cluster](/enterprise/updating-embedded).
+For more information about updating, see [Perform Updates with Embedded Cluster](/enterprise/updating-embedded).
 
 ## Access the Cluster
 

docs/vendor/helm-install-values-schema.mdx

@@ -10,7 +10,7 @@ When a user installs a Helm application with the Helm CLI, the Replicated regist
 
 The values in the `global.replicated` field include the following:
 
-* The fields in the customer's license, such as the field names, descriptions, signatures, values, and any custom license fields that you define. Vendors can use this license information to check entitlements before the application is installed. For more information, see [Checking Entitlements in Helm Charts Before Deployment](/vendor/licenses-reference-helm).
+* The fields in the customer's license, such as the field names, descriptions, signatures, values, and any custom license fields that you define. Vendors can use this license information to check entitlements before the application is installed. For more information, see [Check Entitlements in Helm Charts Before Deployment](/vendor/licenses-reference-helm).
 
 * A base64 encoded Docker configuration file. To proxy images from an external private registry with the Replicated proxy registry, you can use the `global.replicated.dockerconfigjson` field to create an image pull secret for the proxy registry. For more information, see [Proxying Images for Helm Installations](/vendor/helm-image-registry).
 
@@ -47,7 +47,7 @@ The `global.replicated` values schema contains the following fields:
 | `customerEmail` | String | The email address of the customer |
 | `customerName` | String | The name of the customer |
 | `dockerconfigjson` | String | Base64 encoded docker config json for pulling images |
-| `licenseFields`| | A list containing each license field in the customer's license. Each element under `licenseFields` has the following properties: `description`, `signature`, `title`, `value`, `valueType`. `expires_at` is the default `licenseField` that all licenses include. Other elements under `licenseField` include the custom license fields added by vendors in the Vendor Portal. For more information, see [Managing Customer License Fields](/vendor/licenses-adding-custom-fields). |
+| `licenseFields`| | A list containing each license field in the customer's license. Each element under `licenseFields` has the following properties: `description`, `signature`, `title`, `value`, `valueType`. `expires_at` is the default `licenseField` that all licenses include. Other elements under `licenseField` include the custom license fields added by vendors in the Vendor Portal. For more information, see [Manage Customer License Fields](/vendor/licenses-adding-custom-fields). |
 | `licenseFields.[FIELD_NAME].description` | String | Description of the license field |
 | `licenseFields.[FIELD_NAME].signature.v1` | Object | Signature of the license field |
 | `licenseFields.[FIELD_NAME].title` | String | Title of the license field |

docs/vendor/helm-optional-charts.md

@@ -112,7 +112,7 @@ Next, package the Helm chart and add it to the release in the Vendor Portal:
 
 1. Drag and drop the `.tgz` file into the file tree of the release. The Vendor Portal automatically creates a new HelmChart custom resource named `postgresql.yaml`, which references the `.tgz` file you uploaded.
 
-    For more information about adding Helm charts to a release in the Vendor Portal, see [Managing Releases with the Vendor Portal](releases-creating-releases).
+    For more information about adding Helm charts to a release in the Vendor Portal, see [Manage Releases with the Vendor Portal](releases-creating-releases).
 
 ### Step 4: Edit the HelmChart Custom Resource
 

docs/vendor/helm-v2-migrate.md

@@ -20,7 +20,7 @@ To migrate existing installations from HelmChart v1 with `useHelmInstall: true`
 
 1. Create a new release containing your application files.
 
-1. For each Helm chart in the release, find the corresponding HelmChart custom resource and update `apiVersion` to `kots.io/v1beta2`. Then update it to rewrite images, inject image pull secrets, and add backup labels. See [Configuring the HelmChart Custom Resource v2](helm-native-v2-using).
+1. For each Helm chart in the release, find the corresponding HelmChart custom resource and update `apiVersion` to `kots.io/v1beta2`. Then update it to rewrite images, inject image pull secrets, and add backup labels. See [Configure the HelmChart Custom Resource v2](helm-native-v2-using).
 
 1. Promote the release to an internal-only channel that your team uses for testing.
 
@@ -60,7 +60,7 @@ To migrate existing installations from HelmChart v1 and `useHelmInstall: false`
      
 1. Create another new release:
 
-   1. For each Helm chart in the release, find the corresponding HelmChart custom resource and update `apiVersion` to `kots.io/v1beta2`. Then update it to rewrite images, inject image pull secrets, and add backup labels. See [Configuring the HelmChart Custom Resource v2](helm-native-v2-using).
+   1. For each Helm chart in the release, find the corresponding HelmChart custom resource and update `apiVersion` to `kots.io/v1beta2`. Then update it to rewrite images, inject image pull secrets, and add backup labels. See [Configure the HelmChart Custom Resource v2](helm-native-v2-using).
 
    1. In the HelmChart custom resource, under the `helmUpgradeFlags` field, add the `--take-ownership` flag:
 
@@ -124,7 +124,7 @@ To migrate applications that were previously packaged as standard Kubernetes man
 
      1. In the release, add your application Helm chart(s). Remove the application manifests for resources that were adopted into the Helm chart(s).
 
-     1. For each Helm chart in the release, add a corresponding KOTS HelmChart custom resource with `apiVersion` set to `kots.io/v1beta2`. Configure the resource to rewrite images, inject image pull secrets, and add backup labels. See [Configuring the HelmChart Custom Resource v2](helm-native-v2-using).
+     1. For each Helm chart in the release, add a corresponding KOTS HelmChart custom resource with `apiVersion` set to `kots.io/v1beta2`. Configure the resource to rewrite images, inject image pull secrets, and add backup labels. See [Configure the HelmChart Custom Resource v2](helm-native-v2-using).
 
      1. In the HelmChart custom resource, under the `helmUpgradeFlags` field, add the `--take-ownership` flag:
 

docs/vendor/kots-faq.mdx

@@ -116,7 +116,7 @@ To install with Embedded Cluster, users first download and extract the Embedded
 
 After the installation command finishes, users log in to the Admin Console to provide application configuration values, optionally join more nodes to the cluster, run preflight checks, and deploy the application.
 
-Customer-specific Embedded Cluster installation instructions are provided in the Replicated Vendor Portal. For more information, see [Installing with Embedded Cluster](/enterprise/installing-embedded).
+Customer-specific Embedded Cluster installation instructions are provided in the Replicated Vendor Portal. For more information, see [Install with Embedded Cluster](/enterprise/installing-embedded).
 
 ### Does Replicated support installations into air gap environments?
 
@@ -152,7 +152,7 @@ For more information, see [Embedded Cluster Overview](/vendor/embedded-overview)
 
 The KOTS Admin Console and the Replicated Download Portal support the use of a custom logo. Additionally, software vendors can use custom domains to alias the endpoints for Replicated services.
 
-For more information, see [Customizing the Admin Console and Download Portal](/vendor/admin-console-customize-app-icon) and [About Custom Domains](custom-domains).
+For more information, see [Customize the Admin Console and Download Portal](/vendor/admin-console-customize-app-icon) and [About Custom Domains](custom-domains).
 
 For more information, see [Use Custom Domains](/vendor/custom-domains-using).
 
@@ -166,35 +166,35 @@ For more information, see [Use Custom Domains](/vendor/custom-domains-using).
 
 Yes. The Replicated SDK has an _air gap mode_ that allows it to run in environments with no outbound internet access. When installed in air gap mode, the SDK does not attempt to connect to the internet. This avoids any failures that would occur when the SDK is unable to make outbound requests in air gap environments.
 
-For more information, see [Installing the SDK in Air Gap Environments](/vendor/replicated-sdk-airgap).
+For more information, see [Install the SDK in Air Gap Environments](/vendor/replicated-sdk-airgap).
 
 ### How do I develop against the SDK API?
 
 You can use the Replicated SDK in _integration mode_ to develop locally against the SDK API without needing to make real changes in the Replicated Vendor Portal or in your environment.
 
-For more information, see [Developing Against the SDK API](/vendor/replicated-sdk-development).
+For more information, see [Develop Against the SDK API](/vendor/replicated-sdk-development).
 
 ### How does the Replicated SDK work with KOTS?
 
 The Replicated SDK is a Helm chart that can be installed as a small service alongside an application, or as a standalone component. The SDK can be installed using the Helm CLI or KOTS.
 
 Replicated recommends that all applications include the SDK because it provides access to key functionality not available through KOTS, such as support for sending custom metrics from application instances. When both the SDK and KOTS are installed in a cluster alongside an application, both send instance telemetry to the Vendor Portal.
 
-For more information about the SDK installation options, see [Installing the Replicated SDK](/vendor/replicated-sdk-installing).
+For more information about the SDK installation options, see [Install the Replicated SDK](/vendor/replicated-sdk-installing).
 
 ## Vendor Portal FAQs
 
 ### How do I add and remove team members?
 
-Admins can add, remove, and manage team members from the Vendor Portal. For more information, see [Managing Team Members](/vendor/team-management).
+Admins can add, remove, and manage team members from the Vendor Portal. For more information, see [Manage Team Members](/vendor/team-management).
 
 ### How do I manage RBAC policies for my team members?
 
 By default, every team has two policies created automatically: Admin and Read Only. If you have an Enterprise plan, you will also have the Sales and Support policies created automatically. These default policies are not configurable.
 
 You can also configure custom RBAC policies if you are on the Enterprise pricing plan. Creating custom RBAC policies lets you limit which areas of the Vendor Portal are accessible to team members, and control read and read/write privileges to groups based on their role. 
 
-For more information, see [Configuring RBAC Policies](/vendor/team-management-rbac-configuring).
+For more information, see [Configure RBAC Policies](/vendor/team-management-rbac-configuring).
 
 ### Can I alias Replicated endpoints?
 

docs/vendor/kurl-about.mdx

@@ -20,7 +20,7 @@ The Replicated KOTS entitlement is required to install applications with KOTS an
 
 <Installers/>
 
-To distribute a kURL installer alongside your application, you can promote the installer to a channel or include the installer as a manifest file within a given release. For more information about creating kURL installers, see [Creating a kURL Installer](/vendor/packaging-embedded-kubernetes).
+To distribute a kURL installer alongside your application, you can promote the installer to a channel or include the installer as a manifest file within a given release. For more information about creating kURL installers, see [Create a kURL Installer](/vendor/packaging-embedded-kubernetes).
 
 ### kURL Installations