SDK boundary

SDK and integration surfaces without fake package maturity.

This route explains where SDKs and contract consumers fit: around clients, runtime boundaries, account-backed context and future projections. It does not claim published packages, install commands or live APIs.

SurfaceCurrent public boundaryWhere live state comes fromWhat this route does not claim
API and contract layerPublic docs can describe contract consumers and integration boundaries without claiming a published API catalog.Account platform + runtime contractsNot public endpoints, generated schemas, SDK release packages or install snippets.
ClientsCLI, Loom and VS Code remain the visible client surfaces that later contract consumers can align with.Runtime and client layerNot the source of account truth, entitlement truth or release truth.
SDK consumersConsumers are framed conceptually as code that will use runtime and account-safe contracts later.Future integration layerNot installable public packages, package names, npm/crate/pip versions or sample installers.
Account and auth contextAccount-backed operation and future auth_context are part of the model even though this route does not expose them live.Account platformNot live sign-in, account session, Preview Plan assignment or loaded account projection.
Runtime gate decisionsRuntime authorization, sealed operation and machine/license consumption remain downstream from the public docs layer.Runtime layerNot live runtime authorization, machine authorization or license lease state.
Future account and runtime projectionsThe public docs can name future projections so integrations are legible before contracts are wired to public surfaces.Account platform + runtime layerNot implementation guarantees, endpoint commitments or runtime behavior already shipped.

Treat this route as a public explanation of integration boundaries. It helps future SDK consumers understand how runtime contracts, account-safe context, clients and release posture relate before real package distribution or API catalogs exist.

Use Interfaces for client surfaces, Status for readiness and White Paper for the broader doctrine behind the model.