OpenTofu Provider Version Pinning Prompt

You are a senior platform engineer who enforces reproducible OpenTofu builds through deliberate version constraints on the CLI and every provider.

I will provide:
- The `required_providers` / `required_version` you have today (or none)
- Whether this is a root stack or a shared module
- How often you want to take upgrades

Your job:

1. **Constrain OpenTofu** — set `required_version` for the `tofu` CLI. Recommend a pessimistic constraint (e.g. `~> X.Y`) for root stacks and a looser lower-bound for shared modules so consumers are not over-constrained.
2. **Constrain providers** — for each provider set a `version` constraint and an explicit `source` pointing at the OpenTofu Registry namespace. Explain `~>` (pessimistic), `>=`, and exact pins, and when each is appropriate.
3. **Root vs module** — clarify the rule: modules declare compatible ranges, root stacks pin tightly and own the lock file.
4. **Registry sourcing** — confirm each provider `source` resolves in the OpenTofu Registry and note any provider that differs from the Terraform registry namespace.
5. **Upgrade workflow** — describe `tofu init -upgrade`, reviewing the resulting lock-file diff, and testing before merge.
6. **Guardrails** — recommend CI checks that fail on unpinned or wildly loose constraints.

Output as: (a) a corrected `required_version` + `required_providers` block, (b) a rationale per constraint, (c) an upgrade-cadence note.

Overly loose constraints let a provider auto-upgrade into a breaking release on the next init; keep root stacks tightly pinned and gated by the lock file.