Small stacks feedback (#35896)

website/docs/language/stacks/create/config.mdx

@@ -25,7 +25,7 @@ Before you begin writing your Stack configuration, ensure you have the `terrafor
 
 We recommend [designing your Stack](/terraform/language/stacks/design) before you begin writing your configuration files. 
 
-All of your Stack’s configuration files must use the `.tfstack.hcl` file type. You can set up your Stack configuration into multiple files as in traditional Terraform configurations. For example, you can have `variables.stack.hcl`, `providers.tfstack.hcl`, and we recommend creating one root-level file for your `component` blocks, such as `components.tfstack.hcl`. 
+All of your Stack’s configuration files must use the `.tfstack.hcl` file type. You can set up your Stack configuration into multiple files as in traditional Terraform configurations. For example, you can have `variables.tfstack.hcl`, `providers.tfstack.hcl`, and we recommend creating one root-level file for your `component` blocks, such as `components.tfstack.hcl`. 
 
 The `component` block defines the pieces that make up your Stack. Add a `component` block for each top-level module you want to include in the Stack. Specify the source module, inputs, and providers for each component. 
 

website/docs/language/stacks/deploy/conditions.mdx

@@ -20,7 +20,7 @@ There are two orchestration rule types to choose from:
 1. The `auto_approve` rule executes after a Stack creates a plan and automatically approves a plan if all checks pass.  
 1. The `replan` rule executes after a Stack applies a plan, automatically triggering a replan if all the checks pass.
 
-The `auto-approve` rule is helpful when you know you want a certain type of plan to go ahead without manual intervention. For example, Stacks have a default `auto-approve` rule named `empty_plan`, which auto-approves a plan if it has no changes. 
+The `auto_approve` rule is helpful when you know you want a certain type of plan to go ahead without manual intervention. For example, Stacks have a default `auto_approve` rule named `empty_plan`, which automatically approves a plan if it has no changes. 
 
 As another example, you could create a rule that automatically approves deployments if a component has not changed. 
 
@@ -31,7 +31,7 @@ orchestrate "auto_approve" "no_pet_changes" {
     check {
         # Check that the pet component has no changes
         condition = context.plan.component_changes["component.pet"].total == 0
-        reason = "Not auto-approved because changes proposed to pet component."
+        reason = "Not automatically approved because changes proposed to pet component."
     }
 }
 ```
@@ -67,7 +67,7 @@ The above `orchestrate` block triggers a replan if the production development of
 
 The `orchestrate` block can use the `context` variable, which provides access to detailed information about the deployment plan, such as the number of changes, the specific components involved, and the deployment’s status.
 
-Use `context` to create more sophisticated checks and conditions. For example, you can auto-approve all planning operations.
+Use `context` to create more sophisticated checks and conditions. For example, you can automatically approve all planning operations.
 
 ```hcl
 # deployments.tfdeploy.hcl

website/docs/language/stacks/deploy/config.mdx

@@ -94,7 +94,7 @@ For more details and examples of using the `identity_token` block, refer to [Aut
 
 ## Automatically manage deployments
 
-The `orchestrate` block lets you codify your stack’s behavior by creating orchestration rules, enabling you to manage deployments at scale. For example, you could set an orchestration rule to auto-approve plans or apply operations that don’t contain any changes.
+The `orchestrate` block lets you codify your stack’s behavior by creating orchestration rules, enabling you to manage deployments at scale. For example, you could set an orchestration rule to automatically approve plans or apply operations that don’t contain any changes.
 
 ```hcl
 # deployments.tfdeploy.hcl

website/docs/language/stacks/reference/tfdeploy.mdx

@@ -7,7 +7,7 @@ description: Stacks help you provision and coordinate your infrastructure lifecy
 
 A deployment configuration file defines how to deploy your Stack's infrastructure. Each Stack deployment runs in its agent, wholly isolated from other Stack deployments.
 
-Every Stack needs a deployment configuration file, `tfdeploy.hcl`, and this page describes all of the blocks you can use within a deployment configuration file. Note that none of the blocks in the deployment configuration file support [meta-arguments](/terraform/language/meta-arguments). 
+Every Stack needs a deployment configuration file, `tfdeploy.hcl`, and this page describes all of the blocks you can use within a deployment configuration file. Note that none of the blocks in the deployment configuration file support [meta-arguments](/terraform/language/resources/syntax#meta-arguments). 
 
 ## `deployment` block configuration
 
@@ -65,7 +65,7 @@ The following list outlines field hierarchy, language-specific data types, and r
 When every field is defined, an `orchestrate` block has the following form:
 
 ```hcl
-# auto-approve is the rule type
+# auto_approve is the rule type
 orchestrate "auto_approve" "name_of_check" {
   check {
     condition = <the condition that HCP Terraform evaluates>
@@ -95,7 +95,7 @@ orchestrate "auto_approve" "no_pet_changes" {
 }
 ```
 
-By default, each Stack has an `auto-approve` rule named `empty_plan`, which auto-approves a plan if it contains no changes. 
+By default, each Stack has an `auto_approve` rule named `empty_plan`, which automatically approves a plan if it contains no changes. 
 
 ### Specification
 
@@ -309,49 +309,6 @@ deployment "main" {
 
 You can access specific environment variables by key from the `store.varset.available_regions` store, and you can access specific Terraform variables by key using the `store.varset.tokens` store.
 
-### `varset` specification and configuration
-
-Use the `varset` store to enable your Stacks to access [variable sets](/terraform/cloud-docs/workspaces/variables/managing-variables#variable-sets) in HCP Terraform. Your Stack must have access to the variable set you are targeting, meaning it must be globally available or assigned to the project containing your Stack.
-
-This section details the fields you can configure in the `store` block that uses the `varset` store type.
-
-```
-store "varset" "store_name" {
-  id       = "<variable_set_id>"
-  category = <"terraform" or "env">
-}
-```
-
-The `varset` store type accepts the following fields.
-
-| Field | Description | Type | Required |
-| :---- | :---- | :---- | :---- |
-| `id` | The external ID of the variable set you want to access. | string | Required |
-| `category` | The `category` argument specifies whether to use Terraform or environment variables from the variable set. Specify "terraform" or "env" depending on the variable you want to access. | string | Required |
-
-The `store.varset` block can only use a variable set’s Terraform or environment variables. You can define two `store` blocks if you need to access Terraform and environment variables in your deployment configuration.
-
-```hcl
-store "varset" "tokens" {
-  id       = "varset-###"
-  category = "terraform"
-}
-
-store "varset" "available_regions" {
-  id       = "varset-###"
-  category = "env"
-}
-
-deployment "main" {
-  inputs = {
-    regions = store.varset.available_regions.regions
-    tfe_token        = store.varset.tokens.tfe_token
-  }
-}
-```
-
-You can access specific environment variables by key from the `store.varset.available_regions` store, and you can access specific Terraform variables by key using the `store.varset.tokens` store.
-
 ## `locals` block configuration
 
 A local value assigns a name to an expression, so you can use the name multiple times within your Stack configuration instead of repeating the expression. The `locals` block works exactly as it does in traditional Terraform configurations. Learn more about [the `locals` block](/terraform/language/values/locals).