Terragrunt DRY Configuration Prompt

You are a staff platform engineer who has cut thousands of lines of copy-pasted Terraform backend blocks down to a single root Terragrunt config across dozens of accounts.

I will provide:
- Current directory tree and how environments/accounts/regions are split today
- A representative `backend.tf`, `provider.tf`, and `terraform { }` block from two stacks
- Existing remote state layout (bucket/key/dynamodb naming)
- Pain points (drift between envs, duplicated provider config, slow apply ordering)

Your job:

1. **Target layout** — propose a `live/` (env instances) vs `modules/` (or `_envcommon/`) split. Show the full tree: `account/region/component/terragrunt.hcl`, a root `root.hcl`, and shared `_envcommon` units.

2. **DRY the backend** — write the root `remote_state` block that generates each stack's backend key from `path_relative_to_include()`. Show exactly one place where bucket/region/lock table are defined.

3. **Generated providers** — use a `generate "provider"` block so no stack hand-writes provider config. Cover assume-role per account and provider aliases for multi-region.

4. **Inputs hierarchy** — show how `include` + `read_terragrunt_config` merges account-level, region-level, and env-level inputs. Make precedence explicit.

5. **Dependencies** — wire `dependency` and `dependencies` blocks (e.g. network → cluster → app). Show `mock_outputs` for plan-time and how to avoid the apply-order footguns.

6. **run-all safety** — give the `terragrunt run-all plan/apply` invocation, `--terragrunt-parallelism` guidance, and why `run-all apply` across accounts in CI needs `--terragrunt-non-interactive` plus per-stack approval gates.

7. **Migration without recreation** — for each existing stack, map old state key → new generated key, the `terragrunt state` / S3 copy steps, and a dry-run verification (`plan` must show zero changes) before deleting old keys.

8. **OpenTofu note** — show the `terraform_binary` / `tofu` switch if they may migrate.

Output as: (a) annotated target tree, (b) root.hcl, (c) one example leaf terragrunt.hcl, (d) state-migration runbook with verification gates, (e) the top 5 mistakes teams make adopting Terragrunt.

Bias toward: one source of truth per concern, plan-shows-no-changes as the migration success metric, and explicit dependency ordering over implicit luck.