Bump pinned sdk version

[The64thRealm]

bumped to 1.3.45

[claude]

Claude finished @The64thRealm's task in 2m 19s —— View job

---

Code Review

Reviewed the 3-line bump against origin/main. The change itself is clean and internally consistent — one finding, and it's about external coordination rather than the diff.

Findings

1. The pin must match what play ships, not npm latest — inline comment on src/dev/sdk-js-version:1

.github/workflows/auto-tag.yml:39-55 blocks tag creation unless this file exactly equals the @wvdsh/sdk-js version in wvdsh/play's latest-release package-lock.json. Because this PR also bumps Cargo.toml to 0.1.93, merging fires that job right away — if play is still on 1.3.43/1.3.44, the 0.1.93 release silently never tags.

The 1.3.43 → 1.3.45 jump (skipping 1.3.44) looks like an npm-latest resolve, which is exactly the drift scripts/bump-sdk-js.sh:17-18 warns against. Worth confirming play parity before merge.

Verified

• Cargo.toml:3 and Cargo.lock:3079 both at 0.1.93 — consistent, and only the wavedash package entry moved
• No stray hardcoded versions elsewhere in the repo (README, scripts, workflows all clean)
• src/dev/sdk-js-version is exactly 1.3.45\n — satisfies both guards in src/dev/server.rs: the_pinned_sdk_version_file_holds_one_bare_semver (three bare numeric parts) and the_inject_url_never_carries_the_version_files_trailing_newline (.trim() at server.rs:34)
• No SDK API surface changes needed — src/dev/dev.js and src/dev/shell.html only touch window.Wavedash.gameLoaded, Wavedash.loadComplete(), and window.__wavedashSdkConfig, all stable across a patch bump

Could not verify (no network / no cargo in this sandbox)

• Is @wvdsh/sdk-js@1.3.45 actually published? A hand-edit bypasses the npm view guard at scripts/bump-sdk-js.sh:57-60. If it isn't on npm, wavedash dev 404s on the jsdelivr inject URL at runtime — there's no build-time check for this.
• Does play's live release ship 1.3.45? Requires access to the private wvdsh/play repo.
• Did a game boot under wavedash dev? Both scripts/bump-sdk-js.sh:77 and the workflow's own error message ask for this smoke test after a bump; nothing in the PR indicates it ran.

Also a nit: the PR body mentions only the SDK bump and not the CLI 0.1.92 → 0.1.93 version bump that ships with it.
· branch bump-sdk-version

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[claude]

This pin must equal what play ships, not npm latest — the release gate hard-fails otherwise.

.github/workflows/auto-tag.yml:39-55 blocks tag creation unless this file matches .packages["node_modules/@wvdsh/sdk-js"].version in wvdsh/play's latest release package-lock.json:

if [ "$pinned" != "$shipped" ]; then
  echo "::error::wavedash dev would inject @wvdsh/sdk-js@$pinned but play $tag ships $shipped..."
  exit 1
fi

Since this PR also bumps Cargo.toml to 0.1.93, merging fires that job immediately — and if play's live release ships 1.3.43 or 1.3.44, the 0.1.93 tag/release never gets created.

scripts/bump-sdk-js.sh with no argument pins to npm latest, which is precisely the drift this gate exists to catch — the script's own docs call it out (scripts/bump-sdk-js.sh:17-18):

Keep the pin in step with the @wvdsh/sdk-js version play bundles in prod (play/package.json)

The jump 1.3.43 → 1.3.45 (skipping 1.3.44) reads like an npm-latest resolve rather than a play-parity bump, so worth confirming before merge:

gh api repos/wvdsh/play/contents/package-lock.json \
  --jq '.content' -H "Accept: application/vnd.github.raw" \
  | jq -r '.packages["node_modules/@wvdsh/sdk-js"].version'

If play ships something other than 1.3.45, pin to that value instead.