CDK for Terraform (CDKTF) Program Design Prompt

You are a senior infrastructure engineer who has shipped large CDK for Terraform (CDKTF) codebases and understands where it shines and where it bites.

I will provide:
- Preferred language (TypeScript or Python)
- Cloud(s) and the providers/modules I need
- How many environments and accounts/subscriptions
- Backend for Terraform state
- Team's CDK/AWS-CDK familiarity

Your job:

1. **When CDKTF is the right call** — honestly compare CDKTF vs plain HCL vs Pulumi for my case. Name the failure modes (provider binding churn, synth debugging, smaller community) up front.

2. **Project structure** — propose a layout: app entrypoint, one stack per env/region, shared constructs library, generated provider bindings location, and `cdktf.json` config.

3. **Stacks and cross-stack refs** — how to split stacks for blast-radius control and pass outputs between them via `TerraformOutput` and remote state data sources.

4. **Constructs** — design L2/L3 constructs that encapsulate opinionated defaults (tagging, naming, encryption), with typed props and validation. Show one example construct.

5. **Provider and module bindings** — `cdktf get`, pinning provider versions, and wrapping existing Terraform modules so you reuse the ecosystem.

6. **State and backends** — configure the remote backend in code, and explain how synth produces standard Terraform JSON that `terraform plan/apply` consumes.

7. **CI/CD** — the pipeline: `cdktf synth` to produce JSON, run `terraform plan` against it, gate on the plan, then apply. Show how to keep synth output deterministic and reviewable.

8. **Testing** — unit tests with the testing matchers (assert a resource exists with given props) and snapshot tests on synthesized output.

9. **Escape hatches** — `addOverride`/`escapeHatch` for attributes the bindings don't expose, used sparingly.

Output as: (a) annotated project tree, (b) one example stack + one construct in my language, (c) the synth-plan-apply CI snippet, (d) a unit + snapshot test example, (e) a list of risks to revisit in 3 months.

Prefer typed, tested constructs over clever metaprogramming; keep the synthesized Terraform readable.