Builder image ships unstamped version ("0.0.0-webstudio-version"), breaking all CLI/MCP compatibility

[Markus-Stuppnig]

Summary

The builder:latest image reports an unstamped placeholder version
(0.0.0-webstudio-version) instead of a real semver, which causes the
server-side API-compatibility check to reject every published webstudio
CLI release. As a result, webstudio link / sync / mcp cannot be used
against a self-hosted stack at all, regardless of CLI version.

Environment

• Image: ghcr.io/webstudio-community/builder:latest
• Image ID: 7360dd4d61a8, built ~3 days before testing, linux/arm64
• Deployed via docker-compose.yml from webstudio-community/webstudio-self-host
• Host: macOS, Node v24.16.0, webstudio CLI (npm)

Evidence

Inside the running app container, the core packages are still on the
build-time placeholder version:

$ docker compose exec app grep version \
    /app/node_modules/@webstudio-is/trpc-interface/package.json
"version": "0.0.0-webstudio-version"

Same for @webstudio-is/protocol and @webstudio-is/sdk.

Reproduction

1. Bring up the stack from webstudio-self-host's docker-compose.yml.
2. npx webstudio link --link "<share-link-from-builder>"
3. npx webstudio sync

Bisected across CLI versions:

CLI version	Result
0.282.0, 0.281.0, 0.270.0–0.266.0	Rejected: clientVersionUnsupported ("This version of the Webstudio CLI is incompatible with the current API. Update the CLI...")
0.265.0	Passes the version gate, but fails with 404 NOT_FOUND on build.loadProjectDataByProjectId (route doesn't exist on this build)

So there is currently no published CLI version that works against this
image — the compatibility window is empty.

Root cause (hypothesis)

@webstudio-is/trpc-interface's api-compatibility.ts gates CLI requests
by comparing the client's x-webstudio-client-version header against the
server's own version. Since the packages inside the image are never
stamped with a real version during the Docker build (they stay at
0.0.0-webstudio-version), the comparison effectively can't match any
real CLI release — every semver-aware client gets rejected as
clientVersionUnsupported.

Suggested fix

Run the upstream version-stamping step (whatever webstudio-is/webstudio's
release pipeline uses, e.g. changesets version or equivalent) as part of
the fork's Docker build, before pnpm build, so the shipped image reports
its actual upstream version instead of the placeholder.

Ask

• Can you confirm this is a build-pipeline gap rather than intentional?
• Is there a currently-working pinned CLI version I'm missing, or is this
  genuinely broken for everyone right now?

Happy to test a fix against my local stack.