Problem Statement
Why
OpenShell is growing beyond Python and TypeScript SDKs. The Go SDK is the first new language contribution (#2044, decomposition tracked in #2270), and there are no formal acceptance criteria for what a language SDK must deliver to be considered conforming.
RFC-0008 (#1764) defines the SDK architecture (binding strategies, shared core, SDK contract), but there's no operational framework for evaluating whether a specific SDK meets the bar. This creates friction for both contributors ("what does my PR need to include?") and reviewers ("what checklist do I evaluate against?").
This was discussed in the contributor meeting on 2026-07-14 as a follow-up to the Go SDK PR decomposition.
What
An RFC proposing:
Three API conformance tiers, each building on the previous:
- Core: sandbox CRUD, exec, file transfer, health, typed errors
- Extended: providers, profiles, config, credential refresh, services, policy
- Full: SSH tunneling, TCP forwarding, edge client, interactive exec, watch primitives
Three auth levels (independent axis):
- L1: static token, no-auth
- L2: L1 + refreshable tokens, custom AuthProvider
- L3: L2 + OIDC discovery, device-code flow, auth-code flow
Operational requirements (applies to all tiers):
- Linting (language-appropriate, project-standard config)
- Testing (unit tests, integration tests behind build tags)
- Proto sync (freshness checks in CI)
- CI job (build, lint, test, vet on every PR)
Scorecard format: a standard conformance matrix for each SDK's README showing which tiers and auth levels it implements.
Deliverable
The RFC is the proposal and rationale. The primary output is a scorecard document (e.g., sdk/CONFORMANCE.md) that serves as the living acceptance checklist for current and future language SDKs.
Proposed Design
Single RFC document covering conformance tiers, auth levels, CI/quality requirements, and the scorecard format. References RFC-0008 for architecture decisions.
Alternatives Considered
- Split into two RFCs (conformance tiers vs CI gates): rejected because the tiers and CI requirements naturally reference each other.
- Extend RFC-0008: rejected because RFC-0008 is already long and focused on architecture, not operational acceptance.
Checklist
Problem Statement
Why
OpenShell is growing beyond Python and TypeScript SDKs. The Go SDK is the first new language contribution (#2044, decomposition tracked in #2270), and there are no formal acceptance criteria for what a language SDK must deliver to be considered conforming.
RFC-0008 (#1764) defines the SDK architecture (binding strategies, shared core, SDK contract), but there's no operational framework for evaluating whether a specific SDK meets the bar. This creates friction for both contributors ("what does my PR need to include?") and reviewers ("what checklist do I evaluate against?").
This was discussed in the contributor meeting on 2026-07-14 as a follow-up to the Go SDK PR decomposition.
What
An RFC proposing:
Three API conformance tiers, each building on the previous:
Three auth levels (independent axis):
Operational requirements (applies to all tiers):
Scorecard format: a standard conformance matrix for each SDK's README showing which tiers and auth levels it implements.
Deliverable
The RFC is the proposal and rationale. The primary output is a scorecard document (e.g.,
sdk/CONFORMANCE.md) that serves as the living acceptance checklist for current and future language SDKs.Proposed Design
Single RFC document covering conformance tiers, auth levels, CI/quality requirements, and the scorecard format. References RFC-0008 for architecture decisions.
Alternatives Considered
Checklist