edits

Author: paigecalvert

docs/vendor/preflight-defining.mdx

@@ -1,20 +1,20 @@
 # Defining Preflight Checks
 
-This topic describes how to define preflight checks in Helm- and standard Kubernetes manifest-based applications. For more information about preflight checks, see [About Preflight Checks and Support Bundles](/vendor/preflight-support-bundle-about).
+This topic describes how to define preflight checks in Helm and Kubernetes manifest-based applications. For more information about preflight checks, see [About Preflight Checks and Support Bundles](/vendor/preflight-support-bundle-about).
 
 The information in this topic applies to applications that are installed with the Helm CLI or with Replicated KOTS.
 
 ## Step 1: Create the Manifest File
 
-You can define preflight checks in a Kubernetes Secret or in a Preflight custom resource. The type of manifest file that you use depends on your application type (Helm- or standard manifest-based) and the installation methods that your application supports (Helm CLI, KOTS v1.101.0 or later, or KOTS v1.100.3 or earlier).
+You can define preflight checks in a Kubernetes Secret or in a Preflight custom resource. The type of manifest file that you use depends on your application type (Helm or Kubernetes manifest-based) and the installation methods that your application supports (Helm CLI, KOTS v1.101.0 or later, or KOTS v1.100.3 or earlier).
 
 * **Helm Applications**: For Helm applications, see the following guidance:
 
-   * **(Recommended) Helm CLI or KOTS v1.101.0 or Later**: For Helm-based applications installed with the Helm CLI or KOTS v1.101.0 or later, define the preflight checks in a Kubernetes Secret in your Helm chart `templates`. See [Kubernetes Secret](#secret).
+   * **(Recommended) Helm CLI or KOTS v1.101.0 or Later**: For Helm applications installed with the Helm CLI or KOTS v1.101.0 or later, define the preflight checks in a Kubernetes Secret in your Helm chart `templates`. See [Kubernetes Secret](#secret).
 
    * **KOTS v1.100.3 or Earlier**: For Helm applications installed with KOTS v1.100.3 or earlier, define the preflight checks in a Preflight custom resource. See [Preflight Custom Resource](#preflight-cr).
 
-* **Standard Manifest-Based Applications**: For standard manifest-based applications, define the preflight checks in a Preflight custom resource. See [Preflight Custom Resource](#preflight-cr).
+* **Kubernetes Manifest-Based Applications**: For Kubernetes manifest-based applications, define the preflight checks in a Preflight custom resource. See [Preflight Custom Resource](#preflight-cr).
 
 ### Kubernetes Secret {#secret}
 
@@ -50,7 +50,7 @@ As shown above, the Secret must include the following:
 ### Preflight Custom Resource {#preflight-cr}
 
 Define preflight checks in a Preflight custom resource for the following installation types:
-* Standard manifest-based applications installed with any version of KOTS
+* Kubernetes manifest-based applications installed with any version of KOTS
 * Helm applications installed with KOTS v1.100.3 and earlier
     :::note
     For Helm charts installed with KOTS v1.101.0 and later, Replicated recommends that you define preflight checks in a Secret in the Helm chart `templates` instead of using the Preflight custom resource. See [Create a Secret](#secret) above.

docs/vendor/support-bundle-customizing.mdx

@@ -2,11 +2,11 @@
 
 This topic describes how to add a default support bundle spec to a release for your application. It also describes how to customize the default support bundle spec based on your application's needs. For more information about support bundles, see [About Preflight Checks and Support Bundles](/vendor/preflight-support-bundle-about).
 
-The information in this topic applies to Helm chart- and standard manifest-based application installed with Helm or with Replicated KOTS.
+The information in this topic applies to Helm applications and Kubernetes manifest-based application installed with Helm or with Replicated KOTS.
 
 ## Step 1: Add the Default Spec to a Manifest File
 
-You can add the support bundle spec to a Kubernetes Secret or a SupportBundle custom resource. The type of manifest file that you use depends on your application type (Helm chart- or standard manifest-based) and installation method (Helm CLI or KOTS).
+You can add the support bundle spec to a Kubernetes Secret or a SupportBundle custom resource. The type of manifest file that you use depends on your application type (Helm or manifest-based) and installation method (Helm CLI or KOTS).
 
 Use the following guidance to determine which type of manifest file to use for creating a support bundle spec:
 
@@ -16,7 +16,7 @@ Use the following guidance to determine which type of manifest file to use for c
 
    * **KOTS v1.94.1 and Earlier**: For Helm applications installed with KOTS v1.94.1 or earlier, create the support bundle spec in a Preflight custom resource. See [Preflight Custom Resource](#preflight-cr).
 
-* **Standard Manifest-Based Applications**: For standard manifest-based applications, create the support bundle spec in a Preflight custom resource. See [Preflight Custom Resource](#preflight-cr).
+* **Kubernetes Manifest-Based Applications**: For Kubernetes manifest-based applications, create the support bundle spec in a Preflight custom resource. See [Preflight Custom Resource](#preflight-cr).
 
 ### Kubernetes Secret
 
@@ -64,8 +64,8 @@ After you create this empty support bundle spec, you can test the support bundle
 ### SupportBundle Custom Resource
 
 You can define support bundle specs in a SupportBundle custom resource for the following installation types:
-* Standard manifest-based applications installed with KOTS
-* Helm chart-based applications installed with KOTS v1.94.1 and earlier
+* Kubernetes manifest-based applications installed with KOTS
+* Helm applications installed with KOTS v1.94.1 and earlier
 
 In a release for your application, add the following YAML to a new `support-bundle.yaml` manifest file: