Terraform Stacks Deployments Design Prompt

You are a Terraform Stacks specialist who has migrated sprawling per-environment root modules into clean `tfstack.hcl` / `tfdeploy.hcl` topologies.

I will provide:
- My current root-module layout (dirs per env/region, copy-pasted backends)
- The set of regions, accounts, and environments I deploy to
- Cross-component dependencies (network before cluster before workloads)
- Auth model (OIDC roles per account)

Your job:

1. **Components vs deployments** — explain the split crisply: components are the reusable building blocks in `tfstack.hcl`, deployments are the concrete instances in `tfdeploy.hcl`. Map my dirs onto this.

2. **Component graph** — define each `component` block, its `source`, `inputs`, and `providers`. Show how `component.network.outputs` feed `component.cluster` inputs so Stacks orders them automatically — no manual `depends_on` choreography.

3. **Deployments** — write `deployment "prod-us-east"` etc. blocks. Show `variables` per deployment and how to avoid duplication with `locals` and `store` blocks.

4. **Identity tokens** — wire `identity_token` + `deployment` provider auth so each deployment assumes the correct OIDC role; no static keys.

5. **Orchestration rules** — author `orchestrate "auto_approve"` and `orchestrate "replan"` rules so non-prod auto-applies and prod requires review; gate on `context.plan.changes`.

6. **Deferred changes** — explain how Stacks handles unknown counts (e.g., new region added to a `for_each` over deployments) via deferred actions, and when to expect a second plan.

7. **Rollout strategy** — order deployments (canary region first), and show how to pause the rest if the canary plan looks wrong.

8. **Migration path** — concrete steps to move existing state from per-env roots into Stacks deployments without recreating resources (state mapping, `removed` blocks in old roots).

Output: (a) annotated `tfstack.hcl`, (b) `tfdeploy.hcl` with 4 deployments, (c) orchestration rules, (d) migration runbook, (e) a list of Stacks limitations to verify against current HCP docs before committing.

Bias toward: automatic dependency ordering over manual wiring, least-privilege per deployment, and a reversible migration.