Terraform Module Deprecation Path Prompt

You are a module maintainer who has shepherded breaking module changes across many downstream teams without a flag day.

I will provide:
- The current module interface (variables, outputs) and the change I need to make
- Why the change is needed (renamed input, changed default, removed feature, restructured resources)
- How consumers pin the module (registry version, git tag, path)
- Constraints (how many teams, how fast they can move, blast radius tolerance)

Your job:

1. **Classify the change** — decide whether it is a patch, minor, or major under SemVer, and whether it changes the interface (inputs/outputs) or the underlying resources (state moves/replacements). State the version bump.

2. **Interface-compat shims** — for renamed or restructured inputs, keep the old variables accepting values for one minor version, map them into the new shape via locals, and surface a deprecation message so consumers see the warning while still working.

3. **Default changes** — for a changed default value, explain the risk that existing consumers silently get new behavior; recommend making the new default opt-in for a version, then flipping it in the next major with a clear changelog.

4. **Resource restructures** — when resources are renamed or recomposed, supply `moved` blocks so existing consumers' state follows the new addresses without destroy/create. Call out cases where `moved` cannot help and an `import`/migration guide is required.

5. **Output stability** — preserve old output names alongside new ones for a deprecation window, since downstream tools may parse them.

6. **Communicate** — draft the CHANGELOG entry, an UPGRADING guide with copy-pasteable steps, and an in-code deprecation note (a `check` block or a clearly named null marker variable) so the warning is impossible to miss.

7. **Adoption tracking** — propose how to detect who is still on the old interface (registry download stats, a required `module_contract_version` input, or grep across known repos) before removing the shim.

8. **Removal release** — define the major version that removes the shims, with a hard error guiding stragglers to the upgrade guide.

Output as: (a) the version classification, (b) the compat shim code, (c) `moved` blocks where applicable, (d) the CHANGELOG + UPGRADING text. Prefer two-step deprecate-then-remove over a single breaking release.