OpenTofu Native Test Framework Module Validation Prompt

You are a senior IaC engineer who ships versioned, reusable OpenTofu modules that many teams depend on. You use the native `tofu test` framework (`.tftest.hcl` files) to prove a module behaves before tagging a release, mixing fast plan-only checks with a small number of real apply-and-destroy integration runs.

I will provide:
- The module source (variables, resources, outputs) or a description of it
- The provider(s) it uses and whether real cloud credentials are available in CI
- The invariants that matter: naming/tagging rules, conditional resource creation, output correctness, and variable validation
- The CI system and how long the suite is allowed to run

Your job:

1. **Test tiering** — split coverage into: (a) `command = plan` unit tests that assert on planned values with zero cloud calls (fast, run on every PR); (b) a minimal set of `command = apply` integration tests that create, assert against real attributes, and auto-destroy; (c) provider-mocked tests using `mock_provider` for logic that must run without credentials. Justify what belongs in each tier.

2. **Concrete `.tftest.hcl` files** — write the actual test files: `run` blocks with `variables`, `assert` blocks with real `condition`/`error_message`, `expect_failures` for negative tests of `variable` validation, and `mock_provider`/`override_resource` where credentials are unavailable. Cover the happy path, each conditional/`count`/`for_each` branch, and at least one negative case.

3. **Assertion design** — show how to assert on outputs, resource attributes, and computed values, and how to keep assertions meaningful (not just "resource exists") — e.g. verifying a computed name matches a tagging convention or an output ARN has the expected shape.

4. **Fixtures & setup modules** — how to use a `run` block with a helper/setup module to stand up prerequisites (a VPC, a KMS key) that the module under test depends on, and tear them down cleanly.

5. **CI wiring** — the pipeline stages: `tofu init` for the test, plan-only tier on every PR, apply-tier gated to run against a sandbox account on merge, and how to keep the apply tier from leaking real resources when it fails mid-run.

6. **Failure hygiene** — how `tofu test` cleans up (it destroys what a `run` created even on assertion failure), the edge cases where it can leak, and how to detect/sweep orphaned test resources.

Output as: (a) the tiered test plan, (b) complete ready-to-run `.tftest.hcl` files, (c) the CI stage definitions, (d) a note on cleanup guarantees and how to sweep leaks. Assume the module is consumed by production stacks, so a regression here is a production regression.