The sync-providers-yaml gate was failing because the template's providers.yaml had drifted ~400 lines behind controlplane canonical (a629230d). Copy the canonical file verbatim, then regenerate registry-projection.json via registry_projection.py. This preserves the PR's intent (removes stale moonshot:/minimax: colon BYOK forms from claude-code) because controlplane canonical already has those removals. Also passes all 6 registry projection tests including the new moonshot/minimax exclusion tests. Fixes CI: sync-providers-yaml / Compare synced providers.yaml
Federated provider registry (informational)
This directory contains a synced copy of the canonical Molecule AI federated provider registry and the registry's projection of this template's runtime view.
What's here
| File | Role |
|---|---|
providers.yaml |
A SYNCED copy of the canonical registry from molecule-controlplane/internal/providers/providers.yaml. Kept in sync by .gitea/workflows/sync-providers-yaml.yml. Do not hand-edit — re-sync from controlplane main. |
registry-projection.json |
The registry's view of THIS template's runtime — the (provider, model) pairs the registry says are first-class for this runtime. Auto-generated by registry_projection.py generate <runtime>. Do not hand-edit. |
registry_projection.py |
Generator + drift gate + subset gate for the projection artifact. |
README.md |
This file. |
What's authoritative
The template's config.yaml is authoritative. Its providers: block
(or runtime_config.models[] / top-level models[], depending on
template shape) is the operational source of truth for which providers
and models this template actually exposes at runtime. Nothing in
internal/providers/ changes runtime behavior.
The registry is informational only. It documents which (provider, model) pairs the platform's federated catalog claims are first-class for this runtime — typically a strict subset of what the template's hand-authored block ships (e.g. the platform's billing catalog vs. the template's full BYOK matrix).
CI contract
.gitea/workflows/verify-providers-projection.yml enforces two invariants:
- Artifact drift:
registry-projection.jsonis byte-identical to whatregistry_projection.py generate <runtime>produces from the syncedproviders.yaml. - Subset relation: every
(provider, model)pair inregistry-projection.jsonis servable by the template's hand-authored authoritative source. The hand-authored block stays authoritative; this gate only stops the registry from over-claiming (e.g. "the registry says runtime R can serve model M via provider P, but the template doesn't list M under P"). On a violation, the resolution is either:- add
Mto the template's authoritative source underP, or - retire the
(P, M)pair from the canonical registry (molecule-controlplane/internal/providers/providers.yamlruntimes:block).
- add
If this template's runtime is not registered in the canonical registry,
the subset gate fails open — the federation contract is that
non-first-party runtimes ship without registry coverage. The artifact
will be a {"in_registry": false} marker.
.gitea/workflows/sync-providers-yaml.yml keeps the local
providers.yaml in sync with controlplane's canonical copy.
Why Path B
The brief originally called for full registry-driven codegen of the
template's providers: block (RFC#580 Option C). The build agent's
falsification (issue-comment 52157) surfaced that the registry's
per-runtime view is a strict subset of the templates' shipping
providers: blocks — byte-identical codegen was unsatisfiable without
first growing the registry data. Path B drops the byte-identical
constraint, requires only the subset relation, and preserves the
federation contract the CTO locked: templates' hand-authored vocab stays
authoritative, registry over-claim is the only failure mode the gate
catches.