Backend docs up to date

Author: rkoron007

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

@@ -27,7 +27,7 @@
   },
   {
     "title": "Migrate to HCP Terraform",
-    "path": "migrate"   
+    "path": "migrate"
   },
   {
     "title": "API",

content/terraform/v1.13.x/data/language-nav-data.json

@@ -31,7 +31,7 @@
       { "title": "Override files", "path": "files/override" },
       { "title": "Dependency lock file", "path": "files/dependency-lock" },
       { "title": "Test files", "path": "files/tests" },
-      { "title": "Stack Files", "path": "files/stack" }
+      { "title": "Stack files", "path": "files/stack" }
     ]
   },
   {

content/terraform/v1.13.x/docs/language/block/stack/component_configuration/index.mdx

@@ -20,15 +20,9 @@ Each Stack requires at least one `component` block, and you must add a `componen
 You can define the following blocks in component configuration files:
 
 - The [`component`](/terraform/language/block/stack/configuration/component) block sources individual modules that make up your Stack. Each component receives input variables and accepts providers that you declare at the Stack level.
-
 - The [`required_providers`](/terraform/language/block/stack/configuration/required_providers) block declares which providers your component configuration requires so that Terraform can install and use them.
-
 - The [`provider`](/terraform/language/block/stack/configuration/provider) block configures providers and passes that configuration to components.
-
 - The [`removed`](/terraform/language/block/stack/configuration/removed) block defines components you want to remove from your Stack while ensuring proper cleanup of resources.
-
 - The [`variable`](/terraform/language/block/stack/configuration/variable) block defines input variables that your deployments can set with different values.
-
 - The [`output`](/terraform/language/block/stack/configuration/output) block defines values to expose in the HCP Terraform UI and to make available to deployments.
-
 - The [`locals`](/terraform/language/block/locals) block defines local values that you can reference within your component configuration.

content/terraform/v1.13.x/docs/language/block/stack/deploy/deployment.mdx

@@ -120,7 +120,7 @@ deployment "<LABEL>" {
 }
 ```
 
-You can use deployment groups to enable orchestration rules which can manage your deployment's lifecycle. For more details on deployment groups, refer to the [Set conditions for deployment plans](/terraform/language/stacks/deploy/conditions).
+You can use deployment groups to enable orchestration rules which can manage your deployment's lifecycle. For more details on deployment groups, refer to the [Set conditions for deployment runs](/terraform/language/stacks/deploy/conditions).
 
 If a deployment does not specify a deployment group, Terraform automatically generates an independent deployment group for it named `<DEPLOYMENT_NAME>_default`.
 
@@ -215,7 +215,7 @@ deployment "web" {
 }
 ```
 
-You can use deployment groups to enable orchestration rules which can manage your deployment's lifecycle. For more details on deployment groups, refer to the [Set conditions for deployment plans](/terraform/language/stacks/deploy/conditions).
+You can use deployment groups to enable orchestration rules which can manage your deployment's lifecycle. For more details on deployment groups, refer to the [Set conditions for deployment runs](/terraform/language/stacks/deploy/conditions).
 
 ### Multiple deployments
 

content/terraform/v1.13.x/docs/language/block/stack/deploy/deployment_group.mdx

@@ -17,7 +17,7 @@ Deployment groups only support one deployment per group at this time.
 
 The `deployment_group` block defines a new group that you can assign individual deployments to join. You can assign a deployment to a group [using the `deployment_group` argument in a `deployment` block](/terraform/language/block/stack/deploy/deployment#deployment_group). If you don't assign a deployment to a group, Terraform automatically creates a default deployment group for that deployment.
 
-Deployment groups let you enforce orchestration rules on the deployments within the group. To learn more, refer to [Set conditions for deployment plans](/terraform/language/stacks/deploy/conditions).
+Deployment groups let you enforce orchestration rules on the deployments within the group. To learn more, refer to [Set conditions for deployment runs](/terraform/language/stacks/deploy/conditions).
 
 ## Configuration model
 

content/terraform/v1.13.x/docs/language/block/stack/deploy/index.mdx

@@ -20,17 +20,10 @@ To learn more, refer to [Define deployment configuration](/terraform/language/st
 You can define the following blocks in deployment configuration files:
 
 - The [`deployment`](/terraform/language/block/stack/deployment/deployment) block defines how many times you want to deploy your Stack's infrastructure and with what input values.
-
 - The [`deployment_group`](/terraform/language/block/stack/deployment/deployment_group) block groups deployments together to configure shared settings and auto-approval rules.
-
 - The [`deployment_auto_approve`](/terraform/language/block/stack/deployment/deployment_auto_approve) block defines rules that automatically approve deployment plans based on specific conditions.
-
 - The [`identity_token`](/terraform/language/block/stack/deployment/identity_token) block defines JSON Web Tokens (JWT) that Terraform generates for OIDC authentication with cloud providers.
-
 - The [`store`](/terraform/language/block/stack/deployment/store) block provides access to external secret stores and variable sets from your deployment configuration.
-
 - The [`publish_output`](/terraform/language/block/stack/deployment/publish_output) block exports values from your Stack that other Stacks in the same project can consume.
-
 - The [`upstream_input`](/terraform/language/block/stack/deployment/upstream_input) block consumes outputs from another Stack in the same project and uses them as inputs in your current Stack.
-
 - The [`locals`](/terraform/language/block/locals) block defines local values that you can reference within your deployment configuration.

content/terraform/v1.13.x/docs/language/files/stack.mdx

@@ -0,0 +1,67 @@
+---
+page_title: Stack configuration files for Terraform
+description: |-
+  Learn about the two types of configuration files that make up a Stack. The component configuration file defines the pieces that make up a Stack, and deployment configuration files defines how to deploy that infrastructure.
+---
+
+# Stack configuration files
+
+[Stacks](/terraform/language/stacks) use two types of configuration files to separate defining the components of your infrastructure from deployment details. Use a component configuration to define your infrastructure once, and a deployment configuration to deploy that infrastructure multiple times with different configurations.
+
+## File types
+
+A Stack configuration is made up of of two different file types:
+
+- Component files, ending in `.tfcomponent.hcl`, declare the infrastructure components that this Stack creates and the input values of those components.
+- Deployment files, ending in `.tfdeploy.hcl`, declare how many times to deploy a stack and the input values for each deployment.
+
+### Component configuration files
+
+Component files, ending in `.tfcomponent.hcl`, define the infrastructure components that make up your Stack. Component configuration files focus on what infrastructure you want to create, without specifying where or how many times to deploy it.
+
+The component configuration replaces Terraform's traditional root module structure and declares which modules to include, how to configure providers, and what variables your Stack accepts. Each Stack requires at least one `component` block, and you must add a `component` block for every module you want to include in your Stack. Learn more about [writing a component configuration](/terraform/language/stacks/component/config).
+
+You can define the following blocks in component configuration files:
+
+- The [`component`](/terraform/language/block/stack/configuration/component) block sources individual modules that make up your Stack. Each component receives input variables and accepts providers that you declare at the Stack level.
+- The [`required_providers`](/terraform/language/block/stack/configuration/required_providers) block declares which providers your component configuration requires so that Terraform can install and use them.
+- The [`provider`](/terraform/language/block/stack/configuration/provider) block configures providers and passes that configuration to components.
+- The [`removed`](/terraform/language/block/stack/configuration/removed) block defines components you want to remove from your Stack while ensuring proper cleanup of resources.
+- The [`variable`](/terraform/language/block/stack/configuration/variable) block defines input variables that your deployments can set with different values.
+- The [`output`](/terraform/language/block/stack/configuration/output) block defines values to expose in the HCP Terraform UI and to make available to deployments.
+- The [`locals`](/terraform/language/block/locals) block defines local values that you can reference within your component configuration.
+
+You can separate your component configuration into several files for easier navigability. For example, the following file structure separates a Stack's components from the other other blocks that help configure those components:
+
+- `components.tfcomponent.hcl` - Defines your Stack's components
+- `providers.tfcomponent.hcl` - Configures providers in this Stack
+- `variables.tfcomponent.hcl` - Declares input variables in this Stack
+- `outputs.tfcomponent.hcl` - Defines output values of this Stack
+
+### Deployment configuration files
+
+Deployment configuration files (`.tfdeploy.hcl`) define how HCP Terraform deploys your Stack's infrastructure. Deployment configuration files focus on where and how to deploy your infrastructure, using the components you defined in your component configuration.
+
+Your Stack must have at least one `deployment` block. The deployment configuration file specifies how many deployments to create, what values to pass to each deployment, and how to orchestrate the deployment run process.
+
+You can define the following blocks in deployment configuration files:
+
+- The [`deployment`](/terraform/language/block/stack/deployment/deployment) block defines how many times you want to deploy your Stack's infrastructure and with what input values.
+- The [`deployment_group`](/terraform/language/block/stack/deployment/deployment_group) block groups deployments together to configure shared settings and auto-approval rules.
+- The [`deployment_auto_approve`](/terraform/language/block/stack/deployment/deployment_auto_approve) block defines rules that automatically approve deployment plans based on specific conditions.
+- The [`identity_token`](/terraform/language/block/stack/deployment/identity_token) block defines JSON Web Tokens (JWT) that Terraform generates for OIDC authentication with cloud providers.
+- The [`store`](/terraform/language/block/stack/deployment/store) block provides access to external secret stores and variable sets from your deployment configuration.
+- The [`publish_output`](/terraform/language/block/stack/deployment/publish_output) block exports values from your Stack that other Stacks in the same project can consume.
+- The [`upstream_input`](/terraform/language/block/stack/deployment/upstream_input) block consumes outputs from another Stack in the same project and uses them as inputs in your current Stack.
+- The [`locals`](/terraform/language/block/locals) block defines local values that you can reference within your deployment configuration.
+
+## File organization
+
+HCP Terraform processes all the configuration files in your Stack's root directory, regardless of their names. You can organize your configuration across multiple files based on your preferences, similar to traditional Terraform configurations.
+
+Both component configuration and deployment configurations must reside at the root level of your Stack repository. HCP Terraform automatically discovers and processes all `.tfcomponent.hcl` and `.tfdeploy.hcl` files in dependency order.
+
+## Next steps
+
+- Learn how to write [component configuration](/terraform/language/stacks/component/config) files
+- Learn how to write [deployment configuration](/terraform/language/stacks/deploy/create) files

content/terraform/v1.13.x/docs/language/stacks/component/config.mdx

@@ -13,13 +13,27 @@ Your component configuration file defines multiple components that share a lifec
 
 You declare the infrastructure that makes up your Stack in the component configuration file. Component configuration files replace Terraform’s traditional root module and serve as the blueprint for what your Stack deploys.
 
-Component configuration files use a new file type, `tfcomponent.hcl`, to define everything that shares your Stack’s lifecycle. After writing your component configuration, you can write a deployment configuration to dictate how HCP Terraform deploys your Stack’s infrastructure.
+Component configuration files use the `<NAME>.tfcomponent.hcl` file type, and define everything that shares your Stack’s lifecycle. After writing your component configuration, you can write a [deployment configuration](/terraform/language/stacks/deploy/config) to dictate how HCP Terraform deploys your Stack’s infrastructure.
 
-As with Terraform configuration files, HCP Terraform processes all of the blocks in your component configuration and deployment configuration files in your Stack's root directory in dependency order. You can organize your component configuration into multiple files as in traditional Terraform configurations.
+As with Terraform configuration files, HCP Terraform processes all of the blocks in your component configuration and deployment configuration files in your Stack's root directory in dependency order. You can organize your component configuration into multiple files, as in traditional Terraform configurations.
 
 ### Requirements
 
-Before you begin writing your component configuration, ensure you have the `terraform-stacks-cli` for initializing and validating your component configurations. For installation guidance, refer to the [Stacks CLI reference](/terraform/language/stacks/reference/tfcomponents-cli).
+Use Terraform v1.13.x or later to access the Stacks CLI plugin, and run  `terraform stacks` CLI commands.
+
+During the beta release, Stacks had a separate [Terraform Stacks CLI](/terraform/language/v1.12.x/stacks/reference/tfstacks-cli), which no longer supports current functionality.
+
+## Create a version file
+
+Begin by adding a `.terraform-version` file to your Stack's root directory to specify the Terraform version required for your Stack. For example, the following file specifies Terraform v1.13.0:
+
+<CodeBlockConfig filename=".terraform-version">
+
+```hcl
+1.13.0
+```
+
+</CodeBlockConfig>
 
 ## Define your component configuration
 
@@ -29,9 +43,9 @@ All of your Stack’s configuration files must use the `.tfcomponent.hcl` file t
 
 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.
 
-```hcl
-# components.tfcomponent.hcl
+<CodeBlockConfig filename="components.tfcomponent.hcl">
 
+```hcl
 component "cluster" {
     source = "./eks"
     inputs = {
@@ -48,15 +62,16 @@ component "cluster" {
 }
 ```
 
-After establishing your top-level modules, you can use child modules without adding additional `component` blocks.
+</CodeBlockConfig>
+
 
-The component configuration file type accepts most classic Terraform configuration blocks but with some key differences. For more details on declaring providers in Stacks, refer to [Declare providers](/terraform/language/stacks/component/declare-providers). For more information on the component configuration file type and all the blocks and attributes it accepts, refer to the [Configuration file reference](/terraform/language/stacks/reference/tfcomponent).
+After establishing your top-level modules, you can use child modules without adding additional `component` blocks.
 
 The `component` block supports the `for_each` meta-argument if you need to replicate components across multiple instances. For example, the following configuration uses `for_each` to provision modules in multiple AWS regions for a given environment.
 
-```hcl
-# components.tfcomponent.hcl
+<CodeBlockConfig filename="components.tfcomponent.hcl">
 
+```hcl
 component "s3" {
     for_each = var.regions
 
@@ -73,19 +88,40 @@ component "s3" {
 }
 ```
 
-After writing your component configuration, use the Terraform Stacks CLI to validate it.
+</CodeBlockConfig>
+
+
+You can define the following blocks in component configuration files to configure your Stack's components:
+
+- The [`component`](/terraform/language/block/stack/configuration/component) block sources individual modules that make up your Stack. Each component receives input variables and accepts providers that you declare at the Stack level.
+- The [`required_providers`](/terraform/language/block/stack/configuration/required_providers) block declares which providers your component configuration requires so that Terraform can install and use them.
+- The [`provider`](/terraform/language/block/stack/configuration/provider) block configures providers and passes that configuration to components.
+- The [`removed`](/terraform/language/block/stack/configuration/removed) block defines components you want to remove from your Stack while ensuring proper cleanup of resources.
+- The [`variable`](/terraform/language/block/stack/configuration/variable) block defines input variables that your deployments can set with different values.
+- The [`output`](/terraform/language/block/stack/configuration/output) block defines values to expose in the HCP Terraform UI and to make available to deployments.
+- The [`locals`](/terraform/language/block/locals) block defines local values that you can reference within your component configuration.
+
+Provider authentication works differently for a Stack, for more details on declaring providers in Stacks, refer to [Declare providers](/terraform/language/stacks/component/declare-providers).
+
+After writing your component configuration, you can validate your configuration locally using the Terraform CLI.
 
 ## Validate your configuration
 
-Once you have finished your component configuration, use the `terraform-stacks-cli` tool to validate your configuration and generate the necessary provider lock files.
+Once you have finished your component configuration, you can use [`terraform stacks` CLI](/terraform/cli/commands/stacks) commands to validate your configuration and generate the necessary provider lock files.
 
 ```shell-session
-$ tfcomponents init
-$ tfcomponents validate
+$ terraform stacks init
+$ terraform stacks validate
 ```
 
-For installation guidance and more details, refer to the [Stacks CLI](/terraform/language/stacks/reference/tfcomponents-cli).
+You can also re-format your configuration files using the `terraform fmt` command to ensure consistent styling:
+
+```shell-session
+$ terraform stacks fmt
+```
 
 ## Next steps
 
 If you have not yet defined the providers for your Stack, proceed to [Declare providers](/terraform/language/stacks/component/declare-providers). You can also learn how to [Authenticate your Stack](/terraform/language/stacks/deploy/authenticate) to ensure your providers are properly set up.
+
+After completing your component configuration, the next step is to [define your deployment configuration](/terraform/language/stacks/deploy/config) to specify how you want to deploy your Stack's infrastructure.