Cannot manage the workspace default guardrail (lazy-materialized, read-only id)

[wtait1-ff]

Problem

Every workspace has a default guardrail that applies to all keys/members without explicit assignment — ideal for "batteries-included" org protections defined in Terraform. The underlying API fully supports managing it, but the provider offers no path to do so:

• openrouter_workspace.default_guardrail_id is read-only, so it can't be set.
• The default guardrail is lazily materialized: until its config is first written, GET /guardrails/{default_guardrail_id} returns 404 and the guardrail is absent from the openrouter_guardrails data source (total_count: 0). So there's nothing to reference or import.
• The provider's only guardrail write is openrouter_guardrail → POST /guardrails, which mints a new random guardrail, not the workspace default. terraform import of the default id fails (Cannot import non-existent remote object) because the provider's Read hits the 404.

The result is a chicken-and-egg: you can't configure the default because it isn't materialized, and the provider has no write that materializes it.

What we verified against the API (v1, management key)

On a fresh throwaway workspace (deterministic default_guardrail_id = 61faa452-…):

Step	Call	Result
before	GET /guardrails/{default_guardrail_id}	404
before	GET /guardrails?workspace_id=…	total_count: 0 — no Default row
write	PATCH /guardrails/{default_guardrail_id} {"limit_usd":5,"reset_interval":"monthly"}	200 — returns fully-formed Workspace <id> Default guardrail
after	GET /guardrails/{default_guardrail_id}	200
after	GET /guardrails?workspace_id=…	total_count: 1, the Default row

So PATCH /guardrails/{default_guardrail_id} is the materialize-and-configure path, and it works even before materialization — targeting exactly the id the provider already exposes on the workspace resource.

Expected vs actual

• Expected: a way to manage the workspace default guardrail settings via Terraform (mapping onto the existing PATCH /guardrails/{default_guardrail_id}).
• Actual: no writable surface; default_guardrail_id is read-only and un-importable while unmaterialized.

Workaround

We're papering over this out-of-band with a null_resource + local-exec provisioner that PATCHes the default guardrail id directly against the REST API.

Environment

provider OpenRouterTeam/openrouter v0.2.6 · macOS 26.5.2 (darwin_arm64)