fix: linked-stacks docs (#36426) (#36439)

Author: github-actions[bot]

website/docs/language/stacks/deploy/pass-data.mdx

@@ -1,6 +1,6 @@
 ---
-page_title: Pass data from one Stack to another  
-description: Learn how to pass data from one Stack to another using `publish_output` blocks to output data from one Stack, and `upstream_input` blocks to input that data into another Stack.   
+page_title: Pass data from one Stack to another
+description: Learn how to pass data from one Stack to another using `publish_output` blocks to output data from one Stack, and `upstream_input` blocks to input that data into another Stack.
 ---
 
 # Pass data from one Stack to another
@@ -10,7 +10,7 @@ If you have multiple Stacks that do not share a provisioning lifecycle, you can
 
 ## Background
 
-You may need to pass data between different Stacks in your project. For example, one Stack in your organization may manage shared services, such as networking infrastructure, and another Stack may manage application components. Using separate Stacks lets you manage the infrastructure independently, but you may still need to share data from your networking Stack to your application Stack. 
+You may need to pass data between different Stacks in your project. For example, one Stack in your organization may manage shared services, such as networking infrastructure, and another Stack may manage application components. Using separate Stacks lets you manage the infrastructure independently, but you may still need to share data from your networking Stack to your application Stack.
 
 To output information from a Stack, declare a `publish_output` block in the deployment configuration of the Stack exporting data. We refer to the Stack that declares a `publish_output` block as the upstream Stack.
 
@@ -24,7 +24,7 @@ Downstream Stacks must also reside in the same project as their upstream Stacks.
 
 ## Declare outputs
 
-You must declare a `publish_output` block in your deployment configuration for each value you want to output from your current Stack. 
+You must declare a `publish_output` block in your deployment configuration for each value you want to output from your current Stack.
 
 For example, you can add a `publish_output` block for the `vpc_id`  in your upstream Stack’s deployment configuration. You can directly reference a deployment's values with the `deployment.deployment_name` syntax.
 
@@ -41,25 +41,25 @@ publish_output "vpc_id" {
 
 </CodeBlockConfig>
 
-After applying your configuration, any Stack in the same project can now reference your network deployment's `vpc_id` output by declaring an `upstream_input` block. 
+After applying your configuration, any Stack in the same project can now reference your network deployment's `vpc_id` output by declaring an `upstream_input` block.
 
-Once you apply a Stack configuration version that includes your `publish_output` block, HCP Terraform publishes a snapshot of those values, which allows HCP Terraform to resolve them. Meaning, you must apply your Stack’s deployment configuration before any downstream Stacks can reference your Stack's outputs. 
+Once you apply a Stack configuration version that includes your `publish_output` block, HCP Terraform publishes a snapshot of those values, which allows HCP Terraform to resolve them. Meaning, you must apply your Stack’s deployment configuration before any downstream Stacks can reference your Stack's outputs.
 
 Learn more about the [`publish_output` block](/terraform/language/stacks/reference/tfdeploy#publish_output-block-configuration).
 
 ## Consume the output from an upstream Stack
 
 Declare an `upstream_input` block in your Stack’s deployment configuration to read values from another Stack's `publish_output` block. Adding an `upstream_input` block creates a dependency on the upstream Stack.
 
-For example, if you want to use the output `vpc_id` from an upstream Stack in the same project, declare an `upstream_input` block in your deployment configuration. 
+For example, if you want to use the output `vpc_id` from an upstream Stack in the same project, declare an `upstream_input` block in your deployment configuration.
 
 <CodeBlockConfig filename="application.tfdeploy.hcl">
 
 ```hcl
 # Application Stack deployment configuration
 
-upstream_input "networking_stack" {
-  type   = "Stack"
+upstream_input "network_stack" {
+  type   = "stack"
   source = "app.terraform.io/hashicorp/Default Project/networking-stack"
 }
 
@@ -72,42 +72,42 @@ deployment "application" {
 
 </CodeBlockConfig>
 
-After pushing your Stack's configuration into HCP Terraform, HCP Terraform searches for the most recently published snapshot of the upstream Stack your configuration references. If no snapshot exists, the downstream Stack's run fails. 
+After pushing your Stack's configuration into HCP Terraform, HCP Terraform searches for the most recently published snapshot of the upstream Stack your configuration references. If no snapshot exists, the downstream Stack's run fails.
 
 If HCP Terraform finds a published snapshot for your referenced upstream Stack, then all of that Stack's outputs are available to this downstream Stack. Add `upstream_input` blocks for every upstream Stack you want to reference. Learn more about the [`upstream_input` block](/terraform/language/stacks/reference/tfdeploy#upstream_input-block-configuration).
 
 
 ## Trigger runs when output values change
 
-If an upstream Stack's published output values change, HCP Terraform automatically triggers runs for any downstream Stacks that rely on those outputs. 
+If an upstream Stack's published output values change, HCP Terraform automatically triggers runs for any downstream Stacks that rely on those outputs.
 
-In the following example, the `application` deployment depends on the upstream networking Stack. 
+In the following example, the `application` deployment depends on the upstream networking Stack.
 
 <CodeBlockConfig filename="application.tfdeploy.hcl">
 
-```hcl  
+```hcl
 # Application Stack deployment configuration
 
-upstream_input "network_stack" {  
-  type   = "Stack"  
-  source = "app.terraform.io/hashicorp/Default Project/networking-stack"  
+upstream_input "network_stack" {
+  type   = "stack"
+  source = "app.terraform.io/hashicorp/Default Project/networking-stack"
 }
 
-deployment "application" {  
-  inputs = {  
-    vpc_id = upstream_input.network_stack.vpc_id  
-  }  
+deployment "application" {
+  inputs = {
+    vpc_id = upstream_input.network_stack.vpc_id
+  }
 }
 ```
 
 </CodeBlockConfig>
 
-The application Stack depends on the networking Stack’s output, so if the `vpc_id` changes then HCP Terraform triggers a new run for the application Stack. This approach allows you to decouple Stacks that have separate life cycles and ensures that updates in an upstream Stack propagate to downstream Stacks. 
+The application Stack depends on the networking Stack’s output, so if the `vpc_id` changes then HCP Terraform triggers a new run for the application Stack. This approach allows you to decouple Stacks that have separate life cycles and ensures that updates in an upstream Stack propagate to downstream Stacks.
 
 ## Remove upstream Stack dependencies
 
 To stop depending on an upstream Stack’s outputs, do the following in your downstream Stack's deployment configuration:
 
-1. Remove the upstream Stack's `upstream_input` block  
+1. Remove the upstream Stack's `upstream_input` block
 1. Remove any references to the upstream Stack's outputs
-1. Push your configuration changes to HCP Terraform and apply the new configuration
+1. Push your configuration changes to HCP Terraform and apply the new configuration

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

@@ -7,11 +7,11 @@ 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/resources/syntax#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
 
-The `deployment` block is where you define how many times you want to deploy your Stack's infrastructure. Each Stack requires at least one `deployment` block, and you can add a new `deployment` block every time you want to deploy your Stack’s infrastructure again. 
+The `deployment` block is where you define how many times you want to deploy your Stack's infrastructure. Each Stack requires at least one `deployment` block, and you can add a new `deployment` block every time you want to deploy your Stack’s infrastructure again.
 
 -> **Note**: HCP Terraform supports up to a maximum of 20 deployments.
 
@@ -43,7 +43,7 @@ Each Stack must have at least one `deployment` block, and the label of the `depl
 
 ### Reference
 
-For example, the following `deployment` block accepts inputs for variables named `aws_region` and `instance_count` and creates a new deployment in HCP Terraform named “production”. 
+For example, the following `deployment` block accepts inputs for variables named `aws_region` and `instance_count` and creates a new deployment in HCP Terraform named “production”.
 
 ```hcl
 deployment "production" {
@@ -76,16 +76,16 @@ orchestrate "auto_approve" "name_of_check" {
 }
 ```
 
-The `orchestrate` block label includes the rule type and the rule name, which together must be unique within the Stack. 
+The `orchestrate` block label includes the rule type and the rule name, which together must be unique within the Stack.
 
 There are two orchestration rules to choose from:
 
-* The `auto_approve` rule executes after a Stack creates a plan and automatically approves a plan if all checks pass.  
+* The `auto_approve` rule executes after a Stack creates a plan and automatically approves a plan if all checks pass.
 * The `replan` rule executes after a Stack applies a plan, automatically triggering a replan if all the checks pass.
 
 HCP Terraform evaluates the `check` blocks within your `orchestrate` block to determine if it should approve a plan. If all of the checks pass, then HCP Terraform approves the plan for you. If one or more `conditions` do not pass, then HCP Terraform shows the `reason` why, and you must manually approve that plan.
 
-By default, each Stack has an `auto_approve` rule named `empty_plan`, which automatically 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
 
@@ -105,7 +105,7 @@ The `check` block contains the following configurable fields.
 
 ### Orchestration Context
 
-A `check` block’s `condition` field has access to a `context` variable, which includes information about the context of the current deployment plan. The `context` variable contains the following fields. 
+A `check` block’s `condition` field has access to a `context` variable, which includes information about the context of the current deployment plan. The `context` variable contains the following fields.
 
 | Field | Description | Type |
 | :---- | :---- | :---- |
@@ -115,7 +115,7 @@ A `check` block’s `condition` field has access to a `context` variable, which
 | `errors` | A set of diagnostic error message objects. | set of objects |
 | `warnings` | A set of diagnostic warning message objects. | set of objects |
 
-The diagnostic message objects that the `context.errors` and `context.warnings` fields return includes the following information. 
+The diagnostic message objects that the `context.errors` and `context.warnings` fields return includes the following information.
 
 | Field | Description | Type |
 | :---- | :---- | :---- |
@@ -166,7 +166,7 @@ If nothing changes in the `component.pet` component, HCP Terraform automatically
 
 ## `identity_token` block configuration
 
-The `identity_token` block defines a JSON Web Token (JWT) that Terraform generates for a given deployment if that `deployment` block references an `identity_token` in its `inputs`. 
+The `identity_token` block defines a JSON Web Token (JWT) that Terraform generates for a given deployment if that `deployment` block references an `identity_token` in its `inputs`.
 
 You can directly pass the token generated by the `identity_token` block to a provider's configuration for OIDC authentication. For more information on authenticating a Stack using OIDC, refer to [Authenticate a Stack](/terraform/language/stacks/deploy/authenticate).
 
@@ -324,7 +324,7 @@ A local value assigns a name to an expression, so you can use the name multiple
 
 The `publish_output` block requires at least Terraform version `terraform_1.10.0-alpha20241009` or higher. Download [latest version of Terraform](https://releases.hashicorp.com/terraform/) to use the most up-to-date functionality.
 
-Specifies a value to export from your current Stack, which other Stacks in the same project can consume. Declare one `publish_output` block for each value to export your Stack.
+The `publish_output` block specifies a value to export from your current Stack, which other Stacks in the same project can consume. Declare one `publish_output` block for each value to export your Stack.
 
 ### Complete configuration
 
@@ -369,13 +369,13 @@ publish_output "vpc_id" {
 
 To learn more about passing information between Stacks, refer to [Pass data from one Stack to another](/terraform/language/stacks/deploy/pass-data).
 
-## `upstream_input` block configuration 
+## `upstream_input` block configuration
 
 The `upstream_input` block requires at least Terraform version `terraform_1.10.0-alpha20241009` or higher. Download [latest version of Terraform](https://releases.hashicorp.com/terraform/) to use the most up-to-date functionality.
 
-The `upstream_input` block specifies another Stack in the same project to consume outputs from. Declare an `upstream_input` block for each Stack you want to reference. If an output from a upstream Stack changes, HCP Terraform automatically triggers runs for any Stacks that depend on those outputs. 
+The `upstream_input` block specifies another Stack in the same project to consume outputs from. Declare an `upstream_input` block for each Stack you want to reference. If an output from a upstream Stack changes, HCP Terraform automatically triggers runs for any Stacks that depend on those outputs.
 
-To learn more about passing information between Stacks, refer to [Pass data from one Stack to another](/terraform/language/stacks/deploy/link-stacks). 
+To learn more about passing information between Stacks, refer to [Pass data from one Stack to another](/terraform/language/stacks/deploy/link-stacks).
 
 ### Complete configuration
 
@@ -424,4 +424,4 @@ deployment "application" {
 
 </CodeBlockConfig>
 
-Your application Stack can now securely consume and use outputs from your network Stack. To learn more about passing information between Stacks, reference [Pass data from one Stack to another](/terraform/language/stacks/deploy/pass-data).
+Your application Stack can now securely consume and use outputs from your network Stack. To learn more about passing information between Stacks, reference [Pass data from one Stack to another](/terraform/language/stacks/deploy/pass-data).