Add Sarah article

Author: rkoron007

content/terraform/v1.13.x/docs/language/stacks/component/declare-providers.mdx

@@ -78,10 +78,10 @@ component "s3" {
 After configuring your provider, you can use the Terraform CLI to generate a provider lock file:
 
 ```shell
-$ terraform stacks providers-lock
+$ terraform stacks init
 ```
 
-If you update a provider version and want to apply those changes to your Stack locally, re-run the [`terraform stacks providers-lock` command](terraform/cli/commands/stacks/providers-lock) to update the provider lock file.
+If you update a provider version and want to apply those changes to your Stack locally, re-run the [`terraform stacks init -upgrade` command](terraform/cli/commands/stacks/init) to update the provider lock file.
 
 ### Dynamic provider configurations
 
@@ -149,15 +149,13 @@ Check your provider in the [Terraform registry](https://registry.terraform.io/)
 
 ## Provider lock file
 
-A Stack cannot run without a lock file for its providers. After defining your providers, use the Terraform CLI to generate a `.terraform.lock.hcl` lock file. The `terraform stacks providers-lock` command creates and updates your `.terraform.lock.hcl` file:
+A Stack cannot run without a lock file for its providers. After defining your providers, use the Terraform CLI to generate a `.terraform.lock.hcl` lock file. The `terraform stacks init` command creates and updates your `.terraform.lock.hcl` file:
 
 ```shell-session
-$ terraform stacks providers-lock
+$ terraform stacks init
 ```
 
-The `terraform stacks providers-lock` command uses the `required_providers` block from your configuration to download the listed providers and compute the provider lock hashes. The `terraform stacks providers-lock` command only checks the `required_providers` block, so you must list all of the providers you use in that block to ensure that the `terraform stacks` CLI can find them.
-
-If you update your Stack’s providers, rerun the `terraform stacks providers-lock` command to update your Stack’s lock file locally. For more details, refer to the [`terraform stacks` commands](/terraform/cli/commands/stacks).
+The `terraform stacks init` command uses the `required_providers` block from your configuration to download the listed providers and compute the provider lock hashes. If you update your Stack’s providers, run `terraform stacks init -upgrade` command to update your Stack’s lock file locally. For more details, refer to the [`terraform stacks` commands](/terraform/cli/commands/stacks).
 
 ## Next steps
 

content/terraform/v1.13.x/docs/language/stacks/deploy/authenticate.mdx

@@ -13,7 +13,7 @@ We recommend authenticating your Stack with OIDC because using static credential
 
 ## Authenticate with OIDC
 
-[OpenID Connect](https://openid.net/connect/) (OIDC) is an identity layer on top of the OAuth 2.0 protocol. You can use HCP Terraform’s [Workload identity](/terraform/cloud-docs/workspaces/dynamic-provider-credentials/workload-identity-tokens) tokens, built on the OpenID Connect protocol, to securely connect and authenticate your Stacks with cloud providers.
+[OpenID Connect](https://openid.net/connect/) (OIDC) is an identity layer on top of the OAuth 2.0 protocol. You can use HCP Terraform's [Workload identity](/terraform/cloud-docs/workspaces/dynamic-provider-credentials/workload-identity-tokens) tokens, built on the OpenID Connect protocol, to securely connect and authenticate your Stacks with cloud providers.
 
 -> **Hands on**: Walk through setting up OIDC for a Stack in the [Deploy a Stack with HCP Terraform](/terraform/tutorials/cloud/stacks-deploy) tutorial.
 
@@ -24,9 +24,9 @@ Stacks have a built-in `identity_token` block that creates workload identity tok
 The details of Stack authentication differ based on which cloud provider you are setting up, but the basic steps remain the same:
 
 1. Set up the trust configuration between your cloud provider and HCP Terraform, which usually includes creating roles and policies for your cloud provider.
-1. Add an `identity_token` block to your Stack’s deployment file using the audience and roles you created in the previous step.
+1. Add an `identity_token` block to your Stack's deployment file using the audience and roles you created in the previous step.
 
-Your deployments can reference the value of the `identity_token` block to pass the trust relationship role to your Stack’s operations.
+Your deployments can reference the value of the `identity_token` block to pass the trust relationship role to your Stack's operations.
 
 ### Configure trust configuration
 
@@ -127,8 +127,7 @@ output "role_arn" {
 
 </CodeBlockConfig>
 
-
-After setting up your workspace in HCP Terraform, perform a plan and apply operation. HCP Terraform will create your OpenID provider, policy, and role before outputting your new role’s ARN with the `role_arn` output. Copy your new AWS ARN role because this is the value you use to configure your cloud provider with your Stack and HCP Terraform.
+After setting up your workspace in HCP Terraform, perform a plan and apply operation. HCP Terraform will create your OpenID provider, policy, and role before outputting your new role's ARN with the `role_arn` output. Copy your new AWS ARN role because this is the value you use to configure your cloud provider with your Stack and HCP Terraform.
 
 To learn more about the workload identity trust claims and metadata, refer to the `identity_token` block reference](/terraform/language/block/stack/deploy/identity_token#token-attributes).
 
@@ -140,63 +139,62 @@ When you define the `identity_token` block, you specify its audience. For exampl
 
 ```hcl
 identity_token "aws" {
-    audience = ["aws.workload.identity"]
+  audience = ["aws.workload.identity"]
 }
 ```
 
-Once defined, you can reference an identity token in a deployment's input variables and reference that token in a provider’s configuration.
+Once defined, you can reference an identity token in a deployment's input variables and reference that token in a provider's configuration.
 
 You also need to add your trust relationship, your role ARN, to configure your token with the trust relationship to authenticate AWS resources.
 
 <CodeBlockConfig filename="deployments.tfdeploy.hcl">
 
 ```hcl
 identity_token "aws" {
-    audience = ["aws.workload.identity"]
+  audience = ["aws.workload.identity"]
 }
 
 deployment "development" {
-    inputs = {
-        role_arn   	= "<YOUR_ROLE_ARN>"
-        identity_token = identity_token.aws.jwt
-    }
+  inputs = {
+    role_arn       = "<YOUR_ROLE_ARN>"
+    identity_token = identity_token.aws.jwt
+  }
 }
 ```
 
 </CodeBlockConfig>
 
-Now, the deployments are authenticated with AWS and can pass the trust configuration to your Stack’s providers for authentication.
-
+Now, the deployments are authenticated with AWS and can pass the trust configuration to your Stack's providers for authentication.
 
 ```hcl
 # variables.tfcomponent.hcl
 
 variable "role_arn" {
-    type = string
+  type = string
 }
 
 variable "identity_token" {
-    type      = string
-    ephemeral = true
+  type      = string
+  ephemeral = true
 }
 
 # providers.tfcomponent.hcl
 
 required_providers {
-    aws = {
-        source  = "hashicorp/aws"
-        version = "~> 5.7.0"
-    }
+  aws = {
+    source  = "hashicorp/aws"
+    version = "~> 5.7.0"
+  }
 }
 
 provider "aws" "this" {
-    config {
-        region = var.region
-        assume_role_with_web_identity {
-            role_arn           = var.aws_role
-            web_identity_token = var.aws_token
-        }
+  config {
+    region = var.region
+    assume_role_with_web_identity {
+      role_arn           = var.aws_role
+      web_identity_token = var.aws_token
     }
+  }
 }
 ```
 
@@ -214,27 +212,27 @@ Next, add a `store` block to your deployment configuration file to access the va
 
 ```hcl
 store "varset" "tokens" {
-  name       = "Example_Varset_Name"
+  name     = "Example_Varset_Name"
   category = "env"
 }
 ```
 
 </CodeBlockConfig>
 
-Once defined, your deployments can access your variable set’s values. In the following example, the `test` deployment uses the `tokens` store to access the variable set named `Example_Varset_Name`:
+Once defined, your deployments can access your variable set's values. In the following example, the `test` deployment uses the `tokens` store to access the variable set named `Example_Varset_Name`:
 
 <CodeBlockConfig filename="deployments.tfdeploy.hcl">
 
 ```hcl
 store "varset" "tokens" {
-  name       = "Example_Varset_Name"
+  name     = "Example_Varset_Name"
   category = "env"
 }
 
 deployment "test" {
   inputs = {
-    access_key = store.varset.tokens.AWS_ACCESS_KEY_ID
-    secret_key = store.varset.tokens.AWS_SECRET_ACCESS_KEY
+    access_key    = store.varset.tokens.AWS_ACCESS_KEY_ID
+    secret_key    = store.varset.tokens.AWS_SECRET_ACCESS_KEY
     session_token = store.varset.tokens.AWS_SESSION_TOKEN
   }
 }
@@ -249,22 +247,22 @@ After defining a `store` block, deployments can reference specific values from t
 ```hcl
 variable "access_key" {
   description = "AWS access key"
-  type     = string
-  ephemeral = true
+  type        = string
+  ephemeral   = true
 }
 
 variable "secret_key" {
   description = "AWS sensitive secret key."
-  type     = string
-  sensitive = true
-  ephemeral = true
+  type        = string
+  sensitive   = true
+  ephemeral   = true
 }
 
 variable "session_token" {
   description = "AWS session token."
-  type     = string
-  sensitive = true
-  ephemeral = true
+  type        = string
+  sensitive   = true
+  ephemeral   = true
 }
 
 required_providers {
@@ -278,15 +276,13 @@ provider "aws" "this" {
   config {
     access_key = var.access_key
     secret_key = var.secret_key
-    token = var.session_token
+    token      = var.session_token
   }
 }
 ```
 
 </CodeBlockConfig>
 
-
 By default, Stacks deployments do not save the values of variable sets into their state, because variable set values usually include sensitive data, such as passwords or API keys. For variables that need to persist in your deployment state, such as license keys, you can use the `stable` keyword. To learn more, refer to [Persist store values for deployments](/terraform/language/block/stack/deploy/store#persist-store-values-for-deployments).
 
-
 For more information and examples about the `store` block, refer to the [`store` block reference](/terraform/language/block/stack/deploy/store).

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

@@ -5,7 +5,7 @@ description: Learn how to write Stack deployment configuration files to define h
 
 # Define deployment configuration
 
-In Stacks, deployments let you replicate infrastructure across multiple environments, regions, or accounts. Each deployment has in its own isolated state, ensuring that changes in one deployment do not affect others. Learn how to write a deployment configuration to define how HCP Terraform deploys your infrastructure.
+In Stacks, deployments let you replicate infrastructure across multiple environments, regions, or accounts. Each deployment has its own isolated state, ensuring that changes in one deployment do not affect others. Learn how to write a deployment configuration to define how HCP Terraform deploys your infrastructure.
 
 ## Background
 
@@ -22,7 +22,7 @@ You can also create deployment groups to define rules that let you auto-approve
 
 ## Write a deployment configuration file
 
-Deployment configuration files live at the top level of your repository and use the `.tfdeploy.hcl` file extension. We recommend naming your deployments file `deployments.tfdeploy.hcl`.
+Deployment configuration files live at the top level of your repository and use the `.tfdeploy.hcl` file extension. You can organize your deployment configuration into multiple files, as in traditional Terraform configurations.
 
 You can define the following blocks in deployment configuration files to support setting up your Stack's deployments:
 
@@ -149,6 +149,8 @@ To learn more about the `identity_token` block, refer to the [`identity_token` b
 
 ## Automatically approve deployment runs
 
+@include 'premium-deployment-groups.mdx'
+
 You can create deployment groups to define rules that let you auto-approve deployment runs that match your specified criteria.
 
 
@@ -158,7 +160,6 @@ Deployment groups only support one deployment per group at this time.
 
 </Note>
 
-
 Define a `deployment_group` block to create a new group, and specify the auto-approve rules that deployment group enforces. In the following example, the `production` deployment group enforces the `no_destroys` rule:
 
 <CodeBlockConfig filename="deployments.tfdeploy.hcl">

content/terraform/v1.13.x/docs/language/stacks/update-GA.mdx

@@ -0,0 +1,111 @@
+---
+page_title: Stack configuration files for Terraform
+description: |-
+  Learn about the new general release of Stacks and how to migrate from the beta to the general release.
+---
+
+# Move from Stacks beta to general availability
+
+The GA release of Stacks introduces several new features and improvements.
+
+## Terraform CLI changes
+
+During the Stacks beta, you could initialize your Stack using the `terraform-stacks-cli`. The separate `terraform-stacks-cli` is now deprecated. To provide a more unified experience, all Stacks commands are now in the main Terraform CLI as a new subcommand: `terraform stacks`. You can now manage all of your Terraform Stack operations from a single tool, streamlining your workflow. To learn more, refer to [the `terraform stacks` CLI commands](/terraform/cli/commands/stacks).
+
+## Language changes
+
+The general availability release of Stacks introduced a few backward-incompatible syntax changes to the Stacks language:
+
+- Syntax change for deployment groups and auto-approval:
+  - The `auto_approve`, `orchestrate`, and `replan` blocks for orchestration rule are now deprecated.
+  - The `auto_approve` block is replaced by a new auto_approve_checks argument on the deployment_group block. The new `deployment_group` syntax lets you define auto-approval rules directly within your custom deployment groups, giving you more granular control. [Learn more about defining conditions for your deployment runs](/terraform/language/stacks/deploy/conditions).
+- Stacks no longer support the `<NAME>.tfstack.hcl` file extension.
+  - The new extension for configuring your Stack components is `<NAME>.tfcomponent.hcl`. The file name change better reflects the mental model of a component-based configuration.
+
+## Billing Changes
+
+The Stacks public beta did not count toward your HCP Terraform organization's Resources Under Management (RUM). With the GA release, Stacks RUM is aggregated with your workspace RUM for billing purposes.
+
+### Billing Dashboard
+
+The HCP Terraform usage page has been updated to reflect the new billing metrics, including:
+
+- **Billable Managed Resources** displays the sum of your total Stacks and total workspace RUM.
+- **Total Applies** displays the sum of your total Stacks and workspace applies.
+- **Applies this month** displays the Stacks and workspace applies this month.
+- **Billable Stack Resources** displays the sum of your total Stacks RUM.
+
+For more information on billing, refer to the [HCP Terraform pricing page](https://www.hashicorp.com/en/pricing).
+
+## Steps for migration
+
+If you used Stacks during the public beta, you need to take a few steps to transition your existing configurations to the GA release.
+
+<Note>
+
+After the release of Stacks in general availability, your existing beta configurations and state history are no longer available.
+
+</Note>
+
+### Update your configuration files
+
+Perform the following updates to your Stack configuration files to use the new `tfcomponent.hcl` file extension and the new syntax for deployment groups and auto-approval rules:
+
+1. Rename all of your `<NAME>.tfstack.hcl` files to `<NAME>.tfcomponent.hcl`. For example you could run the following command to rename your file:
+
+<CodeBlockConfig>
+
+```shell-session
+$ mv my_stack.tfstack.hcl my_stack.tfcomponent.hcl
+```
+
+</CodeBlockConfig>
+
+2. Update your configuration files to use the new `deployment_group` syntax for auto-approval. For example, the following code snippet uses the deprecated `orchestrate` block:
+
+<CodeBlockConfig>
+
+```hcl
+orchestrate "auto_approve" "no_destroy" {
+  check {
+    condition = context.plan.changes.remove == 0
+    reason    = "Plan destroys ${context.plan.changes.remove} resources."
+  }
+}
+```
+
+</CodeBlockConfig>
+
+You can rewrite your auto-approval rules using the `deployment_auto_approve` block to define your rules, then attaching those rules to deployment groups using the `auto_approve_checks` argument. The following example rewrites the `auto_approve` rule using deployment groups:
+
+<CodeBlockConfig filename="deployments.tfdeploy.hcl">
+
+```hcl
+deployment "my_deployment" {
+  inputs = {
+    # ...
+  }
+  deployment_group = deployment_group.my_custom_group
+}
+
+deployment_group "my_custom_group" {
+  auto_approve_checks = [
+    deployment_auto_approve.no_destroy
+  ]
+}
+
+deployment_auto_approve "no_destroy" {
+  check {
+    condition = context.plan.changes.remove == 0
+    reason    = "Plan destroys ${context.plan.changes.remove} resources."
+  }
+}
+```
+
+</CodeBlockConfig>
+
+For more information about deployment groups and auto-approval rules, refer to [Defining conditions for your deployment runs](/terraform/language/stacks/deploy/conditions).
+
+### Fetch your configuration
+
+Trigger a new configuration fetch for each of your Stacks. The fetching process pulls your configuration from your Version Control System (VCS) and reinitializes your Stack. You can do this by using the [`terraform stacks fetch`](/terraform/cli/commands/stacks/configuration/fetch) command in the new CLI, or by triggering a deployment run in the HCP Terraform UI.