Context
Contrib adapters and integrations are maintained outside the stable core API promise. Supported-adapter status should be useful to adopters without implying root-module stability.
Review paths
- ROADMAP.md
- docs/contrib-adapters.md
- docs/adapter-maturity.md
- docs/package-classification.tsv
- docs/supported-adapter-contracts.tsv
- docs/supported-adapter-test-realism.tsv
- VERSIONING.md
Questions
- Are supported-adapter, experimental, wrapper-only, generated, and tooling tiers clear enough?
- What evidence should be required before promoting an adapter to supported-adapter?
- Is the contrib drift policy strong enough without overstating compatibility guarantees?
- Which contrib adapters need clearer production caveats or external-service realism evidence?
Desired outcome
A recommendation for contrib support policy, including any tier wording, evidence, or release-review changes needed before broader adoption.
Context
Contrib adapters and integrations are maintained outside the stable core API promise. Supported-adapter status should be useful to adopters without implying root-module stability.
Review paths
Questions
Desired outcome
A recommendation for contrib support policy, including any tier wording, evidence, or release-review changes needed before broader adoption.