SDK capability status
Code-level evidence states for the Core SDK client, including explicit NOT_IMPLEMENTED scaffolds.
This reference separates a callable TypeScript shape from runtime capability. It is narrower than product-wide status: it describes the current Core SDK implementation and its proof boundaries.
Evidence states
This page uses the repository's fixed evidence vocabulary. shipped-proven
means the narrow behavior named in a row exists on the release trunk and has
proof appropriate to that claim. For a deliberate NOT_IMPLEMENTED branch,
the proven behavior is the negative contract—not the advertised operation.
Live behavior is claimed only when the evidence names that exact live journey.
Explicit scaffolds and partial branches
| Surface | Availability | Evidence state | Current boundary |
|---|---|---|---|
payments.cancel | Stubbed | shipped-proven | Release-trunk tests prove that every call returns NOT_IMPLEMENTED; cancellation is not available. |
activity.* freshness | Partial | shipped-proven | Release-trunk tests prove the typed contract of list, summary, get and annotate. No live journey is proven, and observedAt names the server read time rather than a freshness verdict. |
offramp.quote, offramp.status | Stubbed | shipped-proven | Release-trunk tests prove both negative contracts; no rail is implied by the types. |
| Organization audit-log listing | Stubbed | shipped-proven | Release-trunk tests prove the NOT_IMPLEMENTED result; audit-log listing is not available. |
targets.resolve({ kind: "destination" }) | Partial | shipped-proven | Release-trunk tests prove destination target resolution returns NOT_IMPLEMENTED. |
payments.pay with an Organization actor | Partial | shipped-proven | Release-trunk tests prove this branch returns NOT_IMPLEMENTED; the state does not claim the operation works. |
target/reference forms using capxulUserId | Partial | shipped-proven | Release-trunk tests prove the relevant conversion/resolution branches return NOT_IMPLEMENTED. |
eip1193AccountProvider().getDeployAccount | Stubbed | shipped-proven | Release-trunk tests prove the method returns NOT_IMPLEMENTED; supplying signer information does not enable it. |
Do not catch these results and pretend success. Gate the UI or workflow, or use an implemented domain-specific path.
Release-trunk implementation does not mean universally live
Auth, identity, Account reads/readiness, destinations, personal payments, documents, requests and inbox, onboarding, and Organization method families contain implemented code paths and hermetic tests. Their live proof varies by method, environment, and milestone. Consult the repository's product-wide capability status and the named proof for the journey you intend to ship.
Organization production composition
Issue #959 is shipped-proven on the release trunk at the hermetic
production-composition boundary. Its contract tests create the standard
production client and prove
backend delegation for Organization, Member, Role, and treasury reads; one
bootstrap authorization and submission; cancellation; typed observed provider
failure; and close/reset behavior. Browser production composes the Openfort
Embedded Signer lazily, while an explicit signer keeps injected-wallet and
deterministic local-key paths available.
Issue #960 is in-flight-proven at the deterministic Core live-chain boundary.
The standard production client passed the personal Account ownership handoff,
one founder-Account Organization bootstrap, confirmed Solo Owner readiness, and
production-backed Organization, Member, Role, and treasury reads against an
isolated real Convex deployment and Base Sepolia. The durable receipt is owned
by the Core SDK capability context.
That live evidence uses an explicit deterministic signer. It does not prove a real browser/Openfort session; issue #961 owns that separate release gate.
Issue #870 is in-flight-proven on its integration branch at two narrower
boundaries. Production-composition tests prove the SDK-created Openfort signer
retains the native failure classification after backend step advancement and
resets before durable same-Organization retry state is cleared. A guarded
development browser run proves the encryption-session classification remains
visible in the Organization lifecycle panel after reload, retry proceeds
without sign-out or broad browser-storage clearing, and a confirmed receipt
uses the same Organization id shown in the failure frame. This is not yet a
published-package consumer claim; final closure remains outside this evidence.