# The SDK roadmap Where the SDK goes next, in priority order. It comes from builders' feedback — an outside review of the SDK and the questions builders hit while shipping apps — and from what we found checking them. The summary of that review is ours too: the runtime is more mature than the SDK product around it. So the next cycle is not mainly new primitives; it is making the SDK **predictable, versioned, testable and safe by default**, without making the architecture conventional. One `Space` for collaboration, AI, state, identity and authority stays. This page changes as items ship. What already changed is listed under [Changes](./sdk.md#changes). ## Now: before we call the SDK stable **1. Keep the room key out of your logs.** ✅ Shipped 2026-10-05. A Space's link and key are credentials — whoever holds them is a member. `console.log(space)` used to print both, and an error reporter that serialises the object would have sent them to a third party. Now logging, inspecting or serialising a `Space`, `Lane` or the `Witbitz` client shows `[REDACTED]`, and only `space.key` and `space.shareLink` hand them out — by name, on purpose. **2. Versions you choose.** ✅ Versioned paths shipped 2026-10-05 with SDK 1.0.0 ([Versions](./sdk.md#versions)); the npm package is next. Today your page loads the SDK from a live URL, so a release reaches your app when your users reload. We will publish immutable, versioned paths (with integrity hashes), a moving `latest` channel for demos and experiments, and an npm package; semver, with deprecation periods for anything that can break your code. For production we will recommend pinning a version — for a platform whose claim is that you can verify what code runs, you should also choose which code your app runs. **3. Docs and types that match the code.** ✅ Shipped 2026-10-05: the types cover the whole surface, and a test fails when the code, the types or this page's method names disagree. [Types for the whole surface](https://witbitz-spaces.pages.dev/witbitz-sdk.d.ts) shipped on 2026-10-05. Next, a check that holds the types and the [SDK page](./sdk.md) to the code itself, so a method or an option cannot be documented one way and behave another. ## Next: the developer product **4. A test harness.** 🔨 Built 2026-10-05 (`@witbitz/test`): it runs the real room service in your test process, with scripted agents. It ships with the npm package (item 2). A local, deterministic stand-in for the runtime: scripted agents that reply or propose, several members, a network you can cut — no tokens, no production. Rooms combine AI, several people, realtime and approvals, and you should be able to test all of that in CI. **5. A separate admin SDK.** ✅ Shipped 2026-10-05 as `WitbitzAdmin` ([Builder calls](./sdk.md#builder-calls)). Builder operations (origins, providers, hosts, room administration, users and billing) take your tenant secret key and belong on your server. They will move to their own module, so a secret key is hard to bundle into a page by accident — and `wb.users` (your app's billed users, not Witbitz accounts) gets a name that says so. The old names keep working through a deprecation period. **6. A turn you can hold, and events you control.** ✅ Shipped 2026-10-05: [`space.turn()`](./sdk.md#turn), `{ replay: false }`, and `on()` returns an unsubscribe. `send()` keeps its room semantics (others may speak, the assistant may stay quiet). Alongside it, a turn handle: its streamed text, its outcome, a timeout and `abort()`. History replay into `on('message')` becomes explicit (opt in or out), and `on()` returns an unsubscribe function. ## Then **7. A learning path.** ✅ Shipped 2026-10-05 ([the path](./sdk.md#path)). The [SDK page](./sdk.md) reorganised into steps: quickstart → build an app → give the AI authority → add people → personal AI → production → the security model → builder operations — so the second message comes before hardware attestation. **Later:** nothing open. Shipped 2026-10-05 from this list: [row schemas](./sdk.md#schemas) for the store, [`space.plan(change)`](./sdk.md#the-surface) — what a change to a room requires, and whether the history comes along — and `wb.capabilities()` for feature detection. ## What will not change A `Space` stays the one thing you build on. And the security model stays visible: we will make it easier to consume, not hide it behind familiar shapes — [verify it yourself](./verify.md).