migrate-waniwani-sdk-0.16-to-0.17
Migrate @waniwani/sdk 0.16 → 0.17
A self-contained migration for the single hop from 0.16.x to 0.17.0. Apply it when a project on 0.16 is moving to 0.17. It covers only that jump; for other version boundaries use the matching migrate-waniwani-sdk-<from>-to-<to> skill, or the general procedure in the SDK's changelog.
Precondition: the project is on @waniwani/sdk@0.16.x. If it is on an older version, migrate up to 0.16 first (that jump ships its own migration); if it is already on 0.17+, there is nothing to do here.
What 0.17 changes
useWaniwani() from @waniwani/sdk/mcp/react is now purely host-agnostic: it resolves its config (endpoint, source, widget token, session id) from explicit options or from a toolResponseMetadata object you pass, and nothing else. It no longer reads a WidgetProvider context and no longer opens its own connection to the widget host to discover the config.
Why: on an MCP-Apps host the tool response _meta (which carries the Waniwani config) is delivered once, to whichever host bridge is connected and listening at that moment. In a skybridge widget that bridge is skybridge. The hook opening a second connection raced the first and missed the one-shot on Claude, so the old auto-discovery was unreliable. The fix makes the core hook take the metadata as data, and adds a skybridge adapter entry that supplies it.
This break is invisible to tsc. A bare useWaniwani() still typechecks — it just returns a no-op widget at runtime (no sessionId, track.* does nothing). So you cannot find the call sites by chasing type errors the way earlier SDK migrations worked. Find them by auditing imports of useWaniwani (step 2).