Manual Release - 2026-09-02

[optave-sdk-publisher]

Manual Release

Version: 3.6.0
Source: main
Target Environment: Public Production
Target Repository: optave/interface-client-sdk-lib-dist
Triggered by: ndovha

Files Published:

• sdks/javascript/README.md (SDK documentation)
• sdks/javascript/BUILDING.md (build documentation)
• sdks/javascript/package.json & package-lock.json (package configuration, lock file if present)
• sdks/javascript/webpack*.js (build configurations)
• sdks/javascript/tsconfig.json (TypeScript configuration)
• sdks/javascript/runtime/ (SDK source code)
• sdks/javascript/integration/ (integration examples and usage samples)
• sdks/javascript/generated/ (TypeScript types & validators)
• sdks/javascript/dist/ (built SDK bundles)
• sdks/javascript/scripts/prod/ (production build scripts)
• sdks/javascript/scripts/shared/ (shared utilities)
• sdks/javascript/assets/ (if present)
• sdks/javascript/LICENSE (Apache 2.0 - public SDK license)

Validation Completed:

• ✅ AsyncAPI specification validated
• ✅ TypeScript types validated (no drift)
• ✅ Full Vitest test suite passed
• ✅ Version alignment verified

Ready for review and merge to main.

[greptile-apps]

Greptile Summary

This manual release publishes JavaScript SDK 3.6.0 with a new assistant action, expanded analytics-oriented payload types, a protocol-marker reset to v1, and substantial runtime/build-target updates.

• Repurposes server UMD from a Salesforce-oriented web bundle to a Node-oriented UMD build.
• Adds assistant request methods, generated examples, types, and validator support.
• Updates endpoint generation, privacy checks, declarations, integrations, documentation, and built artifacts.
• Contains a blocking mismatch between the documented CommonJS server-UMD import and the package’s ESM file scope.

Confidence Score: 4/5

The CommonJS server-UMD entry must be made loadable under the package’s module scope before this release is merged.

The release advertises require('@optave/client-sdk/server-umd'), but that export resolves to a .js file governed by "type": "module", preventing the artifact from reliably exposing the documented CommonJS constructor; the remaining documentation mismatch is non-blocking.

Files Needing Attention: sdks/javascript/package.json, sdks/javascript/README.md

Important Files Changed

Filename	Overview
sdks/javascript/package.json	Repurposes and exports server UMD for Node/CommonJS but maps require() to an ESM-scoped .js artifact.
sdks/javascript/runtime/core/main.js	Adds assistant behavior, privacy validation, protocol-v1 envelope construction, and broad runtime updates.
sdks/javascript/generated/types.d.ts	Expands the generated public contract with assistant support and structured analytics-context types.
sdks/javascript/generated/constants.js	Separates SDK and protocol versions and changes the emitted schema major from v3 to v1.
sdks/javascript/webpack.server.umd.config.js	Changes server UMD from a Salesforce web build to a Node-oriented target.
sdks/javascript/README.md	Documents the new Node server-UMD behavior but retains a stale v3 schema-reference example.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[CommonJS consumer] -->|require server-umd| B[Package exports]
  B --> C[dist/server.umd.js]
  D[package type: module] --> C
  C --> E[Node treats .js as ESM]
  E --> F[Import failure or wrong export shape]

Loading

Comments Outside Diff (1)

1. sdks/javascript/package.json, line 32 (link)

   CommonJS subpath resolves as ESM

   When a Node.js CommonJS application follows the new documentation and calls require('@optave/client-sdk/server-umd'), this export resolves to dist/server.umd.js under the package-wide "type": "module" scope, causing Node to treat the UMD file as ESM and reject the import or return the wrong export shape instead of the documented SDK constructor.

   Knowledge Base Used:

   • SDK build and distribution
   • Distribution entry points and artifacts

   

_{Reviews (1): Last reviewed commit: "chore(release): promote SDK changes to p..." | Re-trigger Greptile}

[greptile-apps]

Schema example retains v3

The SDK now derives and emits optave.message.v1, but this example still presents optave.message.v3, giving integrators contradictory guidance and encouraging stale schema expectations in validation or diagnostics.

Knowledge Base Used: Generated client API

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!