@elizaos/core 2.0.3-beta.6 → 2.0.3-beta.7

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,4 +1,4 @@
1
1
  import type { JSONSchema } from "../types/model.js";
2
- export declare const plannerTemplate = "task: Plan next native tool calls.\n\nrules:\n- use only tools array; smallest grounded queue\n- routed action: set parameters.action only if schema has it\n- args grounded in user request or prior tool results\n- obey schema; arrays as JSON arrays, not comma strings\n- no empty strings/placeholders/invented required args; gather via grounded tool or no tool\n- matching tool exists => call it, even missing details; handler owns questions/drafts/confirm/refusal\n- no messageToUser follow-up when matching tool exists\n- messageToUser is user-visible only; no thoughts, analysis, tool names, function syntax, JSON/tool attempts, \"call MESSAGE\"\n- more tool work => native toolCalls only; never narrate/simulate calls\n- partial after tool result => next grounded tool, not messageToUser\n- tool-required router decision => run at least one exposed non-terminal tool before terminal answer\n- incomplete while user needs live/current/external data, filesystem/runtime state, command output, repo work, build, PR, deploy, verify, side effect, and exposed tool can try\n- attachments/memory/snippets do not replace explicit current run/check/fetch/inspect/build/deploy/verify/look up now; call tool\n- exposed tool can try => call it; do not say \"I cannot browse/search/run/inspect/build/deploy/verify\"\n- SHELL is for filesystem/process work, not a fallback for chat-message search/recall, memory queries, or agent-history lookups. When the user wants chat-message search/recall, memory queries, or agent-history lookups and no dedicated search action (e.g. SEARCH_MESSAGES, MESSAGE_SEARCH, MEMORY_SEARCH) is exposed, do not run shell greps, echo placeholders, or simulate the search \u2014 set messageToUser explaining that the capability is not available this turn.\n- candidateActions naming a tool that is not in this turn's exposed tools list is a dead hint \u2014 do not invent SHELL/BROWSER/TASKS workarounds to fulfill it. Either an exposed tool genuinely resolves the user's intent (call it), or no tool fits (set messageToUser). Never emit echo-placeholder SHELL commands such as: echo \"<intent-name>\" / echo \"placeholder for <ACTION>\" / echo \"search <X>\" as a way to \"trigger\" a missing capability \u2014 placeholder echoes burn cost and produce no progress.\n- TASKS_SPAWN_AGENT is for delegating coding/build/repo work to a coding sub-agent (file edits, shell tooling, building/deploying apps, running tests, opening PRs). It is not a fallback for chat-message recall, memory queries, or agent-history lookups. Spawning a coding sub-agent to \"search the Discord channel for messages mentioning X\" routinely ends in sub-agent error/timeout and a generic \"Sorry, something went wrong\" reply to the user. When the user wants chat-message recall and no dedicated search action is exposed, set messageToUser explaining the capability is not available \u2014 do not spawn a sub-agent for it.\n- A one-shot live/current/public-data lookup \u2014 current price, weather, score, news headline, a status, or a value at a known URL \u2014 is NOT coding work: call WEB_FETCH (construct the single URL yourself) or WEB_SEARCH directly and answer from the result. Do NOT spawn a coding sub-agent for it: a sub-agent for a single lookup is slow, frequently re-spawns itself, and posts spurious \"working on it\" progress acks before answering. Spawn only when the task is genuinely build/code/repo/multi-step work.\n- no tool fits or task complete => no toolCalls, set messageToUser\n- set completed=false when this turn's tool calls do not yet achieve the goal (read-then-act, multi-step deploy/build, verification pending); completed=true only when the goal is achieved this turn. omit when unknown.\n- messageToUser and REPLY text must NEVER claim or imply an investigative action is happening, has happened, or is about to happen \u2014 \"I'm fetching X, please hold\", \"Let me look that up\", \"Pulling up the info\", \"Searching for the answer\", \"I'm checking now\", \"I'll get back to you\", \"Spawning a sub-agent\" \u2014 when no tool call this turn is in flight to produce that content. The planner does not run in the background after returning; once this turn ends, no further tool work happens unless a NEW user message arrives. If your tool iterations exhausted without a usable result (search returned nothing, fetch was blocked, scrape gave no usable HTML, RSS was empty), set messageToUser saying so plainly: \"I tried web search via the available tools and couldn't find current info on X \u2014 try checking a news site directly\" or \"The searches returned no usable results\". Never promise ongoing fetch when this turn is the planner's final iteration. This rule covers every grammatical form: past-perfect (\"I have fetched\"), bare past-tense (\"I fetched\"), present-continuous with subject (\"I'm fetching now\", \"I'm checking\"), bare present-participle without subject (\"Fetching latest info\", \"Looking it up\", \"Pulling up the logs\"), and \"please hold\" / \"give me a sec\" / \"be right back\" style stalling phrases.\n- When a tool call produced actual output (stdout, fetched content, search results, file listings, command output), the subsequent messageToUser must include that output directly \u2014 do not replace it with a meta-summary of what the tool did. Phrases like \"Listed files as requested\", \"Provided the output as returned by X\", \"Returned the result\", \"Executed the command\", \"Searched and found results\", or \"Gathered the information\" are meta-narration, not answers. If the tool already returned user-friendly text (verifiedUserFacing is true), include that text in messageToUser rather than describing the action.\n\nIf context has \"# Routing hints\", follow them. They are action routingHint metadata for this turn's exposed actions only.\n\ncontext_object:\n{{contextObject}}\n\ntrajectory:\n{{trajectory}}";
2
+ export declare const plannerTemplate = "task: Plan next native tool calls.\n\nrules:\n- use only tools array; smallest grounded queue\n- routed action: set parameters.action only if schema has it\n- args grounded in user request or prior tool results\n- obey schema; arrays as JSON arrays, not comma strings\n- no empty strings/placeholders/invented required args; gather via grounded tool or no tool\n- matching tool exists => call it, even missing details; handler owns questions/drafts/confirm/refusal\n- no messageToUser follow-up when matching tool exists\n- messageToUser is user-visible only; no thoughts, analysis, tool names, function syntax, JSON/tool attempts, \"call MESSAGE\"\n- more tool work => native toolCalls only; never narrate/simulate calls\n- partial after tool result => next grounded tool, not messageToUser\n- tool-required router decision => run at least one exposed non-terminal tool before terminal answer\n- incomplete while user needs live/current/external data, filesystem/runtime state, command output, repo work, build, PR, deploy, verify, side effect, and exposed tool can try\n- attachments/memory/snippets do not replace explicit current run/check/fetch/inspect/build/deploy/verify/look up now; call tool\n- exposed tool can try => call it; do not say \"I cannot browse/search/run/inspect/build/deploy/verify\"\n- SHELL is for filesystem/process work, not a fallback for chat-message search/recall, memory queries, or agent-history lookups. When the user wants chat-message search/recall, memory queries, or agent-history lookups and no dedicated search action (e.g. SEARCH_MESSAGES, MESSAGE_SEARCH, MEMORY_SEARCH) is exposed, do not run shell greps, echo placeholders, or simulate the search \u2014 set messageToUser explaining that the capability is not available this turn.\n- candidateActions naming a tool that is not in this turn's exposed tools list is a dead hint \u2014 do not invent SHELL/BROWSER/TASKS workarounds to fulfill it. Either an exposed tool genuinely resolves the user's intent (call it), or no tool fits (set messageToUser). Never emit echo-placeholder SHELL commands such as: echo \"<intent-name>\" / echo \"placeholder for <ACTION>\" / echo \"search <X>\" as a way to \"trigger\" a missing capability \u2014 placeholder echoes burn cost and produce no progress.\n- TASKS_SPAWN_AGENT is for delegating coding/build/repo work to a coding sub-agent (file edits, shell tooling, building/deploying apps, running tests, opening PRs). It is not a fallback for chat-message recall, memory queries, or agent-history lookups. Spawning a coding sub-agent to \"search the Discord channel for messages mentioning X\" routinely ends in sub-agent error/timeout and a generic \"Sorry, something went wrong\" reply to the user. When the user wants chat-message recall and no dedicated search action is exposed, set messageToUser explaining the capability is not available \u2014 do not spawn a sub-agent for it.\n- A one-shot live/current/public-data lookup \u2014 current price, weather, score, news headline, a status, or a value at a known URL \u2014 is NOT coding work: call WEB_FETCH (construct the single URL yourself) or WEB_SEARCH directly and answer from the result. Do NOT spawn a coding sub-agent for it: a sub-agent for a single lookup is slow, frequently re-spawns itself, and posts spurious \"working on it\" progress acks before answering. Spawn only when the task is genuinely build/code/repo/multi-step work.\n- no tool fits or task complete => no toolCalls, set messageToUser\n- set completed=false when this turn's tool calls do not yet achieve the goal (read-then-act, multi-step deploy/build, verification pending); completed=true only when the goal is achieved this turn. omit when unknown.\n- messageToUser and REPLY text must NEVER claim or imply an investigative OR task-execution action is happening, has happened, or is about to happen \u2014 \"I'm fetching X, please hold\", \"Let me look that up\", \"Pulling up the info\", \"Searching for the answer\", \"I'm checking now\", \"I'll get back to you\", \"Spawning a sub-agent\", \"I'm working on it\", \"I'm fixing that now\", \"Let me get that done\", \"Wrapping it up\", \"Almost done\", \"Building it now\", \"I'll start on that\" \u2014 when no tool call this turn is in flight to produce that content. A claim that you are working on / starting / fixing / building / wrapping up a task is only legitimate when a task-executing tool call (e.g. TASKS_SPAWN_AGENT) is actually in flight THIS turn; if you did not spawn a sub-agent or take an action this turn, do not say the task is underway. The planner does not run in the background after returning; once this turn ends, no further tool work happens unless a NEW user message arrives. If your tool iterations exhausted without a usable result (search returned nothing, fetch was blocked, scrape gave no usable HTML, RSS was empty), set messageToUser saying so plainly: \"I tried web search via the available tools and couldn't find current info on X \u2014 try checking a news site directly\" or \"The searches returned no usable results\". Never promise ongoing fetch when this turn is the planner's final iteration. This rule covers every grammatical form for both investigative and task-execution verbs (fetch/search/look up/check AND work on/start/fix/build/wrap up/finish): past-perfect (\"I have fetched\", \"I have started fixing it\"), bare past-tense (\"I fetched\", \"I started on it\"), present-continuous with subject (\"I'm fetching now\", \"I'm checking\", \"I'm working on it\", \"I'm fixing it\"), bare present-participle without subject (\"Fetching latest info\", \"Looking it up\", \"Working on it\", \"Wrapping it up\"), and \"please hold\" / \"give me a sec\" / \"be right back\" / \"almost done\" style stalling phrases.\n- When a tool call produced actual output (stdout, fetched content, search results, file listings, command output), the subsequent messageToUser must include that output directly \u2014 do not replace it with a meta-summary of what the tool did. Phrases like \"Listed files as requested\", \"Provided the output as returned by X\", \"Returned the result\", \"Executed the command\", \"Searched and found results\", or \"Gathered the information\" are meta-narration, not answers. If the tool already returned user-friendly text (verifiedUserFacing is true), include that text in messageToUser rather than describing the action.\n\nIf context has \"# Routing hints\", follow them. They are action routingHint metadata for this turn's exposed actions only.\n\ncontext_object:\n{{contextObject}}\n\ntrajectory:\n{{trajectory}}";
3
3
  export declare const plannerSchema: JSONSchema;
4
4
  //# sourceMappingURL=planner.d.ts.map
@@ -1 +1 @@
1
- {"version":3,"file":"planner.d.ts","sourceRoot":"","sources":["../../src/prompts/planner.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,gBAAgB,CAAC;AAEjD,eAAO,MAAM,eAAe,6wLAgCb,CAAC;AAEhB,eAAO,MAAM,aAAa,EAAE,UAkC3B,CAAC"}
1
+ {"version":3,"file":"planner.d.ts","sourceRoot":"","sources":["../../src/prompts/planner.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,gBAAgB,CAAC;AAEjD,eAAO,MAAM,eAAe,g9MAgCb,CAAC;AAEhB,eAAO,MAAM,aAAa,EAAE,UAkC3B,CAAC"}
@@ -1 +1 @@
1
- {"version":3,"file":"fallback-reply.d.ts","sourceRoot":"","sources":["../../../src/services/message/fallback-reply.ts"],"names":[],"mappings":"AAEA;;;;;;;;;;;;GAYG;AACH,wBAAgB,gBAAgB,CAAC,KAAK,EAAE,OAAO,GAAG,OAAO,CAyBxD;AAED;;;;;;GAMG;AACH,wBAAgB,WAAW,CAAC,KAAK,EAAE,OAAO,GAAG,OAAO,CA6BnD;AAED,wBAAgB,uBAAuB,CAAC,cAAc,EAAE,MAAM,GAAG,MAAM,CAyBtE;AAED,wBAAgB,oBAAoB,CAAC,GAAG,EAAE,MAAM,GAAG,MAAM,CAOxD"}
1
+ {"version":3,"file":"fallback-reply.d.ts","sourceRoot":"","sources":["../../../src/services/message/fallback-reply.ts"],"names":[],"mappings":"AA6BA;;;;;;;;;;;;GAYG;AACH,wBAAgB,gBAAgB,CAAC,KAAK,EAAE,OAAO,GAAG,OAAO,CAkBxD;AAED;;;;;;GAMG;AACH,wBAAgB,WAAW,CAAC,KAAK,EAAE,OAAO,GAAG,OAAO,CAkBnD;AAED,wBAAgB,uBAAuB,CAAC,cAAc,EAAE,MAAM,GAAG,MAAM,CAyBtE;AAED,wBAAgB,oBAAoB,CAAC,GAAG,EAAE,MAAM,GAAG,MAAM,CAOxD"}
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@elizaos/core",
3
- "version": "2.0.3-beta.6",
3
+ "version": "2.0.3-beta.7",
4
4
  "description": "Core runtime, plugin abstractions, and AgentRuntime for elizaOS — actions, providers, evaluators, services, models, and types.",
5
5
  "homepage": "https://github.com/elizaOS/eliza",
6
6
  "repository": {
@@ -141,9 +141,9 @@
141
141
  "@ai-sdk/provider": "3.0.10",
142
142
  "@ai-sdk/provider-utils": "4.0.26",
143
143
  "@bufbuild/protobuf": "^2.12.0",
144
- "@elizaos/contracts": "2.0.3-beta.6",
145
- "@elizaos/logger": "2.0.3-beta.6",
146
- "@elizaos/prompts": "2.0.3-beta.6",
144
+ "@elizaos/contracts": "2.0.3-beta.7",
145
+ "@elizaos/logger": "2.0.3-beta.7",
146
+ "@elizaos/prompts": "2.0.3-beta.7",
147
147
  "@noble/ciphers": "2.2.0",
148
148
  "@noble/hashes": "2.2.0",
149
149
  "@openrouter/ai-sdk-provider": "^2.0.0",
@@ -169,5 +169,5 @@
169
169
  "publishConfig": {
170
170
  "access": "public"
171
171
  },
172
- "gitHead": "990dc996172b3e0fb525a75052a5ac28a4cd4de5"
172
+ "gitHead": "61094f10458d11055c75b3dd0bae374e3f66bac5"
173
173
  }