chore(sdk): release 0.4.0 — republish expanded client surface; pin CLI/MCP deps

[dodeja]

npm's @terminal49/sdk@0.3.1 is stale: it predates the terminals, vessels, webhooks, webhookNotifications, and mapTrackingRequest surface that the CLI and MCP server compile against, so npm install -g @terminal49/cli would install a broken tool (39 TS errors when built against registry 0.3.1; verified by building the CLI against both registry and workspace SDK).

This PR:

• bumps sdks/typescript-sdk to 0.4.0 (package.json, release-please manifest, lockfile — mirroring release-please's extra-files updates)
• pins @terminal49/cli and packages/mcp to @terminal49/sdk@0.4.0
• adds the 0.4.0 CHANGELOG entry

After merge: cut release sdk-v-v0.4.0 (publishes the SDK via the existing workflow), then re-cut the CLI release so @terminal49/cli@0.1.0 ships against a working registry SDK.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Bca2z6b3pMPb3pe911CXAP

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

Greptile Summary

This PR prepares @terminal49/sdk 0.4.0 for publication and pins the CLI and MCP packages to that expanded SDK release.

• Updates the SDK package version, release manifest, root lockfile metadata, and changelog.
• Pins the CLI and MCP dependencies to exactly @terminal49/sdk@0.4.0.
• Preserves the repository’s established SDK component-tag format.

Confidence Score: 5/5

The PR appears safe to merge, with the dependency pins and release metadata consistently targeting SDK 0.4.0.

The changed workspace dependencies resolve to the matching local SDK during repository builds, and the package, manifest, lockfile, changelog, and accepted release-tag format are aligned.

Important Files Changed

Filename	Overview
.release-please-manifest.json	Advances the SDK release baseline from 0.3.1 to 0.4.0 consistently with the package metadata.
package-lock.json	Synchronizes workspace package and dependency versions with the 0.4.0 SDK release.
packages/mcp/package.json	Pins MCP to the expanded SDK version it compiles against.
sdks/typescript-sdk-cli/package.json	Pins the published CLI to SDK 0.4.0 so registry installations receive the required client surface.
sdks/typescript-sdk/CHANGELOG.md	Documents the expanded public client surface and uses the established SDK tag naming convention.
sdks/typescript-sdk/package.json	Bumps the SDK package version to 0.4.0 for publication.

_{Reviews (1): Last reviewed commit: "chore(sdk): release 0.4.0 — republish ex..." | Re-trigger Greptile}

Context used:

• Knowledge Base — TypeScript SDK CLI (@terminal49/cli)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
api	Building	Preview	Aug 22, 2026 7:19am

[vorflux]

Summary

Reviewed — found 3 issues in the SDK 0.4.0 release metadata and dependency pins. The review focused on whether the CLI, MCP package, and SDK can be published and consumed consistently through the repository’s existing workflows.

Findings

sdks/typescript-sdk-cli/package.json

1. The CLI release cannot currently complete through the trusted-publishing workflow because the npm package has not been bootstrapped.

packages/mcp/package.json

1. The documented SDK setup helper still installs @terminal49/sdk@0.2.0, overriding the new manifest pin.

sdks/typescript-sdk/package.json

1. The standalone SDK lockfile still records version 0.3.1, leaving release metadata inconsistent.

Verdict

⚠️Changes requested. The release should not proceed until the CLI publication path is bootstrapped and the remaining SDK version references are aligned with 0.4.0.

---

Review with Vorflux

[vorflux]

Pinning the CLI to SDK 0.4.0 does not currently result in an installable CLI release. @terminal49/cli has no package entry on npm, while .github/workflows/publish_typescript_cli.yml relies exclusively on OIDC trusted publishing. npm requires the package to exist before a trusted publisher can be configured, so the first publication needs an approved bootstrap publication before this workflow can work. This is not theoretical: the cli-v-v0.1.0 release built and tested successfully after this change, then failed specifically at the npm publish step, and npm view @terminal49/cli still returns 404. Bootstrap the package, configure .github/workflows/publish_typescript_cli.yml as its trusted publisher, and then retry the release; otherwise the stated npm install -g @terminal49/cli outcome remains unavailable.

[vorflux]

This updates the MCP manifest to SDK 0.4.0, but the documented npm run sdk:setup path still hard-codes const sdkSemver = '0.2.0' in packages/mcp/scripts/sdk-setup.mjs. Running it with its default published mode—or the documented T49_SDK_SOURCE=published—therefore installs @terminal49/sdk@0.2.0 with --no-save, overriding the version declared here and defeating this pin. Update the helper to install 0.4.0, preferably by reading dependencies['@terminal49/sdk'] from this package manifest so future releases cannot drift again.

[vorflux]

The SDK version is now 0.4.0, but sdks/typescript-sdk/package-lock.json still records 0.3.1 in both its top-level version and packages[""].version fields. That package-local lockfile is actively used by standalone SDK CI and by the publish workflow’s npm ci, and previous SDK releases updated it alongside package.json. Although npm currently tolerates a package-version-only mismatch during npm ci, this leaves committed release metadata inconsistent and causes the next lockfile regeneration to produce unrelated churn. Regenerate or update the package-local lockfile so both version fields are 0.4.0.