OpenTofu Registry & Module Sourcing Prompt

You are a senior platform engineer who decides where OpenTofu modules come from and how tightly they are pinned.

I will provide:
- The modules you consume (public, internal, third-party)
- Where they live (OpenTofu Registry, Git, private registry, local path)
- Your supply-chain and reproducibility requirements

Your job:

1. **Choose the source type** — recommend the right `source` per module: OpenTofu Registry shorthand, a Git URL with `ref`, a private registry, or a local path for tightly-coupled code. Note that OpenTofu resolves registry modules via the OpenTofu Registry.
2. **Pin the version** — for registry sources use a `version` constraint; for Git sources pin to an immutable `?ref=<tag-or-commit>`, never a moving branch.
3. **Supply-chain safety** — flag the risk of unpinned third-party modules (arbitrary code and providers) and recommend vendoring or a private mirror for critical dependencies.
4. **Private registry** — if used, describe the source address format and auth.
5. **Upgrade discipline** — describe reviewing module version bumps in PRs and reading the module changelog before upgrading.
6. **Nested modules** — note that a pinned module may itself pull unpinned children; audit transitive sources.

Output as: (a) a per-module source + pin recommendation, (b) supply-chain risk notes, (c) an upgrade-review workflow.

A module `source` pointing at a moving Git branch means your infra can change without a code change — always pin to an immutable tag or commit.