iac.provider gap: plugin declares moduleTypes but doesn't register IaCProvider impl

[intel352]

Summary

`workflow-plugin-eventbus` v0.1.0 declares `moduleTypes` for `infra.eventbus`, `infra.eventbus.stream`, and `infra.eventbus.consumer` in plugin.json, but does not register itself as an `iac.provider` (no `IaCProvider` impl in the codebase). Without an iac.provider, wfctl's plan dispatch has nowhere to route eventbus resources, so apply fails.

Reproduction

BMW pilot integration. infra.yaml declares:

```yaml

• name: bmw-eventbus
  type: infra.eventbus
  config:
  provider: nats
  deploy_target: digitalocean.app_platform
  ...

• name: bmw-stream
  type: infra.eventbus.stream
  config:
  name: BMW_FULFILLMENT
  subjects: ["bmw.>"]
  ...

6 × infra.eventbus.consumer resources

```

`wfctl infra apply` fails at plan-grouping with:

```
error: plan action for "bmw-eventbus" references provider "nats"
which is not declared as an iac.provider module
```

GoCodeAlone/workflow#620 fixes the plan-grouping bit by introducing an `iac_provider` field that disambiguates IaC routing from impl-level `provider` ("nats"/"kafka"). After PR 620 lands, BMW can declare `iac_provider: do-provider` on each eventbus resource.

But that just shifts the failure: `workflow-plugin-digitalocean` v0.14.3 has no driver for `infra.eventbus` / `infra.eventbus.stream` / `infra.eventbus.consumer` (its driver list: container_service, k8s_cluster, database, cache, load_balancer, vpc, firewall, dns, storage, registry, certificate, droplet, volume, iam_role, api_gateway). Apply will fail with "no driver for resource type infra.eventbus".

What's missing

`workflow-plugin-eventbus` declares modules but no `IaCProvider` interface impl that owns the lifecycle of those modules. Two architectural paths:

Path A: eventbus plugin registers as iac.provider

Plugin declares an `iac.provider` capability + IaCProvider impl. Operators put a separate `type: iac.provider, provider: eventbus` module in their config. Each eventbus resource sets `iac_provider: `.

The eventbus IaCProvider's drivers:

• `infra.eventbus` driver: provisions the broker (delegates to deploy_target plugin — DO App Platform via a sub-RPC, or via a DeployTarget abstraction that the plugin already has internally per the v0.1.0 design)
• `infra.eventbus.stream` + `infra.eventbus.consumer` drivers: NATS API calls against the live broker

This decouples the eventbus's IaC integration from any specific cloud provider — the plugin owns its lifecycle, deploy_target is a configurable backend.

Path B: cloud iac.provider plugins gain eventbus drivers via delegation

`workflow-plugin-digitalocean` (and AWS/GCP/Azure equivalents) gain drivers for `infra.eventbus.*` that delegate to the eventbus plugin via a sub-plugin pattern. Operators set `iac_provider: do-provider` and the DO plugin handles broker provisioning + delegates stream/consumer ops to a local eventbus-plugin RPC.

This keeps the wfctl plan dispatch model unchanged but puts the responsibility on every cloud iac.provider plugin to know about eventbus. Doesn't scale.

Recommendation

Path A. The eventbus plugin already has a `Provider` abstraction (NATS/Kafka/Kinesis) and a `DeployTarget` matrix (DO App Platform / k8s / aws / self-hosted) per the v0.1.0 design — those primitives are exactly what an IaCProvider needs.

Blast radius

Currently blocks BMW pilot deploys from reaching prod. The user's deploy chain (run 25625555953 attempts 1-2):

1. F2 alignment failed on InvalidAccessKeyId — fixed by SPACES rotation (rotate-spaces-credentials.yml in BMW)
2. Plan-grouping failed on "provider 'nats' not declared" — fixed by fix(wfctl): disambiguate iac_provider from impl-level provider in resource configs workflow#620 (iac_provider/provider disambiguation)
3. Apply will fail on "no driver for infra.eventbus" — this issue

Related

• fix(wfctl): disambiguate iac_provider from impl-level provider in resource configs workflow#620 (iac_provider/provider disambiguation; merged ⇒ v0.27.8)
• feat(wfctl): typed-IaC cutover — replace remoteIaCProvider with pb.IaCProviderRequiredClient (PR 4 / Task 16) workflow#609 (typed-IaC strict-cutover; v0.27.7)
• GoCodeAlone/buymywishlist#266 (BMW pin bump v0.27.6)
• BMW infra.yaml lines 342-450 (bmw-eventbus + bmw-stream + 6 bmw-consumer-*)

🤖 Filed by Claude Code on behalf of the BMW deploy debug chain

[intel352]

Design analysis (2026-05-11)

After staring at this longer in the context of the BMW deploy chain, the architectural gap is sharper than the original issue text described:

The eventbus plugin's design — `providers/Provider.Resources()` emits typed `[]iac.Resource` whose `Kind` field names lower-level cloud-native types (`infra.app`, `infra.aws.kinesis_stream`, etc.) — was explicitly meant to be consumed by downstream IaC plugins. The plugin is a transformer, not a realizer.

But wfctl's plan-action dispatch operates on the resource types declared in infra.yaml (BMW's `type: infra.eventbus.*`), not on the transformed output. Result: no path from BMW's `infra.eventbus` declaration to actual DO App Platform provisioning. Three possible designs:

Option A — eventbus plugin becomes a self-contained IaCProvider

Plugin grows `IaCProvider` registration + `ResourceDriver` impls for `infra.eventbus*`. Drivers internally call:

• Provider-aware deploy logic from `providers/nats/deploy_digitalocean_app.go` (already written)
• godo (or the relevant cloud SDK) directly to actually create the App Platform service

Cost: eventbus plugin grows a cloud-SDK dependency tree. Duplicates the DO plugin's App Platform driver. Same for AWS/k8s targets — each becomes a duplicated impl inside the plugin.

Option B — DO plugin gains `infra.eventbus*` drivers via library import

DO plugin imports `workflow-plugin-eventbus` as a Go module, registers drivers for `infra.eventbus*` that delegate to the eventbus plugin's `Provider.Resources()` and then directly realize against godo. AWS/GCP/Azure plugins mirror.

Cost: every cloud IaC plugin now depends on the eventbus plugin module. Coupling inversion (downstream depends on upstream). Tested coverage explodes 4× (per cloud provider).

Option C — wfctl supports plugin-driven plan transformation (recommended)

wfctl gains a "resource transformer" hook before plan-action dispatch. Plugins register transformations for their declared `moduleTypes`. The eventbus plugin registers transformations for `infra.eventbus*` that expand each abstract resource into the underlying `infra.app` / `infra.volume` / etc. The plan engine then dispatches the expanded set to the appropriate `iac.provider` (DO plugin handles `infra.app`, etc.).

Cost: new wfctl primitive (resource transformer). Requires upstream design + impl in workflow repo. But it's the architecturally honest answer for a transformer-plugin model — and unlocks the same pattern for any future composite resource type (e.g. `infra.observability_stack` → app + database + dashboard).

Recommendation

Option C. The eventbus plugin's existing design intent (transformer, not realizer) maps cleanly onto a wfctl-side transformer hook. Options A/B encode the realizer responsibility into the plugin's wrong layer.

If C is too much for the immediate horizon: Option A is the smaller delta because the eventbus plugin already has DO App Platform deploy logic written. Add 3 ResourceDriver impls in eventbus plugin + register as iac.provider. Future cloud targets (AWS/GCP/k8s) get duplicated drivers until C lands as a refactor.

Status

Filing this for maintainer review. BMW deploy chain currently parks at this gap (deploy run 25643925319 apply step: "unsupported resource type \"infra.eventbus\"" × 8 resources). All upstream blockers EXCEPT this one have shipped fixes today:

• workflow-plugin-digitalocean#91 → closed by v1.0.0 (typed-IaC service registration)
• workflow#622 → closed by #623 v0.51.0 (InvokeService cutover)
• workflow#628 → closed by #627 v0.51.2 (GetManifest tolerance)
• BMW pin chain (PRs #267→#273) all merged

🤖 Filed by Claude Code on behalf of BMW deploy chain analysis