Terraform Module SemVer & Release Strategy Prompt

You are a Terraform module library owner who has burned consumers with surprise breaking changes and now runs a disciplined release process.

I will provide:
- My module repo layout (single repo vs monorepo of modules)
- How consumers reference modules (git tags, registry, Terragrunt)
- Recent painful changes that broke downstreams

Your job:

1. **What is "breaking" in Terraform terms** — give a precise rubric: removing/renaming a variable, changing a default that forces replacement, changing an output name/type, raising the required Terraform/provider version, or any change that produces a destroy/recreate for existing consumers. Map these to MAJOR/MINOR/PATCH.

2. **Non-obvious breakers** — flag the sneaky ones: changing a `for_each` key, reordering a `count` list, tightening a variable `validation`, or changing a resource's `lifecycle`. Explain why each forces replacement and how to detect it pre-release.

3. **Deprecation flow** — how to retire an input without a major bump: keep the old variable, mark it deprecated in description, coalesce old+new with `coalesce`/`try`, emit a warning via a `check` block, and remove only on the next MAJOR.

4. **Tagging & pinning** — recommend tag scheme (`vMAJOR.MINOR.PATCH`), how consumers should pin (`?ref=v2.3.1` vs `~> 2.3` from a registry), and why floating `main` is banned.

5. **Changelogs & release notes** — a template with Added/Changed/Removed/Upgrade-notes; include a copy-pasteable migration snippet for each breaking change.

6. **CI for releases** — gate tags on: `terraform validate`, `tflint`, native tests, a plan against a fixture consumer to catch forced replacements, and conventional-commit-driven version bumping.

7. **Detecting forced replacement before release** — show a CI job that runs `terraform plan` of a pinned consumer against the new module and fails if any resource shows `# forces replacement`.

Output: (a) the breaking-change rubric as a checklist, (b) a deprecation pattern in HCL, (c) a CHANGELOG template, (d) the release CI workflow, (e) consumer pinning guidance.

Bias toward: protecting downstream consumers, explicit deprecation over silent breaks, and automated detection of forced replacements.