feat(sdk): SDK acceptance scorecard and conformance tiers #2292

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

• I've reviewed existing issues and the architecture docs
• This is a design proposal, not a "please build this" request