Skip to content

Registry compatibility must distinguish legacy host-load from typed-IaC conformance #634

@intel352

Description

@intel352

Problem

IaC plugin repos now have multiple compatibility signals:

  • legacy host-load smoke: proves an old sdk.Serve module plugin can load and expose metadata/contracts
  • typed-IaC conformance: proves a provider serves sdk.ServeIaCPlugin and registers pb.IaCProviderRequiredServer/optional typed services
  • manifest validation: proves plugin.json/plugin.contracts.json shape only

These are not interchangeable. A plugin can pass legacy host-load and still fail wfctl plugin conformance --mode typed-iac with:

error: iac: plugin uses legacy InvokeService dispatch removed in workflow v1.0.0

Required behavior

  • wfctl registry/install compatibility for manifests advertising IaC provider capability must require typed-IaC conformance evidence once the registry source declares first-party/enforced compatibility.
  • Legacy host-load evidence must be named and treated as advisory/legacy only; it must not satisfy typed-IaC registry readiness.
  • Manifest iacProvider metadata must not be accepted as a sufficient runtime proof.
  • Artifact/executable discovery must verify the selected binary completes the Workflow go-plugin handshake and typed service registration before accepting any IaC evidence.

Security invariant

Conformance smoke must be metadata-only: no cloud mutation, no provider credentials, no secret/env dump, no resource Read/Plan/Apply/Destroy/bootstrap/credential RPCs.

Related

Metadata

Metadata

Labels

architectureArchitectural design and coupling issues

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions