@mastra/client-js 1.20.0-alpha.6 → 1.20.0-alpha.8

package/CHANGELOG.md

@@ -1,5 +1,19 @@
 # @mastra/client-js
 
+## 1.20.0-alpha.8
+
+### Patch Changes
+
+- Updated dependencies [[`9aee493`](https://github.com/mastra-ai/mastra/commit/9aee493ed6089b5133472623dcce49934bf2d509)]:
+  - @mastra/core@1.36.0-alpha.8
+
+## 1.20.0-alpha.7
+
+### Patch Changes
+
+- Updated dependencies [[`a935b0a`](https://github.com/mastra-ai/mastra/commit/a935b0a0977ae3f196b33ec7621f528069c82db0)]:
+  - @mastra/core@1.36.0-alpha.7
+
 ## 1.20.0-alpha.6
 
 ### Patch Changes

package/dist/docs/SKILL.md

@@ -3,7 +3,7 @@ name: mastra-client-js
 description: Documentation for @mastra/client-js. Use when working with @mastra/client-js APIs, configuration, or implementation.
 metadata:
   package: "@mastra/client-js"
-  version: "1.20.0-alpha.6"
+  version: "1.20.0-alpha.8"
 ---
 
 ## When to use

package/dist/docs/assets/SOURCE_MAP.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.20.0-alpha.6",
+  "version": "1.20.0-alpha.8",
   "package": "@mastra/client-js",
   "exports": {
     "RequestContext": {

package/dist/docs/references/docs-agents-signals.md

@@ -86,6 +86,32 @@ agent.sendSignal(
 )
 ```
 
+## Identify users with attributes
+
+Use `attributes` to tag each signal with user identity. The signal type and attributes are rendered as XML so the model can distinguish who said what in a multi-user thread:
+
+```typescript
+agent.sendSignal(
+  {
+    type: 'user',
+    contents: 'Can we simplify the API surface?',
+    attributes: { name: 'Devin', from: 'slack' },
+  },
+  {
+    resourceId: 'user_123',
+    threadId: 'thread_456',
+  },
+)
+```
+
+The model receives:
+
+```xml
+<user name="Devin" from="slack">Can we simplify the API surface?</user>
+```
+
+The UI sees just the message contents but can also read `attributes` and `metadata` off the signal message for custom rendering (e.g. showing user names, avatars, or platform badges).
+
 ## Send external event context
 
 Use custom signal types for system-generated context. Non-user signal types are rendered as XML-style user-role context so they can appear inside conversation history without looking like assistant output.
@@ -96,7 +122,7 @@ agent.sendSignal(
     type: 'system-reminder',
     contents: 'User X has left a new PR comment asking for a smaller API surface.',
     attributes: {
-      type: 'github',
+      source: 'github',
       pr: '123',
     },
   },
@@ -110,7 +136,7 @@ agent.sendSignal(
 The model receives the custom signal as context like this:
 
 ```xml
-<system-reminder type="github" pr="123">User X has left a new PR comment asking for a smaller API surface.</system-reminder>
+<system-reminder source="github" pr="123">User X has left a new PR comment asking for a smaller API surface.</system-reminder>
 ```
 
 Use XML-safe signal type names and attribute names. Signal type names and attribute names can contain letters, numbers, underscores, periods, and hyphens. They must start with a letter or underscore.

package/dist/docs/references/reference-client-js-agents.md

@@ -201,7 +201,7 @@ await agent.sendSignal({
 
 Returns `{ accepted: true, runId: string }`.
 
-**signal** (`{ type: 'user-message' | string; contents: string | Array<TextPart | FilePart>; attributes?: Record<string, JSONValue>; metadata?: Record<string, unknown>; providerOptions?: ProviderMetadata }`): \`user-message\` signals are treated as user input. Other signal types are wrapped in XML context (with any \`attributes\`) before the next model call. \`providerOptions\` is attached to the resulting prompt turn and persisted on the stored signal message.
+**signal** (`{ type: 'user-message' | 'system-reminder' | string; contents: string | Array<TextPart | FilePart>; attributes?: Record<string, JSONValue>; metadata?: Record<string, unknown>; providerOptions?: ProviderMetadata }`): \`user-message\` signals without attributes are treated as plain user input. All other signals — including \`user-message\` with \`attributes\`, \`system-reminder\`, and custom types — are wrapped in an XML element named after the signal type with \`attributes\` rendered as XML attributes (e.g. \`\<user name="Devin" from="slack">message\</user>\`). The model sees the XML; the UI sees the raw contents and can read \`attributes\` for custom rendering. \`providerOptions\` is attached to the resulting prompt turn and persisted on the stored signal message.
 
 **runId** (`string`): Run ID to target directly.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mastra/client-js",
-  "version": "1.20.0-alpha.6",
+  "version": "1.20.0-alpha.8",
   "description": "The official TypeScript library for the Mastra Client API",
   "author": "",
   "type": "module",
@@ -39,7 +39,7 @@
     "canonicalize": "^1.0.8",
     "jose": "^6.2.1",
     "json-schema": "^0.4.0",
-    "@mastra/core": "1.36.0-alpha.6",
+    "@mastra/core": "1.36.0-alpha.8",
     "@mastra/schema-compat": "1.2.10"
   },
   "peerDependencies": {
@@ -57,8 +57,8 @@
     "zod": "^4.3.6",
     "@internal/ai-sdk-v4": "0.0.43",
     "@internal/ai-sdk-v5": "0.0.43",
-    "@internal/lint": "0.0.96",
-    "@internal/types-builder": "0.0.71"
+    "@internal/types-builder": "0.0.71",
+    "@internal/lint": "0.0.96"
   },
   "engines": {
     "node": ">=22.13.0"