eve 0.79.1 → 0.79.2
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.
- package/CHANGELOG.md +18 -0
- package/dist/src/channel/pending-authorization.d.ts +10 -0
- package/dist/src/channel/pending-authorization.js +1 -0
- package/dist/src/compiled/.vendor-stamp.json +2 -2
- package/dist/src/compiled/@eve/tracing/index.js +1 -1
- package/dist/src/compiled/@eve/tracing/otel.js +1 -1
- package/dist/src/compiled/_chunks/workflow/{mcp-C01bDEX-.js → mcp-Bwx_LQ4q.js} +4 -4
- package/dist/src/compiler/extension-compatibility.d.ts +18 -18
- package/dist/src/compiler/extension-compatibility.js +1 -1
- package/dist/src/execution/dynamic-workflow/tool.js +1 -1
- package/dist/src/execution/proxied-deliver-step.js +1 -1
- package/dist/src/execution/publish-session-events.d.ts +13 -3
- package/dist/src/execution/publish-session-events.js +1 -1
- package/dist/src/execution/sandbox/bindings/microsandbox-runtime.js +1 -1
- package/dist/src/execution/session/active-turn.d.ts +2 -1
- package/dist/src/execution/session/active-turn.js +1 -1
- package/dist/src/execution/session/turn-step.js +1 -1
- package/dist/src/execution/session/turn.d.ts +1 -0
- package/dist/src/execution/session/turn.js +1 -1
- package/dist/src/execution/tasks/task-id-input.js +1 -1
- package/dist/src/execution/tools/agent-router-workflow.js +1 -1
- package/dist/src/execution/tools/workflow/apply-run-messages-step.d.ts +6 -2
- package/dist/src/execution/tools/workflow/apply-run-messages-step.js +1 -1
- package/dist/src/execution/tools/workflow/body.d.ts +10 -1
- package/dist/src/execution/tools/workflow/body.js +1 -1
- package/dist/src/execution/tools/workflow/owner-inbox.js +1 -1
- package/dist/src/execution/tools/workflow/serve.js +1 -1
- package/dist/src/harness/action-result-helpers.js +1 -1
- package/dist/src/harness/attachment-staging.js +1 -1
- package/dist/src/harness/compaction/engine.js +3 -1
- package/dist/src/harness/compaction/prompt.d.ts +7 -0
- package/dist/src/harness/compaction/prompt.js +1 -1
- package/dist/src/harness/hitl/approvals.js +1 -1
- package/dist/src/harness/hitl/approved-calls.js +1 -1
- package/dist/src/harness/input-request-resolution.d.ts +2 -1
- package/dist/src/harness/input-request-resolution.js +1 -1
- package/dist/src/instrumentation/native-events.js +1 -1
- package/dist/src/internal/application/optional-package-import.d.ts +5 -0
- package/dist/src/internal/application/optional-package-import.js +1 -1
- package/dist/src/internal/application/stamped-package-version.js +1 -1
- package/dist/src/internal/nitro/host/start-production-server.js +2 -2
- package/dist/src/protocol/message.d.ts +2 -0
- package/dist/src/protocol/message.js +1 -1
- package/dist/src/public/channels/teams/authorization.d.ts +53 -0
- package/dist/src/public/channels/teams/authorization.js +1 -0
- package/dist/src/public/channels/teams/defaults.js +2 -2
- package/dist/src/public/channels/teams/hitl.d.ts +2 -1
- package/dist/src/public/channels/teams/teamsChannel.js +1 -1
- package/dist/src/public/channels/telegram/authorization-callback.js +1 -1
- package/dist/src/public/next/index.js +1 -1
- package/dist/src/public/next/server.d.ts +11 -2
- package/dist/src/public/next/server.js +1 -1
- package/dist/src/setup/scaffold/create/project.js +1 -1
- package/dist/src/shared/action-types.d.ts +1 -0
- package/dist/src/shared/action-types.js +1 -1
- package/dist/src/tools/provided/ask-question-workflow.js +1 -1
- package/dist/src/tools/provided/sleep-workflow.js +1 -1
- package/dist/src/tools/signature.d.ts +4 -2
- package/dist/src/tools/signature.js +1 -1
- package/docs/channels/teams.mdx +6 -0
- package/docs/concepts/built-in-tools.md +1 -1
- package/docs/guides/hooks.md +4 -0
- package/docs/guides/instrumentation/instrumentation.mdx +2 -0
- package/package.json +1 -1
|
@@ -1 +1 @@
|
|
|
1
|
-
import{isObject}from"#shared/guards.js";const CONSTRAINT_KEYS=[`format`,`pattern`,`minimum`,`maximum`,`exclusiveMinimum`,`exclusiveMaximum`,`minLength`,`maxLength`,`minItems`,`maxItems`,`default`],IDENTIFIER=/^[A-Za-z_$][\w$]*$/u;function renderToolSignature(e){let t=e
|
|
1
|
+
import{isObject}from"#shared/guards.js";const MAX_SIGNATURE_LENGTH=4e3,CONSTRAINT_KEYS=[`format`,`pattern`,`minimum`,`maximum`,`exclusiveMinimum`,`exclusiveMaximum`,`minLength`,`maxLength`,`minItems`,`maxItems`,`default`],IDENTIFIER=/^[A-Za-z_$][\w$]*$/u;function renderToolSignature(e){let t=renderSignature(e,!0);if(t.length<=MAX_SIGNATURE_LENGTH)return t;let n=renderSignature(e,!1);return n.length>MAX_SIGNATURE_LENGTH?`${n.slice(0,3997)}...`:n}function renderSignature(e,t){let render=e=>renderType(e,{budget:{remaining:1e3},depth:0,descriptions:t,refs:new Set,root:e}),n=e.inputSchema===void 0?`{}`:render(e.inputSchema),r=e.outputSchema===void 0?`unknown`:render(e.outputSchema);return`${e.name}(input: ${n}): Promise<${r}>`}function renderType(e,t){if(e===!0||!isObject(e)||t.depth>6||t.budget.remaining<=0)return`unknown`;if(--t.budget.remaining,typeof e.$ref==`string`){let n=resolveRef(e.$ref,t);return n===void 0?`unknown`:renderType(n,{...t,refs:new Set([...t.refs,e.$ref])})}if(`const`in e)return literal(e.const);if(Array.isArray(e.enum))return union(e.enum.map(literal));let n=Array.isArray(e.anyOf)?e.anyOf:Array.isArray(e.oneOf)?e.oneOf:void 0;if(n!==void 0)return union(n.map(e=>renderType(e,next(t))));if(Array.isArray(e.allOf))return e.allOf.map(e=>wrap(renderType(e,next(t)))).join(` & `);let r=(Array.isArray(e.type)?e.type:[e.type]).filter(e=>typeof e==`string`).map(n=>renderPrimitive(n,e,t));return r.length>0?union(r):isObject(e.properties)||e.additionalProperties!==void 0?renderObject(e,t):e.items===void 0?`unknown`:renderPrimitive(`array`,e,t)}function renderPrimitive(e,t,n){switch(e){case`string`:return`string`;case`number`:case`integer`:return`number`;case`boolean`:return`boolean`;case`null`:return`null`;case`array`:return`${wrap(renderType(t.items,next(n)))}[]`;case`object`:return renderObject(t,n);default:return`unknown`}}function renderObject(e,t){let n=isObject(e.properties)?e.properties:{},r=new Set(Array.isArray(e.required)?e.required.filter(e=>typeof e==`string`):[]),i=Object.entries(n).map(([e,n])=>{let i=IDENTIFIER.test(e)?e:JSON.stringify(e),a=r.has(e)?``:`?`,o=isObject(n)?propertyComment(n,t.descriptions):``;return`${i}${a}: ${renderType(n,next(t))}${o}`}),a=e.additionalProperties;return isObject(a)&&i.push(`[key: string]: ${renderType(a,next(t))}`),i.length===0?a===!1?`{}`:`Record<string, unknown>`:`{ ${i.join(`; `)} }`}function propertyComment(e,t){let n=[],r=t&&typeof e.description==`string`?e.description.replaceAll(/\s+/gu,` `).replace(/[\s.;,:]+$/u,``).trim():``;r.length>0&&n.push(truncate(r));for(let t of CONSTRAINT_KEYS)e[t]!==void 0&&n.push(`${t}: ${JSON.stringify(e[t])}`);return n.length===0?``:` /* ${n.join(`; `).replaceAll(`*/`,`* /`)} */`}function resolveRef(e,t){if(t.refs.has(e)||!e.startsWith(`#`))return;let n=t.root;for(let t of e.slice(1).split(`/`).filter(Boolean)){if(!isObject(n))return;n=n[t.replaceAll(`~1`,`/`).replaceAll(`~0`,`~`)]}return n}function next(e){return{...e,depth:e.depth+1}}function literal(e){return e===void 0?`undefined`:JSON.stringify(e)}function union(e){let t=[...new Set(e)];return t.length===0?`never`:t.join(` | `)}function wrap(e){return e.includes(` | `)||e.includes(` & `)?`(${e})`:e}function truncate(e){return e.length>120?`${e.slice(0,117)}...`:e}export{renderToolSignature};
|
package/docs/channels/teams.mdx
CHANGED
|
@@ -87,6 +87,12 @@ By default, submissions use the Teams identity of the user who clicked the card.
|
|
|
87
87
|
|
|
88
88
|
When a tool approval settles, eve replaces its Adaptive Card with the outcome and responder name. A response rejected by an approval policy leaves the shared card unchanged.
|
|
89
89
|
|
|
90
|
+
### Connection sign-ins
|
|
91
|
+
|
|
92
|
+
When a connection needs the person to sign in, eve's `authorization.required` handler posts an Adaptive Card. In a personal chat, the card includes the sign-in link and any confirmation code. In group chats and channels, the shared card only says who has to sign in and has a **Sign in** button (`Action.Execute`). When someone presses it, eve resolves who they are the same way it does for HITL submissions (`onInputResponse`). If that's the person who needs to sign in, eve sends back a card with the link and code, and Teams shows that card only to them. Anyone else is told they can't open it. That way another member can't finish the sign-in with their own account and have it saved under the requester's identity.
|
|
93
|
+
|
|
94
|
+
If you customize `onMessage` without also setting `onInputResponse`, nobody can open a sign-in from a group chat or channel, because eve rejects every press.
|
|
95
|
+
|
|
90
96
|
For invokes that aren't HITL, handle them in `onInvoke(ctx, activity)`.
|
|
91
97
|
|
|
92
98
|
### Proactive sessions
|
|
@@ -310,7 +310,7 @@ These tools let the model reach what isn't in its tool list. `eve__search` finds
|
|
|
310
310
|
|
|
311
311
|
Entries the agent declares count from the session's first step. An entry a dynamic resolver returns counts from the step where it first appears, so a resolver in `agent/tools/` that returns only tools without `deferred: true` adds no catalog tools. Once a session's tool list includes a catalog tool, the session keeps it, even after a resolver stops returning the entry that brought it. The catalog tools change only when the session first reaches a new kind of entry, such as its first deferred tool or its first connection.
|
|
312
312
|
|
|
313
|
-
- `eve__search({ query, limit? })` returns the best matches, up to `limit` (default 10, at most 50). `query` is required and must contain a word. A tool match has its exact `tool` name, its `description`, and a TypeScript `signature` rendered from its schemas. A deferred skill's match has its `skill` name, its `description`, and the `path` of its `SKILL.md` when it has supporting files. A result with `tool` is called with `eve__tool`, and one with `skill` is loaded with `eve__skill`. Next to `results`, `searched` counts the entries the query covered, the whole catalog or one namespace, and `remaining` counts the matches past `limit`. A connection behind sign-in counts as its one sign-in result until the user signs in, and an unavailable connection counts as none. Tools and skills rank together, in tiers: an entry whose name is exactly the query, then one whose name after its last `__` is the query, such as `linear__create_issue` or `sre__create_issue` for `create_issue`, then the tools of a connection named by the query, then entries whose names, or names after their last `__`, start with the query, then keyword matches in names, parameters, and descriptions. So `eve__search({ query: "linear" })` lists the `linear` connection's tools first. One-letter and filler words such as `a` and `the` don't count toward keyword matches unless the query has nothing else.
|
|
313
|
+
- `eve__search({ query, limit? })` returns the best matches, up to `limit` (default 10, at most 50). `query` is required and must contain a word. A tool match has its exact `tool` name, its `description`, and a TypeScript `signature` rendered from its schemas. A very long signature drops its property descriptions before any property name. A deferred skill's match has its `skill` name, its `description`, and the `path` of its `SKILL.md` when it has supporting files. A result with `tool` is called with `eve__tool`, and one with `skill` is loaded with `eve__skill`. Next to `results`, `searched` counts the entries the query covered, the whole catalog or one namespace, and `remaining` counts the matches past `limit`. A connection behind sign-in counts as its one sign-in result until the user signs in, and an unavailable connection counts as none. Tools and skills rank together, in tiers: an entry whose name is exactly the query, then one whose name after its last `__` is the query, such as `linear__create_issue` or `sre__create_issue` for `create_issue`, then the tools of a connection named by the query, then entries whose names, or names after their last `__`, start with the query, then keyword matches in names, parameters, and descriptions. So `eve__search({ query: "linear" })` lists the `linear` connection's tools first. One-letter and filler words such as `a` and `the` don't count toward keyword matches unless the query has nothing else.
|
|
314
314
|
- A query whose first word contains `__` searches one namespace: everything before its last `__`, without trailing underscores. The namespace only filters. `eve__search` keeps names under `<namespace>__` and anything named exactly the namespace, such as a connection's sign-in entry, then ranks them by the whole query, so `eve__search({ query: "linear__" })` returns only the `linear` connection's tools, or its sign-in result, and an exact name that contains `__` still ranks first. eve lists only the connections that can own names in that namespace, so other connections make no network call and don't appear in `unavailable`. A namespace that matches nothing fails with the closest connection names. Characters that can't appear in a name, such as a leading `^`, are ignored; `query` isn't a regular expression.
|
|
315
315
|
- `eve__search` never asks the user to sign in. A connection whose server won't list its tools until the user signs in appears as one result named after the connection, such as `linear`; a connection whose server lists its tools without a token is searched like any other. A connection whose tools fail to load, or don't load within 10 seconds, appears under `unavailable` with its `error`, such as `"crm" did not list its tools within 10s. Try again later.` Matches from everything else are still returned, so a slow server doesn't hold up the search. An `eve__tool` call on that connection's tools fails with the same error.
|
|
316
316
|
- `eve__tool({ name: "linear" })`, with a connection's own name, asks the user to sign in to that connection when its tools need it, and returns once they can be listed, so the next `eve__search` finds them. On a server that lists its tools without sign-in, it confirms the tools are available without asking.
|
package/docs/guides/hooks.md
CHANGED
|
@@ -219,6 +219,10 @@ export default defineHook({
|
|
|
219
219
|
|
|
220
220
|
The remaining subscribers for the event still run. Then eve cancels the turn the same way [`session.cancel()`](./client/streaming) does: in-flight model and tool work is aborted, delegated child turns are cancelled, and the turn ends with `turn.cancelled` followed by `session.waiting`. No failure event is emitted. A cancel from `turn.started` or `step.started` takes effect before that model call. In a conversation, the next message starts a new turn. A delegated task reports the cancellation to its caller.
|
|
221
221
|
|
|
222
|
+
A plain-text message that answers a pending question, such as one from `ask_question`, is recorded as `message.received` before eve delivers it. Calling `ctx.cancel()` from that event's hook cancels the turn instead: the question resolves as `cancelled`, and the waiting tool call never receives the text.
|
|
223
|
+
|
|
224
|
+
The same goes for the `action.partial` a workflow tool reports while the turn waits on it: `ctx.cancel()` from its hook cancels the turn, and the run's result never reaches the model.
|
|
225
|
+
|
|
222
226
|
`ctx.cancel()` returns `void` rather than a promise. The turn stops after the hook returns, so there is nothing to await. Call it before the handler's promise settles: eve ignores a call from work the handler does not await and logs a warning.
|
|
223
227
|
|
|
224
228
|
`ctx.cancel()` only stops a running turn. eve logs a warning and ignores the call on `step.failed`, `turn.completed`, `turn.failed`, `turn.cancelled`, `turn.waiting`, `session.waiting`, `session.completed`, `session.failed`, `context.cleared`, `task.started`, `task.settled`, and `agent.started`, and during clear or compact requests.
|
|
@@ -170,6 +170,8 @@ Each call emits one `tool.call.*` lifecycle to authored providers. SDK execution
|
|
|
170
170
|
|
|
171
171
|
For local and remote subagents, `tool.call.completed` and `tool.call.failed` include the child turn's `usage` directly. Token counts are always present when the child reports usage; `usage.costUsd` is present only when the model provider reports a price.
|
|
172
172
|
|
|
173
|
+
When a tool throws and outputs are recorded, `tool.call.failed` carries an `Error` with the thrown error's `name` and `message`, so a provider can classify the failure by `error.name`. It is rebuilt from the durable session record rather than being the object the tool threw, so `instanceof` checks against your own error classes do not match.
|
|
174
|
+
|
|
173
175
|
When upgrading, replace `action.started`, `action.completed`, and `action.failed` handlers with their `tool.call.*` equivalents. Read `event.toolName` instead of `event.name` on start events. The OpenTelemetry trace schema remains version 4.
|
|
174
176
|
|
|
175
177
|
Handlers from different files run concurrently and are failure-isolated. Do
|