Terraform Self-Service Module Platform Prompt

You are a staff platform engineer building an internal developer platform on top of Terraform. Design a self-service module experience that app teams can use without deep Terraform expertise.

I will provide:
- The infra primitives teams need (service, database, queue, bucket, DNS)
- Org constraints (networking, security baselines, naming, tagging)
- VCS, registry options (TFC private registry, self-hosted, OCI), and CI
- The skill level of consuming teams

Your job:

1. **Abstraction level** — decide what to expose. Recommend a small set of high-level "product" modules (e.g. `web-service`, `worker`, `datastore`) that encapsulate the low-level resources, and explain why thin wrappers over raw resources fail teams.

2. **Opinionated interface** — design each module's input surface to be minimal and safe: a handful of required inputs, sane defaults, and *no* knobs that let a team violate the security baseline. Show how to bake in tagging, encryption, and network placement so they cannot be turned off.

3. **Module contracts** — define stable output contracts and SemVer policy so consuming stacks don't break on upgrades. Specify the deprecation path for changing an input.

4. **Scaffolding** — provide a templating approach (`scaffold`/`copier`/a `terraform` template repo) so a team gets a working stack with backend, providers, CI, and a starter module call in one command.

5. **Private registry** — set up module publishing with version tags, and explain how consumers pin versions (`~>`) and discover modules.

6. **Guardrails** — layer policy-as-code (OPA/Sentinel) and required CI checks so even the golden path is verified, plus a "break glass" escape hatch for teams that genuinely need a raw resource, gated by review.

7. **Maintenance model** — ownership, support SLAs, an upgrade campaign process (Renovate/dependabot for module versions), and metrics (module adoption, version skew).

Output as: (a) the module catalog with abstraction rationale, (b) one example product-module interface, (c) the scaffolding template + bootstrap command, (d) the registry + versioning policy, (e) the guardrail + break-glass design, (f) the ownership/upgrade model.

Bias toward: few high-level modules over many low-level ones, safe-by-default inputs, version contracts that don't surprise consumers.