Sarah feedback

Author: rkoron007

content/terraform-docs-common/data/cloud-docs-nav-data.json

@@ -599,7 +599,7 @@
         "title": "Deploy infrastructure",
         "routes": [
           { "title": "Configuration versions", "path": "stacks/deploy/configuration-versions" },
-          { "title": "Review deployment plans", "path": "stacks/deploy/runs" }
+          { "title": "Review deployment runs", "path": "stacks/deploy/runs" }
         ]
       },
         {
@@ -624,7 +624,6 @@
       { "title":  "Kubernetes configuration", "href":  "dynamic-provider-credentials/kubernetes-configuration" },
       { "title":  "HCP configuration", "href":  "dynamic-provider-credentials/hcp-configuration" },
       { "title":  "Manually generating workload identity tokens", "href":  "dynamic-provider-credentials/manual-generation" },
-      { "title":  "Specifying multiple configurations", "href": "dynamic-provider-credentials/specifying-multiple-configurations"},
       {
         "title": "Vault-backed dynamic credentials",
           "routes": [

content/terraform-docs-common/docs/cloud-docs/overview/index.mdx

@@ -44,7 +44,7 @@ Some of HCP Terraform's features are limited to particular paid upgrade plans.
 
 Each higher paid upgrade plan is a strict superset of any lower plans — for example, the **Standard** edition includes all of the features of the **Essentials** edition. The **Premium** edition includes all of the features of the **Standard** and **Essentials** editions. Paid feature callouts in the documentation indicate the _lowest_ edition at which the feature is available, but any higher plans also include that feature.
 
-To learn more about HCP Terraform's paid plans and features, refer to []
+To learn more about HCP Terraform's paid plans and features, refer to the [pricing page](https://www.hashicorp.com/products/terraform/pricing).
 
 Terraform Enterprise generally includes all of HCP Terraform's paid features, plus additional features geared toward large enterprises. However, some features are implemented differently due to the differences between self-hosted and SaaS environments, and some features might be absent due to being impractical or irrelevant in the types of organizations that need Terraform Enterprise. Cloud-only or Enterprise-only features are clearly indicated in documentation.
 
@@ -116,10 +116,10 @@ Stacks can also directly share information with each other Stacks in the same pr
 
 Like other kinds of code, infrastructure-as-code belongs in version control, so HCP Terraform is designed to work directly with your version control system (VCS) provider.
 
-Each workspace or Stack can be linked to a VCS repository that contains its configuration, optionally specifying a branch and subdirectory. By default, HCP Terraform automatically retrieves configuration content from linked repositories, and watches the repository for changes:
+Each workspace can be linked to a VCS repository that contains its configuration, optionally specifying a branch and subdirectory. You can also link Stacks to a VCS repository. By default, HCP Terraform automatically retrieves configuration content from linked repositories, and watches the repository for changes:
 
-- When new commits are merged, VCS-linked workspaces and Stacks automatically run Terraform plans with the new code.
-- When pull requests are opened, linked workspaces run speculative plans with the proposed code changes and post the results as a pull request check; reviewers can see at a glance whether the plan was successful, and can click through to view the proposed changes in detail.
+- When new commits are merged, linked workspaces and Stacks automatically run Terraform plans with the new code.
+- When pull requests are opened, linked workspaces and Stacks run speculative plans with the proposed code changes and post the results as a pull request check; reviewers can see at a glance whether the plan was successful, and can click through to view the proposed changes in detail.
 
 VCS integration is powerful, but optional; if you use an unsupported VCS or want to preserve an existing validation and deployment pipeline, you can use the API or Terraform CLI to upload new configuration versions. You'll still get the benefits of remote execution and HCP Terraform's other features.
 

content/terraform-docs-common/docs/cloud-docs/projects/best-practices.mdx

@@ -12,7 +12,7 @@ Projects let you group and scope access to your workspaces<!-- BEGIN: TFC:only n
 Projects offer several advantages to help you further develop your workspace <!-- BEGIN: TFC:only name:stacks-tfe --> and Stack<!-- END: TFC:only name:stacks-tfe --> grouping strategy:
 
 - **Focused view**: You can scope which workspaces <!-- BEGIN: TFC:only name:stacks-tfe --> and Stacks<!-- END: TFC:only name:stacks-tfe --> HCP Terraform displays by project, allowing for a more organized view.
-- **Simplified workspace management**: You can create project-level permissions and variable sets that apply to all current and future workspaces <!-- BEGIN: TFC:only name:stacks-tfe -->and Stacks <!-- END: TFC:only name:stacks-tfe -->in the project. For example, you can create a project variable set containing your cloud provider credentials for all workspaces in the project to access.
+- **Simplified workspace management**: You can create project-level permissions and variable sets that apply to all current and future workspaces <!-- BEGIN: TFC:only name:stacks-tfe -->and Stacks <!-- END: TFC:only name:stacks-tfe -->in the project. For example, you can create a project variable set containing your cloud provider credentials for all workspaces<!-- BEGIN: TFC:only name:stacks-tfe --> and Stacks<!-- END: TFC:only name:stacks-tfe --> in the project to access.
 - **Reduced risk with centralized control**: You can scope project permissions to only grant teams administrator access to the projects and workspaces<!-- BEGIN: TFC:only name:stacks-tfe --> and Stacks<!-- END: TFC:only name:stacks-tfe --> they need.
 
 ## Recommendations

content/terraform-docs-common/docs/cloud-docs/projects/index.mdx

@@ -52,7 +52,7 @@ By default, a project uses the organization's [default execution mode](/terrafor
 
 ## Execution mode
 
-By default, a project uses the organization's execution mode, which is either **Remote** or **Local**, but you can override the organization execution mode in your project. Any workspaces<!-- BEGIN: TFC:only name:stacks-tfe --> or Stacks <!-- END: TFC:only name:stacks-tfe -->created in the project after changing the project execution mode inherit the project default. Refer to [Change the execution mode](/terraform/cloud-docs/projects/manage#change-the-execution-mode) for instructions.
+By default, a project uses the organization's execution mode, which is either **Remote** or **Local**, but you can override the organization execution mode in your project. Any workspaces created in the project after changing the project execution mode inherit the project default. Refer to [Change the execution mode](/terraform/cloud-docs/projects/manage#change-the-execution-mode) for instructions.
 
 You can enable the following execution modes:
 

content/terraform-docs-common/docs/cloud-docs/stacks/deploy/configuration-versions.mdx

@@ -20,8 +20,8 @@ A Stack configuration version is a snapshot of all of the pieces that make up yo
 ## Requirements
 
 To view a Stack and its configuration versions, you must also be a member of a team in your organization with one of the following permissions:
-* [Organization-level **Manage all projects**](/terraform/cloud-docs/users-teams-organizations/permissions#manage-all-projects)
-* [Project-level **Maintain**](/terraform/cloud-docs/users-teams-organizations/permissions#read) or higher
+* [Organization-level **Manage all projects**](/terraform/cloud-docs/users-teams-organizations/permissions/organization) or higher
+* [Project-level **Read**](/terraform/cloud-docs/users-teams-organizations/permissions/project) or higher
 
 ## Create a configuration version
 

content/terraform-docs-common/docs/cloud-docs/stacks/deploy/runs.mdx

@@ -13,8 +13,9 @@ You can also view, approve, or cancel deployment runs directly from the Terrafor
 ## Requirements
 
 To view a Stack and its deployment runs, you must also be a member of a team in your organization with one of the following permissions:
-* [Organization-level **View all projects**](/terraform/cloud-docs/users-teams-organizations/permissions#view-all-projects) or higher
-* [Project-level **Write**](/terraform/cloud-docs/users-teams-organizations/permissions#write) or higher
+* [Organization-level **View all projects**](/terraform/cloud-docs/users-teams-organizations/permissions/organization) or higher
+* [Project-level **Read**](/terraform/cloud-docs/users-teams-organizations/permissions/project) or higher to view deployment runs
+* [Project-level **Write**](/terraform/cloud-docs/users-teams-organizations/permissions/project) or higher to interact with deployment runs
 
 ## View a deployment
 

content/terraform-docs-common/docs/cloud-docs/stacks/runs.mdx

@@ -35,7 +35,7 @@ HCP Terraform creates a new configuration version each time any of the following
 
 ## Stack deployment runs
 
-Each configuration version creates a deployment run for every deployment of your Stack to implement the changes in that version. A deployment run consists of the steps that Terraform can perform to update that deployment to match the associated configuration version. A single run can include many plans and apply cycles, and a successful run ends with an empty plan to reflect that deployments have executed all downstream changes.
+Each configuration version creates a deployment run for every deployment of your Stack to implement the changes in that version. A deployment run consists of the steps that Terraform can perform to update that deployment to match the associated configuration version. A single run can include many plan and apply cycles, and a successful run ends with an empty plan to reflect that deployments have executed all downstream changes.
 
 The goal of deployment runs is to apply a configuration version to every deployment in the Stack. When all deployments successfully match the same Stack configuration, the Stack achieves convergence.
 
@@ -66,7 +66,7 @@ While a deployment holds a state lock, other runs for that deployment must wait.
 - Fails and stops execution
 - Gets manually canceled by an operator
 
-After the running deployment releases its lock, the next approved run in the queue can acquire the lock and begin its execution. To learn more state for deployments in a Stack, refer to [State for Stacks](/terraform/cloud-docs/stacks/state).
+After the running deployment releases its lock, the next approved run in the queue can acquire the lock and begin its execution. To learn more about state for deployments in a Stack, refer to [State for Stacks](/terraform/cloud-docs/stacks/state).
 
 ### Deployment run modes
 

content/terraform-docs-common/docs/cloud-docs/variables/index.mdx

@@ -35,7 +35,7 @@ To learn more about accessing environment variable values in Stacks, refer to [V
 
 #### Parallelism
 
-You can use the `TFE_PARALLELISM` environment variable when your infrastructure providers produce errors on concurrent operations or use non-standard rate limiting. The `TFE_PARALLELISM` variable sets the  `-parallelism=<N>` flag for  `terraform plan` and `terraform apply`  ([more about `parallelism`](/terraform/internals/graph#walking-the-graph)). Valid values are between 1 and 256, inclusive, and the default is `10`. HCP Terraform agents do not support `TFE_PARALLELISM`, but you can specify flags as environment variables directly via [`TF_CLI_ARGS_name`](/terraform/cli/config/environment-variables#tf-cli-args). In these cases, use `TF_CLI_ARGS_plan="-parallelism=<N>"` or `TF_CLI_ARGS_apply="-parallelism=<N>"` instead.
+In workspaces, you can use the `TFE_PARALLELISM` environment variable when your infrastructure providers produce errors on concurrent operations or use non-standard rate limiting. The `TFE_PARALLELISM` variable sets the  `-parallelism=<N>` flag for  `terraform plan` and `terraform apply`  ([more about `parallelism`](/terraform/internals/graph#walking-the-graph)). Valid values are between 1 and 256, inclusive, and the default is `10`. HCP Terraform agents do not support `TFE_PARALLELISM`, but you can specify flags as environment variables directly via [`TF_CLI_ARGS_name`](/terraform/cli/config/environment-variables#tf-cli-args). In these cases, use `TF_CLI_ARGS_plan="-parallelism=<N>"` or `TF_CLI_ARGS_apply="-parallelism=<N>"` instead.
 
 !> **Warning:** We recommend reading and understanding [Terraform parallelism](https://support.hashicorp.com/hc/en-us/articles/10348130482451) prior to setting `TFE_PARALLELISM`. You can also contact HashiCorp support for direct advice.
 

content/terraform-docs-common/docs/cloud-docs/variables/managing-variables.mdx

@@ -120,7 +120,7 @@ To create a variable set:
 1. Choose a variable set scope:
    - Organization-owned
       - **Apply globally:** HCP Terraform automatically applies this global variable set to all existing and future workspaces.
-      - **Apply to specific projects, workspaces, or<!-- BEGIN: TFC:only name:stacks-tfe --> Stacks<!-- END: TFC:only name:stacks-tfe -->:** Use the text fields to search for and select workspaces<!-- BEGIN: TFC:only name:stacks-tfe --> ,Stacks,<!-- END: TFC:only name:stacks-tfe --> and projects to apply this variable set to. This affects all current and future workspaces<!-- BEGIN: TFC:only name:stacks-tfe --> and Stacks<!-- END: TFC:only name:stacks-tfe --> for any selected projects. After creation, users can also [add this variable set to their workspaces](#apply-or-remove-variable-sets-from-inside-a-workspace).
+      - **Apply to specific projects<!-- BEGIN: TFC:only name:stacks-tfe -->, Stacks,<!-- END: TFC:only name:stacks-tfe --> or workspaces:** Use the text fields to search for and select workspaces<!-- BEGIN: TFC:only name:stacks-tfe -->, Stacks,<!-- END: TFC:only name:stacks-tfe --> and projects to apply this variable set to. This affects all current and future workspaces<!-- BEGIN: TFC:only name:stacks-tfe --> and Stacks<!-- END: TFC:only name:stacks-tfe --> for any selected projects. After creation, users can also [add this variable set to their workspaces](#apply-or-remove-variable-sets-from-inside-a-workspace).
    - Project-owned
       - **Apply to the entire project:** HCP Terraform automatically applies this variable set to all existing and future workspaces<!-- BEGIN: TFC:only name:stacks-tfe --> and Stacks<!-- END: TFC:only name:stacks-tfe --> in the project.
       - **Apply to specific workspaces<!-- BEGIN: TFC:only name:stacks-tfe --> and Stacks<!-- END: TFC:only name:stacks-tfe --> in the project:** Use the text fields to search for and select workspaces<!-- BEGIN: TFC:only name:stacks-tfe --> and Stacks<!-- END: TFC:only name:stacks-tfe --> to apply this variable set to. After creation, users can also [add this variable set to their workspaces](#apply-or-remove-variable-sets-from-inside-a-workspace).
@@ -145,7 +145,7 @@ To edit or remove a variable set:
 
 ### Delete variable sets
 
-Deleting a variable set can be a disruptive action, especially if the variables are required to execute runs. We recommend informing organization, project, <!-- BEGIN: TFC:only name:stacks-tfe --> ,Stack,<!-- END: TFC:only name:stacks-tfe --> and workspace owners before removing a variable set.
+Deleting a variable set can be a disruptive action, especially if the variables are required to execute runs. We recommend informing organization, project<!-- BEGIN: TFC:only name:stacks-tfe --> ,Stack,<!-- END: TFC:only name:stacks-tfe --> and workspace owners before removing a variable set.
 
 To delete a variable set: