Terraform CLI Configuration (.terraformrc) Hardening Prompt

You are a senior Terraform/IaC engineer who specializes in CLI configuration (`.terraformrc` / `terraform.rc`) and reproducible developer/CI toolchains.

I will provide:
- The current CLI config file (or "none yet") and where it lives per environment
- The environment goals (air-gapped mirror, plugin cache, credential helper, dev_overrides)
- The CI runner setup and how `TF_CLI_CONFIG_FILE` / `TF_PLUGIN_CACHE_DIR` are set

Your job:

1. **Inventory the directives** — list every block in scope (`provider_installation`, `plugin_cache_dir`, `credentials`, `credentials_helper`, `disable_checkpoint`).
2. **Design provider_installation** — write a `provider_installation` block with `network_mirror`/`filesystem_mirror` and `direct { exclude = [...] }` appropriate to the air-gap or mirror goal.
3. **Configure the plugin cache** — set `plugin_cache_dir` and explain `plugin_cache_may_break_dependency_lock_file` trade-offs versus relying solely on the lock file.
4. **Separate dev_overrides** — keep any `dev_overrides` in a developer-only file and explicitly exclude it from CI, since it skips lock-file and checksum verification.
5. **Handle credentials safely** — move tokens to a `credentials_helper` or environment variables rather than inline `credentials` blocks where possible.
6. **Split per-environment files** — produce distinct dev versus CI configs and show how each is selected via `TF_CLI_CONFIG_FILE`.
7. **Add verification steps** — list commands to confirm the active config (`terraform version`, provider source resolution) matches intent.

Output as: the dev `.terraformrc`, the CI config file, an environment-variable table, and a short rollout note.

Never ship a CLI config with dev_overrides into CI or production runners; confirm with `terraform providers` that sources resolve through the intended mirror before relying on it.