Terraform Provider OpenRouter: From First Commit to Verified v0.2.10

Created: May 5, 2026 Updated: May 5, 2026

Introduction

Some engineering stories are about new features. Others are about turning an idea into something teams can actually trust in production.

This is the second kind.

The terraform-provider-openrouter journey started on April 27, 2026 as a new Terraform/OpenTofu provider for the OpenRouter management API. It ended this phase on May 5, 2026 with a fully published v0.2.10 release, a repaired CI/release path, live Terraform acceptance evidence, OpenTofu smoke verification, and a clearer public contract for downstream users.

What makes the story interesting is not just the final version number. It is the path between the first scaffolding commit and the point where the provider was truly release-ready.

That path included:

• the initial provider implementation
• alignment with the shared CloudOpsWorks Go blueprint
• documentation and release automation work
• an interview-driven requirements lock for v1
• a failed semantic evaluation
• a focused repair loop for provider correctness
• live acceptance and OpenTofu verification
• CI and release-pipeline fixes
• the final merge and public release

This article reconstructs that evolution from the repository history, stored engineering artifacts, validation notes, and the execution trail preserved in the workspace.

What the provider was built to do

At its core, the provider exposes OpenRouter management-plane objects to Terraform and OpenTofu.

By the time the current release line stabilized, the provider supported these resources:

• openrouter_api_key
• openrouter_workspace
• openrouter_guardrail

And these data sources:

• openrouter_workspace
• openrouter_api_keys
• openrouter_workspaces
• openrouter_guardrails
• openrouter_organization
• openrouter_providers

The provider configuration stayed intentionally small:

• api_key
• OPENROUTER_API_KEY environment fallback
• optional base_url

That simplicity became important later, because one of the main goals of the repair phase was to preserve the provider contract while improving correctness, verification, and release quality.

The inception: April 27, 2026

The repository began with the initial commit on April 27, 2026.

The next meaningful milestone came quickly when the repository adopted the shared CloudOpsWorks Go blueprint without sacrificing Terraform provider release behavior.

That change mattered because it did two things at once:

1. it aligned the repository with the shared CloudOpsWorks Go blueprint and its operational model
2. it avoided flattening the provider into a generic application repository

That distinction is easy to miss, but it is critical for provider engineering. A Terraform provider has to fit into broader repository automation, while still honoring registry packaging, provider docs, and release conventions that are specific to provider ecosystems.

From there, the repository rapidly accumulated the operational pieces a provider needs in public:

• README and docs expansion
• release automation
• GitVersion configuration
• GoReleaser iterations
• packaging and checksum/signing adjustments
• Makefile tasks
• examples

By the end of April 27, the repository already looked much more like a public provider project than a prototype.

The first feature wave: resources, data sources, and provider shape

The initial implementation phase did not stop at scaffolding.

Commit history shows the provider’s core surfaces arriving quickly:

• API key resource support
• workspace resource support
• guardrail resource support
• organization and providers data sources
• workspaces and API keys data sources
• generated docs and examples

Then, on April 28, the single-workspace data source was added, closing an obvious usability gap in the data model.

At that point, the repository already had the basic shape of a usable provider. It could manage meaningful OpenRouter objects, it had examples, and it was moving through release automation iterations fast enough to reach the public v0.2.x line.

But “usable” and “production-ready” are not the same thing.

That difference became the real story of the next phase.

What was still missing

The provider had working code and release momentum, but it still had hidden quality debt.

That debt was not primarily about missing features. It was about the difference between:

• a provider that appears complete
• and a provider that behaves correctly under import, drift, pagination, and repeated apply/plan cycles

When the work was later evaluated against a stricter v1 quality bar, several gaps surfaced:

• inconsistent import semantics across resources
• missing pagination for some list operations
• API-field fidelity gaps between code and the OpenRouter API
• docs/tooling metadata drift
• lack of real acceptance-test evidence

In other words: the provider could already do useful work, but it had not yet proven that it behaved like a dependable Terraform/OpenTofu provider under the conditions real operators care about.

That is where the structured engineering loop began.

The requirements lock: interview, specification, and evaluation

On April 27, the work moved into a structured interview and specification phase. Instead of continuing with assumptions, the team used an AI-assisted requirements workflow to turn a general product idea into an explicit v1 contract.

The scope was deliberately bounded to:

• api_keys
• workspaces
• guardrails
• organization
• providers

It also locked the behavioral expectations:

• CRUD where supported
• import behavior
• state reconciliation
• documentation and examples
• compatibility with Terraform 1.7.x and OpenTofu 1.7.x

The important shift here was that the provider was no longer judged by intuition or “looks fine locally.” It was now being judged against a written specification with explicit acceptance criteria.

When that evaluation ran, the result was a rejection on semantic grounds. The evaluation passed mechanical checks, but failed the deeper compliance bar with a semantic score of 0.46.

That was the turning point.

The project no longer needed more surface area. It needed a focused correctness pass.

The repair phase: a bounded AI execution loop with plans and evidence

The next stage was not an open-ended rewrite. It was a bounded repair loop with explicit planning artifacts stored in the repository, including a product requirements document and a dedicated test specification.

Those artifacts narrowed the task:

• reconcile import semantics
• add missing pagination
• fix API-fidelity and field-modeling gaps
• correct docs/tooling metadata
• add the verification evidence needed to back the claims

The corresponding context notes captured exactly what was known and what still had to be repaired.

This was a good example of disciplined AI-assisted engineering. The loop did not simply “keep coding.” It first turned the problem into an explicit PRD, a test specification, and a scoped execution lane, then used that material to guide implementation and verification.

The biggest code and behavior fixes

The single biggest repair phase in this story was the verification and API-semantics hardening pass, which touched 26 files and materially changed the provider’s quality bar.

The most important improvements included:

1. Real acceptance coverage

The provider gained actual HashiCorp-style acceptance tests for:

• API key resource
• workspace resource
• guardrail resource
• core data sources

That change alone moved the repository from “unit-tested implementation” toward “provider-tested behavior.”

2. Pagination fixes

The client implementation was corrected so API key and workspace listing behavior no longer stopped at the first page.

That matters because pagination bugs often hide until real organizations have enough objects to cross a page boundary. Once they do, imports, drift detection, and data source behavior become unreliable.

3. Import and reconciliation fixes

The repair loop clarified and tested import behavior, while also improving how resources refreshed and reconciled state after changes.

This included fixing API key refresh behavior after update and reducing unintended replacement behavior caused by incorrect attribute modeling.

4. API-fidelity improvements

The provider moved closer to the actual OpenRouter API contract, including:

• current-key validation fixes
• workspace and guardrail field modeling improvements
• providers data source fidelity updates
• omission of unset optional guardrail fields instead of emitting JSON null

5. Docs and tooling corrections

One of the clearest polish bugs was that docs tooling still referenced hashicups in tools/tools.go.

That was corrected so the generated docs and provider tooling aligned with the actual provider identity.

The proof phase: Terraform and OpenTofu verification

The provider’s validation evidence was preserved in project artifacts. That evidence matters because it turns “we think it works” into “we ran the right proof.”

Mechanical verification

• make test ✅
• make build ✅

Terraform acceptance evidence

The provider was validated with Terraform v1.7.5 using live acceptance tests.

The acceptance suite passed for:

• TestAccAPIKeyResource_basic
• TestAccDataSources_basic
• TestAccGuardrailResource_basic
• TestAccWorkspaceResource_basic

That acceptance path covered:

• CRUD behavior where applicable
• import verification
• drift reconciliation
• empty-plan/no-op validation
• read behavior for the supported data sources

OpenTofu compatibility evidence

The provider was also smoke-tested with OpenTofu v1.7.7 using a local dev override workflow:

1. tofu init
2. tofu apply with managed resources
3. tofu apply after adding data sources
4. tofu destroy

That passed as well.

This combination mattered because the v1 requirement was not just “works with Terraform,” but “works credibly across Terraform and OpenTofu in the supported compatibility band.”

The last mile: CI and release plumbing

Even after the provider behavior was fixed, the release path itself still had friction.

A key CI failure surfaced in the CloudOpsWorks build lane:

• go: no such tool "covdata"

That failure was not a provider-feature bug. It was a build/toolchain mismatch. Fixing the provider without fixing the CI surface would still have left the release story incomplete.

The final sequence of changes addressed that last-mile plumbing:

• align global configuration with the current Go toolchain
• restore repository identity and correct semantic-version bump mapping
• add the missing production environment inputs expected by CloudOpsWorks CI
• update review and ownership configuration in the CloudOpsWorks repository policy

These changes removed noisy configuration warnings, fixed release-path expectations, and got the PR build back into a state where the actual provider work could pass cleanly.

By the end of that sequence:

• PR builds were green
• the missing inputs-prod warning was gone
• the remaining annotation was only an upstream Node 20 deprecation warning in a GitHub Action dependency

The merge and the release

The final merge happened through the repository’s standard pull-request flow.

That PR merged into master on May 5, 2026.

After the merge, the repository completed its release flow and published:

• v0.2.10
  Released on May 5, 2026 at 19:15:46 UTC

That matters because it is the point where the story becomes externally real.

The provider was no longer:

• just a branch
• just a passing local validation
• or just a repaired CI lane

It was a public released artifact with a documented provider contract, verified behavior, and a reproducible change history.

What this story says about AI-assisted platform engineering

This was not a story of AI replacing engineering judgment.

It was a story of AI operating inside a disciplined engineering system:

• requirements were clarified through interview artifacts
• acceptance criteria were locked in a Seed
• evaluation rejected vague confidence
• a scoped PRD and test spec directed the repair loop
• validation evidence was recorded
• CI and release systems remained the source of truth

That is the useful pattern.

Humans decided:

• the scope
• the release intent
• the quality bar
• and what counted as “done”

The AI-assisted loop handled:

• repository inspection
• multi-step diagnosis
• targeted repairs
• acceptance-test scaffolding
• CI interpretation
• release-path cleanup

Used that way, AI is not a gimmick. It becomes a force multiplier for correctness work that would otherwise be slower, easier to lose track of, or more likely to stop at the “almost done” stage.

In practical terms, the workflow used here combined:

• OpenAI Codex for code reasoning, editing, and verification
• oh-my-codex (OMX) as the orchestration layer for structured execution
• an interview-style clarification loop to lock requirements before deeper changes
• a plan-and-test-spec stage to define the repair lane
• a persistent execution-and-verification loop to keep iterating until the evidence was strong enough

That matters because the value did not come from “AI wrote some code.” The value came from using AI inside a structured engineering workflow:

1. clarify the goal
2. narrow the scope
3. gather evidence
4. change the implementation
5. verify against real tooling
6. fix the release path
7. publish the result

That is a much stronger model than ad hoc prompting, because it keeps the work anchored in artifacts, tests, and release outcomes.

The timeline in one view

Why this matters for teams evaluating Cloud Ops Works

There is a practical reason to tell this story in public.

Most organizations do not struggle because they lack ideas. They struggle because turning an idea into a released, supportable, verifiable asset takes sustained engineering discipline. That is especially true for infrastructure products, internal platforms, Terraform modules, and providers, where the hard part is rarely the very first implementation. The hard part is getting all the way to something that downstream teams can trust.

That is the value this journey demonstrates.

It shows that Cloud Ops Works can take a project from:

• initial scaffolding
• through standards alignment
• through validation design
• through behavior repair
• through CI and release hardening
• and finally into a public, versioned, consumable release

For engineering leaders, that means less ambiguity around delivery maturity.

For platform teams, it means faster movement from “we have code” to “we have something we can safely adopt.”

For organizations exploring AI-assisted delivery, it is also an example of the model we believe in: AI should not bypass engineering rigor. It should help teams apply that rigor more consistently, more quickly, and with better traceability.

That combination of human judgment, explicit validation, and AI-assisted execution is increasingly what separates prototypes from reliable platform products.

So while this article is about terraform-provider-openrouter, the bigger message is broader: if your team needs to turn infrastructure automation ideas into released, documented, verifiable assets, that is exactly the kind of outcome Cloud Ops Works is built to help deliver.