@elizaos/agent 2.0.0-alpha.396 → 2.0.0-alpha.398
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/apps/app-steward/src/services/steward-credentials.d.ts.map +1 -1
- package/apps/app-steward/src/services/steward-credentials.js +11 -1
- package/package.json +4 -4
- package/packages/agent/src/triggers/action.d.ts.map +1 -1
- package/packages/agent/src/triggers/action.js +14 -2
- package/packages/app-core/src/api/client-n8n.js +7 -1
- package/packages/app-core/src/components/pages/AutomationsView.d.ts.map +1 -1
- package/packages/app-core/src/components/pages/AutomationsView.js +117 -4
- package/packages/app-core/src/components/pages/WorkflowGraphViewer.d.ts.map +1 -1
- package/packages/app-core/src/components/pages/WorkflowGraphViewer.js +73 -5
- package/packages/app-core/src/components/pages/page-scoped-conversations.js +1 -1
- package/packages/app-core/src/components/workspace/AppWorkspaceChrome.d.ts.map +1 -1
- package/packages/app-core/src/components/workspace/AppWorkspaceChrome.js +17 -4
- package/packages/app-core/src/i18n/locales/en.json +2 -0
- package/packages/shared/src/index.d.ts +0 -2
- package/packages/shared/src/index.d.ts.map +1 -1
- package/packages/shared/src/index.js +6 -5
- package/packages/typescript/src/prompts.d.ts +2 -2
- package/packages/typescript/src/prompts.d.ts.map +1 -1
- package/packages/typescript/src/prompts.js +1 -0
- package/packages/typescript/src/services/message.d.ts.map +1 -1
- package/packages/typescript/src/services/message.js +22 -1
- package/packages/shared/src/eliza-core-roles.d.ts +0 -70
- package/packages/shared/src/eliza-core-roles.d.ts.map +0 -1
- package/packages/shared/src/eliza-core-roles.js +0 -541
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"steward-credentials.d.ts","sourceRoot":"","sources":["../../../../../../../apps/app-steward/src/services/steward-credentials.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;
|
|
1
|
+
{"version":3,"file":"steward-credentials.d.ts","sourceRoot":"","sources":["../../../../../../../apps/app-steward/src/services/steward-credentials.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAmBH,MAAM,WAAW,2BAA2B;IAC1C,MAAM,EAAE,MAAM,CAAC;IACf,QAAQ,EAAE,MAAM,CAAC;IACjB,OAAO,EAAE,MAAM,CAAC;IAChB,MAAM,EAAE,MAAM,CAAC;IACf,UAAU,EAAE,MAAM,CAAC;IACnB,eAAe,CAAC,EAAE;QAChB,GAAG,CAAC,EAAE,MAAM,CAAC;QACb,MAAM,CAAC,EAAE,MAAM,CAAC;KACjB,CAAC;IACF,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,SAAS,CAAC,EAAE,MAAM,CAAC;CACpB;AAQD;;;GAGG;AACH,wBAAgB,sBAAsB,IAAI,2BAA2B,GAAG,IAAI,CAe3E;AAED;;GAEG;AACH,wBAAgB,sBAAsB,CACpC,WAAW,EAAE,2BAA2B,GACvC,IAAI,CAYN;AAED;;;;;GAKG;AACH,wBAAgB,6BAA6B,CAC3C,GAAG,GAAE,MAAM,CAAC,UAAwB,GACnC,2BAA2B,GAAG,IAAI,CA6BpC"}
|
|
@@ -6,8 +6,18 @@
|
|
|
6
6
|
* Environment variables always override file values.
|
|
7
7
|
*/
|
|
8
8
|
import fs from "node:fs";
|
|
9
|
+
import { homedir } from "node:os";
|
|
9
10
|
import path from "node:path";
|
|
10
|
-
|
|
11
|
+
// Inlined to avoid pulling the @elizaos/core source barrel into consumers
|
|
12
|
+
// that only need state-dir resolution (e.g. the Electrobun bun bundle, which
|
|
13
|
+
// would otherwise transitively bundle plugin-sql, transformers, and onnxruntime).
|
|
14
|
+
// Mirrors the canonical implementation in @elizaos/core's
|
|
15
|
+
// src/utils/state-dir.ts: MILADY_STATE_DIR > ELIZA_STATE_DIR > ~/.milady.
|
|
16
|
+
function resolveStateDir() {
|
|
17
|
+
return (process.env.MILADY_STATE_DIR?.trim() ||
|
|
18
|
+
process.env.ELIZA_STATE_DIR?.trim() ||
|
|
19
|
+
path.join(homedir(), ".milady"));
|
|
20
|
+
}
|
|
11
21
|
const CREDENTIALS_FILENAME = "steward-credentials.json";
|
|
12
22
|
function resolveCredentialsPath() {
|
|
13
23
|
return path.join(resolveStateDir(), CREDENTIALS_FILENAME);
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@elizaos/agent",
|
|
3
|
-
"version": "2.0.0-alpha.
|
|
3
|
+
"version": "2.0.0-alpha.398",
|
|
4
4
|
"description": "Standalone elizaOS-based agent and backend server package.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"license": "MIT",
|
|
@@ -467,7 +467,7 @@
|
|
|
467
467
|
"@elizaos/app-steward": "^0.0.0",
|
|
468
468
|
"@elizaos/app-task-coordinator": "^0.0.0",
|
|
469
469
|
"@elizaos/app-training": "^0.0.1",
|
|
470
|
-
"@elizaos/core": "^2.0.0-alpha.
|
|
470
|
+
"@elizaos/core": "^2.0.0-alpha.398",
|
|
471
471
|
"@elizaos/plugin-agent-orchestrator": "^0.6.2-alpha.0",
|
|
472
472
|
"@elizaos/plugin-browser-bridge": "^0.1.0",
|
|
473
473
|
"@elizaos/plugin-local-embedding": "^2.0.0-alpha.12",
|
|
@@ -476,8 +476,8 @@
|
|
|
476
476
|
"@elizaos/plugin-solana": "^2.0.0-alpha.6",
|
|
477
477
|
"@elizaos/plugin-sql": "^2.0.0-alpha.19",
|
|
478
478
|
"@elizaos/plugin-wechat": "^0.1.0",
|
|
479
|
-
"@elizaos/shared": "^2.0.0-alpha.
|
|
480
|
-
"@elizaos/skills": "^2.0.0-alpha.
|
|
479
|
+
"@elizaos/shared": "^2.0.0-alpha.398",
|
|
480
|
+
"@elizaos/skills": "^2.0.0-alpha.398",
|
|
481
481
|
"@hapi/boom": "^10.0.1",
|
|
482
482
|
"@noble/curves": "^2.0.1",
|
|
483
483
|
"@solana/web3.js": "^1.98.4",
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"action.d.ts","sourceRoot":"","sources":["../../../../../src/triggers/action.ts"],"names":[],"mappings":"AACA,OAAO,EACL,KAAK,MAAM,EAWZ,MAAM,eAAe,CAAC;
|
|
1
|
+
{"version":3,"file":"action.d.ts","sourceRoot":"","sources":["../../../../../src/triggers/action.ts"],"names":[],"mappings":"AACA,OAAO,EACL,KAAK,MAAM,EAWZ,MAAM,eAAe,CAAC;AAgIvB,wBAAgB,sBAAsB,CAAC,IAAI,EAAE,MAAM,GAAG,OAAO,CAW5D;AAED,eAAO,MAAM,uBAAuB,EAAE,MAyQrC,CAAC"}
|
|
@@ -82,15 +82,28 @@ function scheduleText(summary) {
|
|
|
82
82
|
}
|
|
83
83
|
return `on cron ${summary.cronExpression ?? "* * * * *"}`;
|
|
84
84
|
}
|
|
85
|
+
const EVERY_N_UNIT_PATTERN = /\bevery\s+\d+\s*(second|minute|hour|day|week|month)s?\b/i;
|
|
85
86
|
export function looksLikeTriggerIntent(text) {
|
|
86
87
|
const trimmed = text.trim();
|
|
87
88
|
if (!trimmed) {
|
|
88
89
|
return false;
|
|
89
90
|
}
|
|
90
|
-
|
|
91
|
+
if (findKeywordTermMatch(trimmed, TRIGGER_INTENT_TERMS) !== undefined) {
|
|
92
|
+
return true;
|
|
93
|
+
}
|
|
94
|
+
return EVERY_N_UNIT_PATTERN.test(trimmed);
|
|
91
95
|
}
|
|
92
96
|
export const createTriggerTaskAction = {
|
|
93
97
|
name: CREATE_TRIGGER_TASK_ACTION,
|
|
98
|
+
// SET_REMINDER is deliberately absent: it collides with LIFE's same simile
|
|
99
|
+
// (life.ts:2499) and LIFE owns the user-facing reminder/alarm concept.
|
|
100
|
+
// CREATE_TRIGGER_TASK is for programmatic scheduled jobs (cron, interval,
|
|
101
|
+
// agent-owned heartbeats), not LifeOps reminders. When both actions share
|
|
102
|
+
// a simile, runtime.processActions (runtime.ts:2400-2440) resolves it via
|
|
103
|
+
// first-match iteration order, so the collision was dispatching user
|
|
104
|
+
// reminder intents to whichever action registered first — a race the
|
|
105
|
+
// planner's validate-time gating cannot override (processActions does not
|
|
106
|
+
// re-validate at dispatch, per runtime.ts:2473).
|
|
94
107
|
similes: [
|
|
95
108
|
"CREATE_TRIGGER",
|
|
96
109
|
"SCHEDULE_TRIGGER",
|
|
@@ -99,7 +112,6 @@ export const createTriggerTaskAction = {
|
|
|
99
112
|
"SCHEDULE_HEARTBEAT",
|
|
100
113
|
"CREATE_AUTOMATION",
|
|
101
114
|
"SCHEDULE_AUTOMATION",
|
|
102
|
-
"SET_REMINDER",
|
|
103
115
|
"CREATE_CRON",
|
|
104
116
|
"CREATE_RECURRING",
|
|
105
117
|
],
|
|
@@ -32,10 +32,16 @@ ElizaClient.prototype.updateN8nWorkflow = async function (id, request) {
|
|
|
32
32
|
});
|
|
33
33
|
};
|
|
34
34
|
ElizaClient.prototype.generateN8nWorkflow = async function (request) {
|
|
35
|
+
// LLM-driven workflow generation runs keyword extraction, node search,
|
|
36
|
+
// generation, multiple correction passes, and feasibility assessment
|
|
37
|
+
// sequentially — easily 30-90s on a cold cache. The 10s default fetch
|
|
38
|
+
// timeout is far too aggressive and surfaces as
|
|
39
|
+
// "Request timed out after 10000ms" in the Automations UI even when
|
|
40
|
+
// the backend would have succeeded a few seconds later.
|
|
35
41
|
return this.fetch("/api/n8n/workflows/generate", {
|
|
36
42
|
method: "POST",
|
|
37
43
|
body: JSON.stringify(request),
|
|
38
|
-
});
|
|
44
|
+
}, { timeoutMs: 120_000 });
|
|
39
45
|
};
|
|
40
46
|
ElizaClient.prototype.activateN8nWorkflow = async function (id) {
|
|
41
47
|
return this.fetch(`/api/n8n/workflows/${encodeURIComponent(id)}/activate`, {
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"AutomationsView.d.ts","sourceRoot":"","sources":["../../../../../../../app-core/src/components/pages/AutomationsView.tsx"],"names":[],"mappings":"AAAA;;GAEG;
|
|
1
|
+
{"version":3,"file":"AutomationsView.d.ts","sourceRoot":"","sources":["../../../../../../../app-core/src/components/pages/AutomationsView.tsx"],"names":[],"mappings":"AAAA;;GAEG;AA+wKH,wBAAgB,eAAe,4CAO9B;AAED,wBAAgB,uBAAuB,4CAoDtC"}
|
|
@@ -534,6 +534,15 @@ function useAutomationsViewController() {
|
|
|
534
534
|
useEffect(() => {
|
|
535
535
|
if (!selectedItemId)
|
|
536
536
|
return;
|
|
537
|
+
// Exempt in-flight workflow drafts — they're not in allItems until
|
|
538
|
+
// generateWorkflowFromPrompt finishes and refreshAutomations
|
|
539
|
+
// surfaces the real workflow. Without this exemption the draft
|
|
540
|
+
// selection gets cleared mid-generation, the auto-select effect
|
|
541
|
+
// below picks lastSelectedIdRef (typically a task like Heartbeat),
|
|
542
|
+
// and the user lands somewhere unexpected — defeating the
|
|
543
|
+
// WorkflowGenerationProgress UI we just added on the draft pane.
|
|
544
|
+
if (selectedItemId.startsWith("workflow-draft:"))
|
|
545
|
+
return;
|
|
537
546
|
if (!allItems.some((item) => item.id === selectedItemId)) {
|
|
538
547
|
setSelectedItemId(null);
|
|
539
548
|
setSelectedItemKind(null);
|
|
@@ -774,7 +783,42 @@ function useAutomationsViewController() {
|
|
|
774
783
|
if (editorOpen || editingId || editingTaskId)
|
|
775
784
|
return null;
|
|
776
785
|
if (selectedItemId) {
|
|
777
|
-
|
|
786
|
+
const found = allItems.find((item) => item.id === selectedItemId);
|
|
787
|
+
if (found)
|
|
788
|
+
return found;
|
|
789
|
+
// In-flight workflow draft (createWorkflowDraft set selectedItemId
|
|
790
|
+
// BEFORE refreshAutomations surfaced the real workflow). Synthesize
|
|
791
|
+
// a minimal draft item so AutomationDraftPane renders with the
|
|
792
|
+
// WorkflowGenerationProgress card during the LLM call.
|
|
793
|
+
//
|
|
794
|
+
// The `room` field is left null here. `activeWorkflowConversation`
|
|
795
|
+
// — the live conversation tied to this draft — lives in
|
|
796
|
+
// AutomationsLayout (a different scope from this controller hook),
|
|
797
|
+
// so we cannot read it from here without a larger refactor.
|
|
798
|
+
// Instead, handleDeleteDraft reads activeWorkflowConversation
|
|
799
|
+
// directly and falls back to it when item.room is missing on a
|
|
800
|
+
// synthesized draft (see the handler below).
|
|
801
|
+
if (selectedItemId.startsWith("workflow-draft:")) {
|
|
802
|
+
const draftId = selectedItemId.slice("workflow-draft:".length);
|
|
803
|
+
const synthesized = {
|
|
804
|
+
id: selectedItemId,
|
|
805
|
+
type: "automation_draft",
|
|
806
|
+
source: "workflow_draft",
|
|
807
|
+
title: "New workflow",
|
|
808
|
+
description: "",
|
|
809
|
+
status: "draft",
|
|
810
|
+
enabled: false,
|
|
811
|
+
system: false,
|
|
812
|
+
isDraft: true,
|
|
813
|
+
hasBackingWorkflow: false,
|
|
814
|
+
updatedAt: null,
|
|
815
|
+
draftId,
|
|
816
|
+
schedules: [],
|
|
817
|
+
room: null,
|
|
818
|
+
};
|
|
819
|
+
return synthesized;
|
|
820
|
+
}
|
|
821
|
+
return null;
|
|
778
822
|
}
|
|
779
823
|
return allItems[0] ?? null;
|
|
780
824
|
}, [allItems, editingId, editingTaskId, editorOpen, selectedItemId]);
|
|
@@ -2216,6 +2260,33 @@ function AutomationsLayout() {
|
|
|
2216
2260
|
try {
|
|
2217
2261
|
await client.deleteN8nWorkflow(item.workflowId);
|
|
2218
2262
|
await Promise.all(item.schedules.map((schedule) => client.deleteTrigger(schedule.id)));
|
|
2263
|
+
// Also delete the chat conversation/room that backed this workflow.
|
|
2264
|
+
// Without this, the `/api/automations` aggregator keeps surfacing the
|
|
2265
|
+
// workflow row as a ghost entry because rooms with workflowId
|
|
2266
|
+
// metadata are listed even when the underlying n8n workflow is gone.
|
|
2267
|
+
const conversationId = item.room?.conversationId;
|
|
2268
|
+
if (conversationId) {
|
|
2269
|
+
try {
|
|
2270
|
+
await client.deleteConversation(conversationId);
|
|
2271
|
+
}
|
|
2272
|
+
catch (roomErr) {
|
|
2273
|
+
// Non-fatal: the workflow itself is deleted; surface the room
|
|
2274
|
+
// failure to the user but don't roll back.
|
|
2275
|
+
setPageNotice(`Workflow deleted, but its chat room could not be removed: ${roomErr instanceof Error ? roomErr.message : String(roomErr)}`);
|
|
2276
|
+
}
|
|
2277
|
+
}
|
|
2278
|
+
if (selectedItemId === item.id) {
|
|
2279
|
+
setSelectedItemId(null);
|
|
2280
|
+
setSelectedItemKind(null);
|
|
2281
|
+
}
|
|
2282
|
+
// Mirror handleDeleteDraft: also clear the active workflow
|
|
2283
|
+
// conversation if it's the one tied to the deleted workflow.
|
|
2284
|
+
// Without this, refreshAutomationsWithDraftBinding keeps receiving
|
|
2285
|
+
// a stale conversation reference on subsequent refreshes.
|
|
2286
|
+
if (conversationId &&
|
|
2287
|
+
activeWorkflowConversation?.id === conversationId) {
|
|
2288
|
+
setActiveWorkflowConversation(null);
|
|
2289
|
+
}
|
|
2219
2290
|
await ctx.refreshAutomations();
|
|
2220
2291
|
}
|
|
2221
2292
|
catch (error) {
|
|
@@ -2228,7 +2299,15 @@ function AutomationsLayout() {
|
|
|
2228
2299
|
finally {
|
|
2229
2300
|
setWorkflowBusyId(null);
|
|
2230
2301
|
}
|
|
2231
|
-
}, [
|
|
2302
|
+
}, [
|
|
2303
|
+
activeWorkflowConversation?.id,
|
|
2304
|
+
ctx,
|
|
2305
|
+
selectedItemId,
|
|
2306
|
+
setActiveWorkflowConversation,
|
|
2307
|
+
setSelectedItemId,
|
|
2308
|
+
setSelectedItemKind,
|
|
2309
|
+
t,
|
|
2310
|
+
]);
|
|
2232
2311
|
const handleDuplicateWorkflow = useCallback(async (item) => {
|
|
2233
2312
|
if (!item.workflowId) {
|
|
2234
2313
|
return;
|
|
@@ -2247,7 +2326,13 @@ function AutomationsLayout() {
|
|
|
2247
2326
|
}
|
|
2248
2327
|
}, [ctx, selectWorkflowById]);
|
|
2249
2328
|
const handleDeleteDraft = useCallback(async (item) => {
|
|
2250
|
-
|
|
2329
|
+
// Synthesized in-flight drafts (workflow-draft:* ids surfaced
|
|
2330
|
+
// before refreshAutomations completes) have no `room` because the
|
|
2331
|
+
// controller's resolvedSelectedItem useMemo can't reach
|
|
2332
|
+
// activeWorkflowConversation from its scope. Fall back to the
|
|
2333
|
+
// live activeWorkflowConversation when item.room is missing —
|
|
2334
|
+
// that's the same conversation the synthesized item represents.
|
|
2335
|
+
const conversationId = item.room?.conversationId ?? activeWorkflowConversation?.id ?? null;
|
|
2251
2336
|
if (!conversationId) {
|
|
2252
2337
|
setPageNotice("This draft is missing its automation room.");
|
|
2253
2338
|
return;
|
|
@@ -2377,5 +2462,33 @@ export function AutomationsView() {
|
|
|
2377
2462
|
}
|
|
2378
2463
|
export function AutomationsDesktopShell() {
|
|
2379
2464
|
const controller = useAutomationsViewController();
|
|
2380
|
-
|
|
2465
|
+
// Collapse the right-rail chat dock when no workflow / draft is
|
|
2466
|
+
// selected. The Automations Overview page already has a centered hero
|
|
2467
|
+
// compose ("Describe a task or workflow…") that's the canonical create
|
|
2468
|
+
// surface; the bottom-right dock + hero showed two inputs at once and
|
|
2469
|
+
// confused users. When a workflow or draft IS selected, the rail (and
|
|
2470
|
+
// its PageScopedChatPane) opens so the user can edit/refine.
|
|
2471
|
+
//
|
|
2472
|
+
// Stay in CONTROLLED mode at all times. An earlier revision flipped
|
|
2473
|
+
// between controlled (when nothing selected) and uncontrolled (when
|
|
2474
|
+
// something selected); that left AppWorkspaceChrome's internal
|
|
2475
|
+
// `internalCollapsed` stuck at `true` after the controlled phase, so
|
|
2476
|
+
// the rail never opened on the first selection. Always-controlled
|
|
2477
|
+
// avoids that transition entirely.
|
|
2478
|
+
const hasScopedItem = controller.resolvedSelectedItem != null;
|
|
2479
|
+
const [userCollapsedWhenSelected, setUserCollapsedWhenSelected] = useState(false);
|
|
2480
|
+
// When the user clears the selection, also reset the toggle so the next
|
|
2481
|
+
// selection starts with the rail open by default.
|
|
2482
|
+
useEffect(() => {
|
|
2483
|
+
if (!hasScopedItem)
|
|
2484
|
+
setUserCollapsedWhenSelected(false);
|
|
2485
|
+
}, [hasScopedItem]);
|
|
2486
|
+
const chatCollapsed = hasScopedItem ? userCollapsedWhenSelected : true;
|
|
2487
|
+
const handleToggleChat = useCallback((next) => {
|
|
2488
|
+
// No-op when nothing is selected — the rail is force-closed in that
|
|
2489
|
+
// state and the toggle button is hidden, so this should never fire.
|
|
2490
|
+
if (hasScopedItem)
|
|
2491
|
+
setUserCollapsedWhenSelected(next);
|
|
2492
|
+
}, [hasScopedItem]);
|
|
2493
|
+
return (_jsx(AutomationsViewContext.Provider, { value: controller, children: _jsx(AppWorkspaceChrome, { testId: "automations-workspace", chat: _jsx(AutomationsSidebarChat, { activeItem: controller.resolvedSelectedItem }), chatCollapsed: chatCollapsed, onToggleChat: handleToggleChat, hideCollapseButton: !hasScopedItem, main: _jsx("div", { className: "flex flex-col flex-1 min-h-0 min-w-0 overflow-hidden", children: _jsx(AutomationsLayout, {}) }) }) }));
|
|
2381
2494
|
}
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"WorkflowGraphViewer.d.ts","sourceRoot":"","sources":["../../../../../../../app-core/src/components/pages/WorkflowGraphViewer.tsx"],"names":[],"mappings":"AA0BA,OAAO,KAAK,EAEV,iBAAiB,EACjB,WAAW,EAEZ,MAAM,6BAA6B,CAAC;
|
|
1
|
+
{"version":3,"file":"WorkflowGraphViewer.d.ts","sourceRoot":"","sources":["../../../../../../../app-core/src/components/pages/WorkflowGraphViewer.tsx"],"names":[],"mappings":"AA0BA,OAAO,KAAK,EAEV,iBAAiB,EACjB,WAAW,EAEZ,MAAM,6BAA6B,CAAC;AAwrBrC,UAAU,wBAAwB;IAChC,QAAQ,EAAE,WAAW,GAAG,IAAI,CAAC;IAC7B,OAAO,CAAC,EAAE,OAAO,CAAC;IAClB,YAAY,CAAC,EAAE,OAAO,CAAC;IACvB,qBAAqB,CAAC,EAAE,MAAM,CAAC;IAC/B,kBAAkB,CAAC,EAAE,MAAM,CAAC;IAC5B,WAAW,CAAC,EAAE,CAAC,QAAQ,EAAE,MAAM,KAAK,IAAI,CAAC;IACzC,kBAAkB,CAAC,EAAE,MAAM,IAAI,CAAC;IAChC,6EAA6E;IAC7E,MAAM,CAAC,EAAE,iBAAiB,GAAG,IAAI,CAAC;CACnC;AAED,wBAAgB,mBAAmB,CAAC,EAClC,QAAQ,EACR,OAAe,EACf,YAAoB,EACpB,qBAAgD,EAChD,kBAAqE,EACrE,WAAW,EACX,kBAAkB,EAClB,MAAM,GACP,EAAE,wBAAwB,2CA+P1B"}
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
import {
|
|
1
|
+
import { jsx as _jsx, jsxs as _jsxs, Fragment as _Fragment } from "react/jsx-runtime";
|
|
2
2
|
import { Button, Dialog, DialogContent, DialogHeader, DialogTitle, Spinner, StatusBadge, } from "@elizaos/ui";
|
|
3
3
|
import { Background, Controls, MiniMap, ReactFlow, } from "@xyflow/react";
|
|
4
4
|
import { ExternalLink, Maximize2, X } from "lucide-react";
|
|
@@ -170,6 +170,77 @@ function graphChrome(uiTheme) {
|
|
|
170
170
|
overlayChipText: "#60a5fa",
|
|
171
171
|
};
|
|
172
172
|
}
|
|
173
|
+
// ── Generation progress overlay ───────────────────────────────────────────────
|
|
174
|
+
/**
|
|
175
|
+
* Stage messages for `WorkflowGenerationProgress`. The plugin's workflow
|
|
176
|
+
* generation today is a single request/response, so the client cannot yet
|
|
177
|
+
* observe the actual stage in real time. We cycle through plausible labels
|
|
178
|
+
* on a fixed timer based on observed median latencies of each phase:
|
|
179
|
+
* 1. extractKeywords (fast — runtime-context provider + keyword LLM call)
|
|
180
|
+
* 2. searchNodes + credential filter + fetchRuntimeContext
|
|
181
|
+
* 3. generateWorkflow (LLM, slowest)
|
|
182
|
+
* 4. validateAndRepair + injectMissingCredentialBlocks
|
|
183
|
+
* 5. deployWorkflow + resolveCredentials + activate
|
|
184
|
+
*
|
|
185
|
+
* When the plugin grows a server-sent-events streaming endpoint, the timer
|
|
186
|
+
* can be replaced with real per-stage progress events.
|
|
187
|
+
*/
|
|
188
|
+
const WORKFLOW_GENERATION_STAGES = [
|
|
189
|
+
{
|
|
190
|
+
label: "Understanding your prompt",
|
|
191
|
+
hint: "Extracting keywords + matching providers",
|
|
192
|
+
startsAt: 0,
|
|
193
|
+
},
|
|
194
|
+
{
|
|
195
|
+
label: "Finding the right nodes",
|
|
196
|
+
hint: "Searching catalog + checking credentials",
|
|
197
|
+
startsAt: 3,
|
|
198
|
+
},
|
|
199
|
+
{
|
|
200
|
+
label: "Generating workflow",
|
|
201
|
+
hint: "Asking the LLM with runtime facts",
|
|
202
|
+
startsAt: 6,
|
|
203
|
+
},
|
|
204
|
+
{
|
|
205
|
+
label: "Validating + repairing",
|
|
206
|
+
hint: "Clamping versions + auto-fixing references",
|
|
207
|
+
startsAt: 18,
|
|
208
|
+
},
|
|
209
|
+
{
|
|
210
|
+
label: "Deploying to n8n",
|
|
211
|
+
hint: "Minting credentials + activating",
|
|
212
|
+
startsAt: 24,
|
|
213
|
+
},
|
|
214
|
+
{
|
|
215
|
+
label: "Almost done",
|
|
216
|
+
hint: "Wrapping up — this is taking a bit longer than usual",
|
|
217
|
+
startsAt: 35,
|
|
218
|
+
},
|
|
219
|
+
];
|
|
220
|
+
function WorkflowGenerationProgress({ chrome, }) {
|
|
221
|
+
const [elapsed, setElapsed] = useState(0);
|
|
222
|
+
useEffect(() => {
|
|
223
|
+
const start = Date.now();
|
|
224
|
+
const id = setInterval(() => {
|
|
225
|
+
setElapsed(Math.floor((Date.now() - start) / 1000));
|
|
226
|
+
}, 500);
|
|
227
|
+
return () => clearInterval(id);
|
|
228
|
+
}, []);
|
|
229
|
+
const currentIndex = WORKFLOW_GENERATION_STAGES.reduce((acc, stage, idx) => (elapsed >= stage.startsAt ? idx : acc), 0);
|
|
230
|
+
return (_jsx("div", { className: "w-full max-w-md rounded-xl border px-5 py-4 text-sm shadow-lg", style: {
|
|
231
|
+
background: chrome.overlayChipBg,
|
|
232
|
+
color: chrome.overlayChipText,
|
|
233
|
+
borderColor: chrome.overlayChipText,
|
|
234
|
+
}, children: _jsxs("div", { className: "flex items-start gap-3", children: [_jsx(Spinner, { className: "mt-0.5 h-4 w-4 shrink-0" }), _jsxs("div", { className: "min-w-0 flex-1 space-y-3", children: [_jsxs("div", { children: [_jsx("div", { className: "font-semibold", children: "Building your workflow\u2026" }), _jsx("div", { className: "text-xs opacity-70", children: "Generations usually take 10\u201330 seconds." })] }), _jsx("ol", { className: "space-y-1.5", children: WORKFLOW_GENERATION_STAGES.map((stage, idx) => {
|
|
235
|
+
const isDone = idx < currentIndex;
|
|
236
|
+
const isActive = idx === currentIndex;
|
|
237
|
+
return (_jsxs("li", { className: `flex items-start gap-2 text-xs transition-opacity ${isDone || isActive ? "opacity-100" : "opacity-40"}`, children: [_jsx("span", { className: `mt-0.5 inline-flex h-3.5 w-3.5 shrink-0 items-center justify-center rounded-full border ${isDone
|
|
238
|
+
? "border-current bg-current/15"
|
|
239
|
+
: isActive
|
|
240
|
+
? "border-current bg-current/15"
|
|
241
|
+
: "border-current/40"}`, "aria-hidden": true, children: isDone ? (_jsx("svg", { viewBox: "0 0 12 12", className: "h-2.5 w-2.5", fill: "none", stroke: "currentColor", strokeWidth: "2", role: "img", "aria-label": "completed", children: _jsx("path", { d: "M2.5 6.5l2.5 2.5 4.5-5", strokeLinecap: "round", strokeLinejoin: "round" }) })) : isActive ? (_jsx("span", { className: "h-1.5 w-1.5 animate-pulse rounded-full bg-current", "aria-hidden": true })) : null }), _jsxs("span", { className: "min-w-0 flex-1", children: [_jsx("span", { className: `font-medium ${isActive ? "" : "opacity-70"}`, children: stage.label }), (isDone || isActive) && (_jsxs("span", { className: "ml-1.5 opacity-60", children: ["\u2014 ", stage.hint] }))] })] }, stage.label));
|
|
242
|
+
}) })] })] }) }));
|
|
243
|
+
}
|
|
173
244
|
// ── Node detail drawer ────────────────────────────────────────────────────────
|
|
174
245
|
const PARAM_TRUNCATE_LENGTH = 200;
|
|
175
246
|
function ParamValue({ value }) {
|
|
@@ -317,10 +388,7 @@ export function WorkflowGraphViewer({ workflow, loading = false, isGenerating =
|
|
|
317
388
|
? "animate-pulse ring-2 ring-blue-500/50"
|
|
318
389
|
: "ring-1 ring-border/30";
|
|
319
390
|
const chrome = graphChrome(uiTheme);
|
|
320
|
-
return (_jsxs(_Fragment, { children: [_jsxs("div", { ref: containerRef, role: "img", "aria-label": ariaLabel, className: `relative overflow-hidden rounded-lg ${borderClass}`, style: { height: 420, background: chrome.canvasBg }, children: [loading && !hasNodes && (_jsx("div", { className: "absolute inset-0 flex items-center justify-center", children: _jsx(Spinner, { className: "h-6 w-6 text-muted" }) })), !loading && !hasNodes && !isGenerating && (_jsxs("div", { className: "absolute inset-0 flex flex-col items-center justify-center gap-3 px-6 text-center", children: [_jsx("p", { className: `text-sm font-medium ${chrome.emptyTitleClass}`, children: "Blank workflow" }), _jsx("p", { className: `max-w-sm text-xs ${chrome.emptyHelpClass}`, children: emptyStateHelpText }), onEmptyStateAction && (_jsx("button", { type: "button", className: "mt-1 rounded-md border border-border/40 bg-bg/40 px-3 py-1.5 text-xs text-txt hover:bg-bg/70 transition-colors", onClick: onEmptyStateAction, children: emptyStateActionLabel }))] })), isGenerating && (_jsx("div", { className: "absolute inset-0 z-10 flex items-center justify-center backdrop-blur-[1px]", style: { background: chrome.overlayBg }, children:
|
|
321
|
-
background: chrome.overlayChipBg,
|
|
322
|
-
color: chrome.overlayChipText,
|
|
323
|
-
}, children: [_jsx(Spinner, { className: "h-4 w-4" }), "Building workflow..."] }) })), !loading && (_jsx("div", { role: "presentation", className: "h-full w-full", onClick: (e) => e.stopPropagation(), onKeyDown: (e) => e.stopPropagation(), children: _jsxs(ReactFlow, { nodes: nodes, edges: isGenerating ? generatingEdges(edges) : edges, nodesDraggable: !isGenerating, nodesConnectable: false, edgesReconnectable: false, onNodeClick: handleNodeClick, fitView: true, fitViewOptions: { padding: 0.2, maxZoom: 1.2 }, proOptions: { hideAttribution: true }, "aria-label": ariaLabel, children: [_jsx(Background, { color: chrome.dots, gap: 20, size: 1 }), _jsx(Controls, { showInteractive: false }), hasNodes && (_jsx(MiniMap, { nodeColor: (n) => {
|
|
391
|
+
return (_jsxs(_Fragment, { children: [_jsxs("div", { ref: containerRef, role: "img", "aria-label": ariaLabel, className: `relative overflow-hidden rounded-lg ${borderClass}`, style: { height: 420, background: chrome.canvasBg }, children: [loading && !hasNodes && (_jsx("div", { className: "absolute inset-0 flex items-center justify-center", children: _jsx(Spinner, { className: "h-6 w-6 text-muted" }) })), !loading && !hasNodes && !isGenerating && (_jsxs("div", { className: "absolute inset-0 flex flex-col items-center justify-center gap-3 px-6 text-center", children: [_jsx("p", { className: `text-sm font-medium ${chrome.emptyTitleClass}`, children: "Blank workflow" }), _jsx("p", { className: `max-w-sm text-xs ${chrome.emptyHelpClass}`, children: emptyStateHelpText }), onEmptyStateAction && (_jsx("button", { type: "button", className: "mt-1 rounded-md border border-border/40 bg-bg/40 px-3 py-1.5 text-xs text-txt hover:bg-bg/70 transition-colors", onClick: onEmptyStateAction, children: emptyStateActionLabel }))] })), isGenerating && (_jsx("div", { className: "absolute inset-0 z-10 flex items-center justify-center backdrop-blur-[1px]", style: { background: chrome.overlayBg }, children: _jsx(WorkflowGenerationProgress, { chrome: chrome }) })), !loading && (_jsx("div", { role: "presentation", className: "h-full w-full", onClick: (e) => e.stopPropagation(), onKeyDown: (e) => e.stopPropagation(), children: _jsxs(ReactFlow, { nodes: nodes, edges: isGenerating ? generatingEdges(edges) : edges, nodesDraggable: !isGenerating, nodesConnectable: false, edgesReconnectable: false, onNodeClick: handleNodeClick, fitView: true, fitViewOptions: { padding: 0.2, maxZoom: 1.2 }, proOptions: { hideAttribution: true }, "aria-label": ariaLabel, children: [_jsx(Background, { color: chrome.dots, gap: 20, size: 1 }), _jsx(Controls, { showInteractive: false }), hasNodes && (_jsx(MiniMap, { nodeColor: (n) => {
|
|
324
392
|
const colors = n.data
|
|
325
393
|
?.colors;
|
|
326
394
|
return colors?.border ?? "#475569";
|
|
@@ -32,7 +32,7 @@ export const PAGE_SCOPE_COPY = {
|
|
|
32
32
|
"page-automations": {
|
|
33
33
|
title: "Automations",
|
|
34
34
|
body: "Use me to create or inspect a task or n8n workflow. Tell me the trigger, timing, and result.",
|
|
35
|
-
systemAddendum: "You are answering inside the Automations view. The user can create tasks and n8n workflows, attach either one to a schedule or event, configure wake mode, max runs, and enabled state, browse templates, inspect existing automations, and troubleshoot failed runs. Treat tasks as simple prompt-driven automations and workflows as multi-step n8n pipelines. Recommend the smaller task shape unless the user clearly needs a multi-step pipeline.
|
|
35
|
+
systemAddendum: "You are answering inside the Automations view. The user can create tasks and n8n workflows, attach either one to a schedule or event, configure wake mode, max runs, and enabled state, browse templates, inspect existing automations, and troubleshoot failed runs. Treat tasks as simple prompt-driven automations and workflows as multi-step n8n pipelines. Recommend the smaller task shape unless the user clearly needs a multi-step pipeline. When the user describes a concrete automation, dispatch it via the planner's <actions> field using <action><name>CREATE_TRIGGER_TASK</name></action> for scheduled or event tasks, or <action><name>MANAGE_TASKS</name></action> for task list operations. Reference live tasks and workflows in context by display name. Never fabricate automation names.",
|
|
36
36
|
},
|
|
37
37
|
"page-apps": {
|
|
38
38
|
title: "Apps chat",
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"AppWorkspaceChrome.d.ts","sourceRoot":"","sources":["../../../../../../../app-core/src/components/workspace/AppWorkspaceChrome.tsx"],"names":[],"mappings":"AAYA,OAAO,EAEL,KAAK,GAAG,EACR,KAAK,SAAS,EAOf,MAAM,OAAO,CAAC;AAGf,OAAO,EAEL,KAAK,uBAAuB,EAC7B,MAAM,gCAAgC,CAAC;AACxC,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,uCAAuC,CAAC;AAEvE,eAAO,MAAM,qCAAqC,wCACX,CAAC;AACxC,eAAO,MAAM,2CAA2C,oCACrB,CAAC;AAOpC,UAAU,kCAAkC;IAC1C,YAAY,EAAE,MAAM,IAAI,CAAC;IACzB,QAAQ,EAAE,MAAM,IAAI,CAAC;IACrB,UAAU,EAAE,OAAO,CAAC;CACrB;AAKD,wBAAgB,yBAAyB,IAAI,kCAAkC,GAAG,IAAI,CAErF;AAED,UAAU,mCAAmC;IAC3C,MAAM,CAAC,EAAE,MAAM,CAAC;CACjB;AAED,wBAAgB,8BAA8B,CAAC,EAC7C,MAAsC,GACvC,EAAE,mCAAmC,GAAG,GAAG,CAAC,OAAO,GAAG,IAAI,CAgB1D;AA0HD,MAAM,WAAW,uBAAuB;IACtC,wDAAwD;IACxD,GAAG,CAAC,EAAE,SAAS,CAAC;IAChB,kCAAkC;IAClC,IAAI,EAAE,SAAS,CAAC;IAChB;;;OAGG;IACH,IAAI,CAAC,EAAE,SAAS,CAAC;IACjB;;;OAGG;IACH,SAAS,CAAC,EAAE,SAAS,CAAC;IACtB;;;OAGG;IACH,uBAAuB,CAAC,EAAE,IAAI,CAC5B,uBAAuB,EACvB,OAAO,GAAG,eAAe,CAC1B,CAAC;IACF;;;OAGG;IACH,aAAa,CAAC,EAAE,OAAO,CAAC;IACxB;;;OAGG;IACH,YAAY,CAAC,EAAE,CAAC,IAAI,EAAE,OAAO,KAAK,IAAI,CAAC;IACvC;;;;OAIG;IACH,oBAAoB,CAAC,EAAE,OAAO,CAAC;IAC/B,gFAAgF;IAChF,kBAAkB,CAAC,EAAE,OAAO,CAAC;IAC7B,gFAAgF;IAChF,YAAY,CAAC,EAAE,OAAO,CAAC;IACvB,+CAA+C;IAC/C,MAAM,CAAC,EAAE,MAAM,CAAC;CACjB;AAyBD,2EAA2E;AAC3E,wBAAgB,kBAAkB,CAAC,EACjC,GAAG,EACH,IAAI,EACJ,IAAI,EACJ,SAAS,EACT,uBAAuB,EACvB,aAAa,EAAE,iBAAiB,EAChC,YAAY,EACZ,oBAA4B,EAC5B,kBAA0B,EAC1B,YAAoB,EACpB,MAA+B,GAChC,EAAE,uBAAuB,GAAG,GAAG,CAAC,OAAO,
|
|
1
|
+
{"version":3,"file":"AppWorkspaceChrome.d.ts","sourceRoot":"","sources":["../../../../../../../app-core/src/components/workspace/AppWorkspaceChrome.tsx"],"names":[],"mappings":"AAYA,OAAO,EAEL,KAAK,GAAG,EACR,KAAK,SAAS,EAOf,MAAM,OAAO,CAAC;AAGf,OAAO,EAEL,KAAK,uBAAuB,EAC7B,MAAM,gCAAgC,CAAC;AACxC,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,uCAAuC,CAAC;AAEvE,eAAO,MAAM,qCAAqC,wCACX,CAAC;AACxC,eAAO,MAAM,2CAA2C,oCACrB,CAAC;AAOpC,UAAU,kCAAkC;IAC1C,YAAY,EAAE,MAAM,IAAI,CAAC;IACzB,QAAQ,EAAE,MAAM,IAAI,CAAC;IACrB,UAAU,EAAE,OAAO,CAAC;CACrB;AAKD,wBAAgB,yBAAyB,IAAI,kCAAkC,GAAG,IAAI,CAErF;AAED,UAAU,mCAAmC;IAC3C,MAAM,CAAC,EAAE,MAAM,CAAC;CACjB;AAED,wBAAgB,8BAA8B,CAAC,EAC7C,MAAsC,GACvC,EAAE,mCAAmC,GAAG,GAAG,CAAC,OAAO,GAAG,IAAI,CAgB1D;AA0HD,MAAM,WAAW,uBAAuB;IACtC,wDAAwD;IACxD,GAAG,CAAC,EAAE,SAAS,CAAC;IAChB,kCAAkC;IAClC,IAAI,EAAE,SAAS,CAAC;IAChB;;;OAGG;IACH,IAAI,CAAC,EAAE,SAAS,CAAC;IACjB;;;OAGG;IACH,SAAS,CAAC,EAAE,SAAS,CAAC;IACtB;;;OAGG;IACH,uBAAuB,CAAC,EAAE,IAAI,CAC5B,uBAAuB,EACvB,OAAO,GAAG,eAAe,CAC1B,CAAC;IACF;;;OAGG;IACH,aAAa,CAAC,EAAE,OAAO,CAAC;IACxB;;;OAGG;IACH,YAAY,CAAC,EAAE,CAAC,IAAI,EAAE,OAAO,KAAK,IAAI,CAAC;IACvC;;;;OAIG;IACH,oBAAoB,CAAC,EAAE,OAAO,CAAC;IAC/B,gFAAgF;IAChF,kBAAkB,CAAC,EAAE,OAAO,CAAC;IAC7B,gFAAgF;IAChF,YAAY,CAAC,EAAE,OAAO,CAAC;IACvB,+CAA+C;IAC/C,MAAM,CAAC,EAAE,MAAM,CAAC;CACjB;AAyBD,2EAA2E;AAC3E,wBAAgB,kBAAkB,CAAC,EACjC,GAAG,EACH,IAAI,EACJ,IAAI,EACJ,SAAS,EACT,uBAAuB,EACvB,aAAa,EAAE,iBAAiB,EAChC,YAAY,EACZ,oBAA4B,EAC5B,kBAA0B,EAC1B,YAAoB,EACpB,MAA+B,GAChC,EAAE,uBAAuB,GAAG,GAAG,CAAC,OAAO,CA6RvC"}
|
|
@@ -79,14 +79,27 @@ export function AppWorkspaceChrome({ nav, main, chat, chatScope, pageScopedChatP
|
|
|
79
79
|
const collapsed = isControlled
|
|
80
80
|
? (chatCollapsedProp ?? false)
|
|
81
81
|
: internalCollapsed;
|
|
82
|
+
// Controlled mode is the source of truth on every viewport — including
|
|
83
|
+
// mobile. When the page passes chatCollapsed=true (e.g. forcing a
|
|
84
|
+
// single canonical compose surface in an empty state), the mobile
|
|
85
|
+
// pane-switcher must respect that and not flip back to open via local
|
|
86
|
+
// mobileChatOpen state.
|
|
82
87
|
const effectiveCollapsed = chatDisabled
|
|
83
88
|
? true
|
|
84
|
-
:
|
|
85
|
-
?
|
|
86
|
-
:
|
|
89
|
+
: isControlled
|
|
90
|
+
? collapsed
|
|
91
|
+
: isMobileViewport
|
|
92
|
+
? !mobileChatOpen
|
|
93
|
+
: collapsed;
|
|
87
94
|
const handleToggle = useCallback((next) => {
|
|
88
95
|
if (isMobileViewport) {
|
|
89
96
|
mobileSidebarControl?.setOpen(false);
|
|
97
|
+
if (isControlled) {
|
|
98
|
+
// Page is the source of truth on mobile too — defer to it
|
|
99
|
+
// instead of touching local mobileChatOpen state.
|
|
100
|
+
onToggleChat?.(next);
|
|
101
|
+
return;
|
|
102
|
+
}
|
|
90
103
|
setMobileChatOpen(chatDisabled ? false : !next);
|
|
91
104
|
return;
|
|
92
105
|
}
|
|
@@ -200,7 +213,7 @@ export function AppWorkspaceChrome({ nav, main, chat, chatScope, pageScopedChatP
|
|
|
200
213
|
const chatContent = chat ??
|
|
201
214
|
(chatScope ? (_jsx(PageScopedChatPane, { ...pageScopedChatPaneProps, scope: chatScope })) : (_jsx(ChatView, { variant: "default" })));
|
|
202
215
|
return (_jsx(WorkspaceMobileSidebarControlsContext.Provider, { value: mobileSidebarControlsValue, children: _jsx(AppWorkspaceChatChromeContext.Provider, { value: chatChromeContextValue, children: _jsxs("div", { className: `flex min-h-0 min-w-0 w-full flex-1 bg-bg pb-[var(--eliza-mobile-nav-offset,0px)] ${isMobileViewport ? "flex-col" : ""}`, "data-testid": testId, children: [isMobileViewport &&
|
|
203
|
-
(!chatDisabled || mobileSidebarControl !== null) ? (_jsx(MobileWorkspacePaneSwitcher, { chatAvailable: !chatDisabled, chatOpen: !effectiveCollapsed, sidebar: mobileSidebarControl, onChat: () => handleToggle(false), onMain: handleOpenMobileMain, onSidebar: handleOpenMobileSidebar })) : null, _jsxs("div", { className: `relative min-h-0 min-w-0 flex-1 flex-col overflow-hidden ${isMobileViewport && !effectiveCollapsed ? "hidden" : "flex"}`, children: [nav, _jsx("div", { className: "relative flex min-h-0 flex-1 flex-col overflow-hidden", children: main })] }), chatDisabled ? null : effectiveCollapsed ? (_jsx("aside", { className: "w-0 min-w-0 shrink-0", "data-testid": `${testId}-chat-sidebar`, "data-collapsed": true, children: isMobileViewport
|
|
216
|
+
(!chatDisabled || mobileSidebarControl !== null) ? (_jsx(MobileWorkspacePaneSwitcher, { chatAvailable: !chatDisabled, chatOpen: !effectiveCollapsed, sidebar: mobileSidebarControl, onChat: () => handleToggle(false), onMain: handleOpenMobileMain, onSidebar: handleOpenMobileSidebar })) : null, _jsxs("div", { className: `relative min-h-0 min-w-0 flex-1 flex-col overflow-hidden ${isMobileViewport && !effectiveCollapsed ? "hidden" : "flex"}`, children: [nav, _jsx("div", { className: "relative flex min-h-0 flex-1 flex-col overflow-hidden", children: main })] }), chatDisabled ? null : effectiveCollapsed ? (_jsx("aside", { className: "w-0 min-w-0 shrink-0", "data-testid": `${testId}-chat-sidebar`, "data-collapsed": true, children: !isMobileViewport && !hideCollapseButton ? (_jsx(AppWorkspaceChatDockToggleButton, { collapsed: true, testId: `${testId}-chat-expand` })) : null })) : (_jsxs(_Fragment, { children: [isMobileViewport ? (_jsx("aside", { className: "flex min-h-0 min-w-0 w-full flex-1 flex-col overflow-hidden bg-bg", "data-testid": `${testId}-chat-sidebar`, children: _jsx("div", { className: "flex min-h-0 flex-1 flex-col overflow-hidden", children: chatContent }) })) : null, !isMobileViewport ? (_jsxs("aside", { className: "relative flex shrink-0 flex-col overflow-hidden bg-bg", style: {
|
|
204
217
|
width: `${chatWidth}px`,
|
|
205
218
|
minWidth: `${chatWidth}px`,
|
|
206
219
|
}, "data-testid": `${testId}-chat-sidebar`, children: [_jsx("hr", { "aria-label": "Resize chat", "aria-orientation": "vertical", "aria-valuemin": 0, "aria-valuemax": 100, "aria-valuenow": 50, tabIndex: 0, "data-testid": `${testId}-chat-resize-handle`, onPointerDown: handleResizePointerDown, className: "absolute inset-y-0 left-0 z-20 m-0 h-full w-3 -translate-x-1/2 cursor-col-resize touch-none select-none border-0 bg-transparent transition-colors hover:bg-accent/20" }), _jsx("div", { className: "flex min-h-0 flex-1 flex-col overflow-hidden", children: chatContent })] })) : null, !isMobileViewport && !hideCollapseButton ? (_jsx(AppWorkspaceChatDockToggleButton, { collapsed: false, testId: `${testId}-chat-collapse` })) : null] }))] }) }) }));
|
|
@@ -135,6 +135,8 @@
|
|
|
135
135
|
"automations.n8n.deleteConfirmMessage": "Permanently delete this workflow. This cannot be undone.",
|
|
136
136
|
"automations.n8n.deleteConfirmWorkflow": "Delete \"{{name}}\"? This cannot be undone.",
|
|
137
137
|
"automations.n8n.deleteFailed": "Failed to delete workflow.",
|
|
138
|
+
"automations.n8n.detailEmptyBody": "Select a workflow from the sidebar to view its details, or switch to the dashboard to create a new one.",
|
|
139
|
+
"automations.n8n.detailEmptyHeading": "No workflow selected",
|
|
138
140
|
"automations.n8n.deleteWorkflow": "Delete workflow",
|
|
139
141
|
"automations.n8n.errorDeleteWorkflow": "Failed to delete workflow: {{message}}",
|
|
140
142
|
"automations.n8n.errorLoadStatus": "Failed to load n8n status: {{message}}",
|
|
@@ -11,8 +11,6 @@ export * from "./connectors";
|
|
|
11
11
|
export * from "./contracts";
|
|
12
12
|
export * from "./dev-settings-banner-style";
|
|
13
13
|
export * from "./dev-settings-table";
|
|
14
|
-
export type { ConnectorAdminWhitelist, RoleCheckResult, RoleGrantSource, RoleName, RolesConfig as ElizaCoreRolesConfig, RolesWorldMetadata, ServerOwnershipState, } from "./eliza-core-roles";
|
|
15
|
-
export { canModifyRole, checkSenderPrivateAccess, checkSenderRole, findWorldsForOwner, getConfiguredOwnerEntityIds, getConnectorAdminWhitelist, getEntityRole, getLiveEntityMetadataFromMessage, getUserServerRole, hasConfiguredCanonicalOwner, matchEntityToConnectorAdminWhitelist, normalizeRole, ROLE_RANK, resolveCanonicalOwnerId, resolveCanonicalOwnerIdForMessage, resolveEntityRole, resolveWorldForMessage, setConnectorAdminWhitelist, setEntityRole, } from "./eliza-core-roles";
|
|
16
14
|
export * from "./env-utils";
|
|
17
15
|
export * from "./onboarding-presets";
|
|
18
16
|
export * from "./onboarding-presets.characters";
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../../../shared/src/index.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAGH,cAAc,gBAAgB,CAAC;AAE/B,cAAc,aAAa,CAAC;AAI5B,YAAY,EACV,YAAY,EACZ,qBAAqB,EACrB,gCAAgC,EAChC,mBAAmB,EACnB,WAAW,EACX,yBAAyB,EACzB,mBAAmB,EACnB,gBAAgB,EAChB,qBAAqB,EACrB,oBAAoB,EACpB,YAAY,EACZ,eAAe,EACf,WAAW,EACX,UAAU,EACV,iBAAiB,EACjB,sBAAsB,EACtB,eAAe,EACf,iBAAiB,EACjB,aAAa,EACb,oBAAoB,EACpB,uBAAuB,EACvB,gBAAgB,EAChB,iBAAiB,EACjB,iBAAiB,EACjB,WAAW,EACX,sBAAsB,EACtB,kBAAkB,EAClB,mBAAmB,EACnB,cAAc,EACd,kBAAkB,EAClB,qBAAqB,EACrB,eAAe,EACf,mBAAmB,EACnB,UAAU,EACV,SAAS,EACT,cAAc,EACd,2BAA2B,EAC3B,iBAAiB,EACjB,qBAAqB,EACrB,eAAe,EACf,WAAW,EACX,eAAe,EACf,gBAAgB,EAChB,4BAA4B,EAC5B,0BAA0B,EAC1B,yBAAyB,EACzB,cAAc,EACd,iBAAiB,EACjB,eAAe,EACf,eAAe,EACf,aAAa,EACb,sBAAsB,EACtB,gCAAgC,EAChC,iBAAiB,EACjB,0BAA0B,EAC1B,0BAA0B,EAC1B,+BAA+B,EAC/B,gCAAgC,EAChC,6BAA6B,EAC7B,kBAAkB,EAClB,mBAAmB,EACnB,iBAAiB,EACjB,mBAAmB,EACnB,sBAAsB,EACtB,oBAAoB,EACpB,gBAAgB,EAChB,UAAU,EACV,iBAAiB,EACjB,iBAAiB,EACjB,gBAAgB,EAChB,oBAAoB,EACpB,WAAW,EACX,gBAAgB,EAChB,uBAAuB,EACvB,yBAAyB,EACzB,qBAAqB,EAErB,oBAAoB,IAAI,iCAAiC,EACzD,gBAAgB,IAAI,6BAA6B,EACjD,yBAAyB,EACzB,mBAAmB,EACnB,eAAe,EACf,eAAe,EACf,eAAe,EACf,aAAa,EACb,mBAAmB,EACnB,iBAAiB,EACjB,gBAAgB,EAChB,mCAAmC,EACnC,4BAA4B,EAC5B,wBAAwB,EACxB,6BAA6B,EAC7B,6BAA6B,EAC7B,4BAA4B,EAC5B,2BAA2B,EAC3B,aAAa,EACb,mBAAmB,EACnB,YAAY,EACZ,eAAe,EACf,kBAAkB,EAClB,qBAAqB,EACrB,sBAAsB,EACtB,qBAAqB,EACrB,kBAAkB,EAClB,cAAc,EACd,QAAQ,EACR,iBAAiB,EACjB,qBAAqB,EACrB,qBAAqB,EACrB,mBAAmB,EACnB,YAAY,EACZ,SAAS,EACT,0BAA0B,EAC1B,cAAc,EACd,iBAAiB,EACjB,mBAAmB,EACnB,YAAY,EACZ,iBAAiB,EACjB,mBAAmB,EACnB,iBAAiB,EACjB,aAAa,EACb,iBAAiB,EACjB,mBAAmB,EACnB,WAAW,EACX,eAAe,EACf,SAAS,EACT,mBAAmB,EACnB,gBAAgB,EAChB,WAAW,EACX,sBAAsB,EACtB,qBAAqB,EACrB,oBAAoB,EACpB,WAAW,EACX,YAAY,EACZ,mBAAmB,EACnB,gBAAgB,EAChB,WAAW,EACX,WAAW,EACX,SAAS,EACT,OAAO,EACP,sBAAsB,EACtB,WAAW,EACX,YAAY,EACZ,SAAS,EACT,kBAAkB,EAClB,UAAU,GACX,MAAM,gBAAgB,CAAC;AACxB,cAAc,cAAc,CAAC;AAK7B,cAAc,aAAa,CAAC;AAC5B,cAAc,6BAA6B,CAAC;AAC5C,cAAc,sBAAsB,CAAC;
|
|
1
|
+
{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../../../shared/src/index.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAGH,cAAc,gBAAgB,CAAC;AAE/B,cAAc,aAAa,CAAC;AAI5B,YAAY,EACV,YAAY,EACZ,qBAAqB,EACrB,gCAAgC,EAChC,mBAAmB,EACnB,WAAW,EACX,yBAAyB,EACzB,mBAAmB,EACnB,gBAAgB,EAChB,qBAAqB,EACrB,oBAAoB,EACpB,YAAY,EACZ,eAAe,EACf,WAAW,EACX,UAAU,EACV,iBAAiB,EACjB,sBAAsB,EACtB,eAAe,EACf,iBAAiB,EACjB,aAAa,EACb,oBAAoB,EACpB,uBAAuB,EACvB,gBAAgB,EAChB,iBAAiB,EACjB,iBAAiB,EACjB,WAAW,EACX,sBAAsB,EACtB,kBAAkB,EAClB,mBAAmB,EACnB,cAAc,EACd,kBAAkB,EAClB,qBAAqB,EACrB,eAAe,EACf,mBAAmB,EACnB,UAAU,EACV,SAAS,EACT,cAAc,EACd,2BAA2B,EAC3B,iBAAiB,EACjB,qBAAqB,EACrB,eAAe,EACf,WAAW,EACX,eAAe,EACf,gBAAgB,EAChB,4BAA4B,EAC5B,0BAA0B,EAC1B,yBAAyB,EACzB,cAAc,EACd,iBAAiB,EACjB,eAAe,EACf,eAAe,EACf,aAAa,EACb,sBAAsB,EACtB,gCAAgC,EAChC,iBAAiB,EACjB,0BAA0B,EAC1B,0BAA0B,EAC1B,+BAA+B,EAC/B,gCAAgC,EAChC,6BAA6B,EAC7B,kBAAkB,EAClB,mBAAmB,EACnB,iBAAiB,EACjB,mBAAmB,EACnB,sBAAsB,EACtB,oBAAoB,EACpB,gBAAgB,EAChB,UAAU,EACV,iBAAiB,EACjB,iBAAiB,EACjB,gBAAgB,EAChB,oBAAoB,EACpB,WAAW,EACX,gBAAgB,EAChB,uBAAuB,EACvB,yBAAyB,EACzB,qBAAqB,EAErB,oBAAoB,IAAI,iCAAiC,EACzD,gBAAgB,IAAI,6BAA6B,EACjD,yBAAyB,EACzB,mBAAmB,EACnB,eAAe,EACf,eAAe,EACf,eAAe,EACf,aAAa,EACb,mBAAmB,EACnB,iBAAiB,EACjB,gBAAgB,EAChB,mCAAmC,EACnC,4BAA4B,EAC5B,wBAAwB,EACxB,6BAA6B,EAC7B,6BAA6B,EAC7B,4BAA4B,EAC5B,2BAA2B,EAC3B,aAAa,EACb,mBAAmB,EACnB,YAAY,EACZ,eAAe,EACf,kBAAkB,EAClB,qBAAqB,EACrB,sBAAsB,EACtB,qBAAqB,EACrB,kBAAkB,EAClB,cAAc,EACd,QAAQ,EACR,iBAAiB,EACjB,qBAAqB,EACrB,qBAAqB,EACrB,mBAAmB,EACnB,YAAY,EACZ,SAAS,EACT,0BAA0B,EAC1B,cAAc,EACd,iBAAiB,EACjB,mBAAmB,EACnB,YAAY,EACZ,iBAAiB,EACjB,mBAAmB,EACnB,iBAAiB,EACjB,aAAa,EACb,iBAAiB,EACjB,mBAAmB,EACnB,WAAW,EACX,eAAe,EACf,SAAS,EACT,mBAAmB,EACnB,gBAAgB,EAChB,WAAW,EACX,sBAAsB,EACtB,qBAAqB,EACrB,oBAAoB,EACpB,WAAW,EACX,YAAY,EACZ,mBAAmB,EACnB,gBAAgB,EAChB,WAAW,EACX,WAAW,EACX,SAAS,EACT,OAAO,EACP,sBAAsB,EACtB,WAAW,EACX,YAAY,EACZ,SAAS,EACT,kBAAkB,EAClB,UAAU,GACX,MAAM,gBAAgB,CAAC;AACxB,cAAc,cAAc,CAAC;AAK7B,cAAc,aAAa,CAAC;AAC5B,cAAc,6BAA6B,CAAC;AAC5C,cAAc,sBAAsB,CAAC;AAOrC,cAAc,aAAa,CAAC;AAC5B,cAAc,sBAAsB,CAAC;AACrC,cAAc,iCAAiC,CAAC;AAChD,cAAc,yBAAyB,CAAC;AACxC,cAAc,WAAW,CAAC;AAC1B,cAAc,eAAe,CAAC;AAE9B,OAAO,EACL,2BAA2B,EAC3B,wBAAwB,EACxB,yBAAyB,GAC1B,MAAM,kBAAkB,CAAC;AAC1B,cAAc,eAAe,CAAC;AAC9B,cAAc,UAAU,CAAC;AACzB,cAAc,eAAe,CAAC;AAC9B,cAAc,uBAAuB,CAAC"}
|
|
@@ -16,11 +16,12 @@ export * from "./connectors";
|
|
|
16
16
|
export * from "./contracts";
|
|
17
17
|
export * from "./dev-settings-banner-style";
|
|
18
18
|
export * from "./dev-settings-table";
|
|
19
|
-
// `eliza-core-roles`
|
|
20
|
-
// `
|
|
21
|
-
//
|
|
22
|
-
//
|
|
23
|
-
|
|
19
|
+
// `eliza-core-roles` is intentionally NOT re-exported from this barrel.
|
|
20
|
+
// It pulls runtime imports (`logger`, `createUniqueUuid`) from `@elizaos/core`,
|
|
21
|
+
// which would drag the entire `@elizaos/core` source graph (plugin-sql,
|
|
22
|
+
// transformers, onnxruntime) into every consumer of `@elizaos/shared`.
|
|
23
|
+
// Callers that need the vendored role helpers must import them through the
|
|
24
|
+
// dedicated subpath: `import { ROLE_RANK } from "@elizaos/shared/eliza-core-roles"`.
|
|
24
25
|
export * from "./env-utils";
|
|
25
26
|
export * from "./onboarding-presets";
|
|
26
27
|
export * from "./onboarding-presets.characters";
|
|
@@ -35,8 +35,8 @@ export declare const longTermExtractionTemplate = "# Task: Extract Long-Term Mem
|
|
|
35
35
|
export declare const LONG_TERM_EXTRACTION_TEMPLATE = "# Task: Extract Long-Term Memory (Strict Criteria)\n\nYou are analyzing a conversation to extract ONLY the most critical, persistent information about the user using cognitive science memory categories.\n\n# Recent Messages\n{{recentMessages}}\n\n# Current Long-Term Memories\n{{existingMemories}}\n\n# Memory Categories (Based on Cognitive Science)\n\n## 1. EPISODIC Memory\nPersonal experiences and specific events with temporal/spatial context.\n**Examples:**\n- \"User completed migration project from MongoDB to PostgreSQL in Q2 2024\"\n- \"User encountered authentication bug in production on March 15th\"\n- \"User had a negative experience with Docker networking in previous job\"\n\n**Requirements:**\n- Must include WHO did WHAT, WHEN/WHERE\n- Must be a specific, concrete event (not a pattern)\n- Must have significant impact or relevance to future work\n\n## 2. SEMANTIC Memory\nGeneral facts, concepts, knowledge, and established truths about the user.\n**Examples:**\n- \"User is a senior backend engineer with 8 years experience\"\n- \"User specializes in distributed systems and microservices architecture\"\n- \"User's primary programming language is TypeScript\"\n- \"User works at Acme Corp as technical lead\"\n\n**Requirements:**\n- Must be factual, timeless information\n- Must be explicitly stated or demonstrated conclusively\n- No speculation or inference from single instances\n- Core identity, expertise, or knowledge only\n\n## 3. PROCEDURAL Memory\nSkills, workflows, methodologies, and how-to knowledge.\n**Examples:**\n- \"User follows strict TDD workflow: write tests first, then implementation\"\n- \"User prefers git rebase over merge to maintain linear history\"\n- \"User's debugging process: check logs \u2192 reproduce locally \u2192 binary search\"\n- \"User always writes JSDoc comments before implementing functions\"\n\n**Requirements:**\n- Must describe HOW user does something\n- Must be a repeated, consistent pattern (seen 3+ times or explicitly stated as standard practice)\n- Must be a workflow, methodology, or skill application\n- Not one-off preferences\n\n# ULTRA-STRICT EXTRACTION CRITERIA\n\n## DO EXTRACT (Only These):\n\n**EPISODIC:**\n- Significant completed projects or milestones\n- Important bugs, incidents, or problems encountered\n- Major decisions made with lasting impact\n- Formative experiences that shape future work\n\n**SEMANTIC:**\n- Professional identity (role, title, company)\n- Core expertise and specializations (stated explicitly or demonstrated conclusively)\n- Primary languages, frameworks, or tools (not exploratory use)\n- Established facts about their work context\n\n**PROCEDURAL:**\n- Consistent workflows demonstrated 3+ times or explicitly stated\n- Standard practices user always follows\n- Methodology preferences with clear rationale\n- Debugging, testing, or development processes\n\n## NEVER EXTRACT:\n\n- **One-time requests or tasks** (e.g., \"can you generate an image\", \"help me debug this\")\n- **Casual conversations** without lasting significance\n- **Exploratory questions** (e.g., \"how does X work?\")\n- **Temporary context** (current bug, today's task)\n- **Preferences from single occurrence** (e.g., user asked for code once)\n- **Social pleasantries** (thank you, greetings)\n- **Testing or experimentation** (trying out a feature)\n- **Common patterns everyone has** (likes clear explanations)\n- **Situational information** (working on feature X today)\n- **Opinions without persistence** (single complaint, isolated praise)\n- **General knowledge** (not specific to user)\n\n# Quality Gates (ALL Must Pass)\n\n1. **Significance Test**: Will this matter in 3+ months?\n2. **Specificity Test**: Is this concrete and actionable?\n3. **Evidence Test**: Is there strong evidence (3+ instances OR explicit self-identification)?\n4. **Uniqueness Test**: Is this specific to THIS user (not generic)?\n5. **Confidence Test**: Confidence must be >= 0.85 (be VERY conservative)\n6. **Non-Redundancy Test**: Does this add NEW information not in existing memories?\n\n# Confidence Scoring (Be Conservative)\n\n- **0.95-1.0**: User explicitly stated as core identity/practice AND demonstrated multiple times\n- **0.85-0.94**: User explicitly stated OR consistently demonstrated 5+ times\n- **0.75-0.84**: Strong pattern (3-4 instances) with supporting context\n- **Below 0.75**: DO NOT EXTRACT (insufficient evidence)\n\n# Critical Instructions\n\n1. **Default to NOT extracting** - When in doubt, skip it\n2. **Require overwhelming evidence** - One or two mentions is NOT enough\n3. **Focus on what's PERSISTENT** - Not what's temporary or situational\n4. **Verify against existing memories** - Don't duplicate or contradict\n5. **Maximum 2-3 extractions per run** - Quality over quantity\n\n**If there are no qualifying facts (which is common), return no memories entries.**\n\n# Response Format\n\nmemories[0]:\n category: semantic\n content: User is a senior TypeScript developer with 8 years of backend experience\n confidence: 0.95\nmemories[1]:\n category: procedural\n content: User follows TDD workflow: writes tests before implementation, runs tests after each change\n confidence: 0.88\nmemories[2]:\n category: episodic\n content: User led database migration from MongoDB to PostgreSQL for payment system in Q2 2024\n confidence: 0.92";
|
|
36
36
|
export declare const messageClassifierTemplate = "Analyze this user request and classify it for planning purposes:\n\n\"{{text}}\"\n\nClassify the request across these dimensions:\n\n1. COMPLEXITY LEVEL:\n- simple: Direct actions that don't require planning\n- medium: Multi-step tasks requiring coordination\n- complex: Strategic initiatives with multiple stakeholders\n- enterprise: Large-scale transformations with full complexity\n\n2. PLANNING TYPE:\n- direct_action: Single action, no planning needed\n- sequential_planning: Multiple steps in sequence\n- strategic_planning: Complex coordination with stakeholders\n\n3. REQUIRED CAPABILITIES:\n- List specific capabilities needed (analysis, communication, project_management, etc.)\n\n4. STAKEHOLDERS:\n- List types of people/groups involved\n\n5. CONSTRAINTS:\n- List limitations or requirements mentioned\n\n6. DEPENDENCIES:\n- List dependencies between tasks or external factors\n\nRespond in this exact format:\nCOMPLEXITY: [simple|medium|complex|enterprise]\nPLANNING: [direct_action|sequential_planning|strategic_planning]\nCAPABILITIES: [comma-separated list]\nSTAKEHOLDERS: [comma-separated list]\nCONSTRAINTS: [comma-separated list]\nDEPENDENCIES: [comma-separated list]\nCONFIDENCE: [0.0-1.0]";
|
|
37
37
|
export declare const MESSAGE_CLASSIFIER_TEMPLATE = "Analyze this user request and classify it for planning purposes:\n\n\"{{text}}\"\n\nClassify the request across these dimensions:\n\n1. COMPLEXITY LEVEL:\n- simple: Direct actions that don't require planning\n- medium: Multi-step tasks requiring coordination\n- complex: Strategic initiatives with multiple stakeholders\n- enterprise: Large-scale transformations with full complexity\n\n2. PLANNING TYPE:\n- direct_action: Single action, no planning needed\n- sequential_planning: Multiple steps in sequence\n- strategic_planning: Complex coordination with stakeholders\n\n3. REQUIRED CAPABILITIES:\n- List specific capabilities needed (analysis, communication, project_management, etc.)\n\n4. STAKEHOLDERS:\n- List types of people/groups involved\n\n5. CONSTRAINTS:\n- List limitations or requirements mentioned\n\n6. DEPENDENCIES:\n- List dependencies between tasks or external factors\n\nRespond in this exact format:\nCOMPLEXITY: [simple|medium|complex|enterprise]\nPLANNING: [direct_action|sequential_planning|strategic_planning]\nCAPABILITIES: [comma-separated list]\nSTAKEHOLDERS: [comma-separated list]\nCONSTRAINTS: [comma-separated list]\nDEPENDENCIES: [comma-separated list]\nCONFIDENCE: [0.0-1.0]";
|
|
38
|
-
export declare const messageHandlerTemplate = "task: Generate dialog and actions for {{agentName}}.\n\ncontext:\n{{providers}}\n\nrules[21]:\n- think briefly, then respond\n- always include a <thought> field, even for direct replies\n- actions execute in listed order\n- if replying without another grounded state/action query, REPLY goes first\n- REPLY means a direct chat reply in the current conversation only; it is not an email reply, inbox workflow, or external-channel send\n- set simple=true only when the planner's text should be sent directly as the final reply without running REPLY again\n- if actions are REPLY-only and you want the REPLY action to generate the final user-facing message, set simple=false\n- use IGNORE or STOP only by themselves\n- include providers only when needed\n- use only action and provider names that appear in the listed runtime surface; never invent new action names, provider names, benchmark ids, or paraphrased tool labels\n- when the user asks about uploaded files, documents, prior uploads, or knowledge-base contents, call the relevant providers before replying instead of asking the user to resend the material\n- when the user refers to \"the uploaded file\", \"the document I uploaded\", or a prior upload without naming it, treat that as a provider lookup request first; only ask which file after grounded document/knowledge lookup still leaves multiple plausible answers\n- use provider_hints from context when present instead of restating the same rules\n- if an action needs inputs, include them inside that action's <params> block\n- if a required param is unknown, ask for clarification in text\n- for live status questions or remaining-work queries, do not answer from recent conversation alone; call the relevant action/provider to refresh state, and do not pair it with a speculative REPLY that guesses the result\n- when an action will fetch the state and produce the final grounded answer, do not add REPLY just to say \"checking\", \"let me look\", or similar filler; use the action alone and leave text empty\n- when the user asks you to create, store, remember, schedule, remind, upload, follow up, route, escalate, or set a standing policy, choose the matching action instead of handling it in prose only\n- for standing or future-condition requests like \"if/when X, do Y\", still choose the action that records, queues, or routes that behavior on the first turn\n- if a matching action can own the task and ask the missing follow-up itself, still select that action and put the clarification in text; do not reply in prose alone\n- when the user defines a durable preference, recurring block, escalation policy, upload policy, approval-gated workflow, or multi-device reminder rule, select the owning action even if some implementation details are still missing\n\t- do not wait for portal names, deck attachments, updated-id uploads, exact flight times, reservation ids, fee-risk item names, priority labels, event IDs, exact travel preferences, or the definition of \"important\" before selecting the owning action; let the action gather those details\n\t- future portal uploads, updated-id interventions, and cancellation-fee warning policies are operational workflows, not prose acknowledgements; choose LIFEOPS_COMPUTER_USE or PUBLISH_DEVICE_INTENT first and let those actions ask the missing follow-up\n\t- for LifeOps create requests with a clear defaultable habit or natural window, such as drinking water, stretch breaks during the day, weekday-after-lunch Invisalign checks, or brushing when waking up and before bed, call LIFE instead of asking for exact clock times unless the user explicitly asks for precise scheduling\n- only choose actions that directly satisfy the user's request or an explicit live-state question; do not opportunistically triage inboxes, summarize calendars, propose meetings, or call adjacent tools just because provider context makes them available\n- when the user is venting, reflecting, stating an opinion, or asking for generic advice about a domain, stay in REPLY or NONE unless they explicitly ask you to inspect state, change state, send something, schedule something, or perform a real operation\n\ncontrol_actions:\n- STOP means the task is done and the agent should end the run without executing more actions\n- STOP is a terminal control action even if it is not listed in available actions\n\nfields[5]{name,meaning}:\n- thought | short plan\n- actions | ordered <action> entries inside <actions>\n- providers | array of provider names, or empty\n- text | next message for {{agentName}}\n- simple | true only when text itself should be sent directly as the final reply; false when actions should run, including REPLY-driven finalization\n\nformatting:\n- wrap multi-line code in fenced code blocks\n- use inline backticks for short code identifiers\n\noutput:\nXML only. Return exactly one <response>...</response> document. No prose before or after it. No <think>.\n\nExample:\n<response>\n <thought>Reply briefly. No extra providers needed.</thought>\n <actions>\n <action>\n <name>REPLY</name>\n </action>\n </actions>\n <providers></providers>\n <text>Your message here</text>\n <simple>true</simple>\n</response>";
|
|
39
|
-
export declare const MESSAGE_HANDLER_TEMPLATE = "task: Generate dialog and actions for {{agentName}}.\n\ncontext:\n{{providers}}\n\nrules[21]:\n- think briefly, then respond\n- always include a <thought> field, even for direct replies\n- actions execute in listed order\n- if replying without another grounded state/action query, REPLY goes first\n- REPLY means a direct chat reply in the current conversation only; it is not an email reply, inbox workflow, or external-channel send\n- set simple=true only when the planner's text should be sent directly as the final reply without running REPLY again\n- if actions are REPLY-only and you want the REPLY action to generate the final user-facing message, set simple=false\n- use IGNORE or STOP only by themselves\n- include providers only when needed\n- use only action and provider names that appear in the listed runtime surface; never invent new action names, provider names, benchmark ids, or paraphrased tool labels\n- when the user asks about uploaded files, documents, prior uploads, or knowledge-base contents, call the relevant providers before replying instead of asking the user to resend the material\n- when the user refers to \"the uploaded file\", \"the document I uploaded\", or a prior upload without naming it, treat that as a provider lookup request first; only ask which file after grounded document/knowledge lookup still leaves multiple plausible answers\n- use provider_hints from context when present instead of restating the same rules\n- if an action needs inputs, include them inside that action's <params> block\n- if a required param is unknown, ask for clarification in text\n- for live status questions or remaining-work queries, do not answer from recent conversation alone; call the relevant action/provider to refresh state, and do not pair it with a speculative REPLY that guesses the result\n- when an action will fetch the state and produce the final grounded answer, do not add REPLY just to say \"checking\", \"let me look\", or similar filler; use the action alone and leave text empty\n- when the user asks you to create, store, remember, schedule, remind, upload, follow up, route, escalate, or set a standing policy, choose the matching action instead of handling it in prose only\n- for standing or future-condition requests like \"if/when X, do Y\", still choose the action that records, queues, or routes that behavior on the first turn\n- if a matching action can own the task and ask the missing follow-up itself, still select that action and put the clarification in text; do not reply in prose alone\n- when the user defines a durable preference, recurring block, escalation policy, upload policy, approval-gated workflow, or multi-device reminder rule, select the owning action even if some implementation details are still missing\n\t- do not wait for portal names, deck attachments, updated-id uploads, exact flight times, reservation ids, fee-risk item names, priority labels, event IDs, exact travel preferences, or the definition of \"important\" before selecting the owning action; let the action gather those details\n\t- future portal uploads, updated-id interventions, and cancellation-fee warning policies are operational workflows, not prose acknowledgements; choose LIFEOPS_COMPUTER_USE or PUBLISH_DEVICE_INTENT first and let those actions ask the missing follow-up\n\t- for LifeOps create requests with a clear defaultable habit or natural window, such as drinking water, stretch breaks during the day, weekday-after-lunch Invisalign checks, or brushing when waking up and before bed, call LIFE instead of asking for exact clock times unless the user explicitly asks for precise scheduling\n- only choose actions that directly satisfy the user's request or an explicit live-state question; do not opportunistically triage inboxes, summarize calendars, propose meetings, or call adjacent tools just because provider context makes them available\n- when the user is venting, reflecting, stating an opinion, or asking for generic advice about a domain, stay in REPLY or NONE unless they explicitly ask you to inspect state, change state, send something, schedule something, or perform a real operation\n\ncontrol_actions:\n- STOP means the task is done and the agent should end the run without executing more actions\n- STOP is a terminal control action even if it is not listed in available actions\n\nfields[5]{name,meaning}:\n- thought | short plan\n- actions | ordered <action> entries inside <actions>\n- providers | array of provider names, or empty\n- text | next message for {{agentName}}\n- simple | true only when text itself should be sent directly as the final reply; false when actions should run, including REPLY-driven finalization\n\nformatting:\n- wrap multi-line code in fenced code blocks\n- use inline backticks for short code identifiers\n\noutput:\nXML only. Return exactly one <response>...</response> document. No prose before or after it. No <think>.\n\nExample:\n<response>\n <thought>Reply briefly. No extra providers needed.</thought>\n <actions>\n <action>\n <name>REPLY</name>\n </action>\n </actions>\n <providers></providers>\n <text>Your message here</text>\n <simple>true</simple>\n</response>";
|
|
38
|
+
export declare const messageHandlerTemplate = "task: Generate dialog and actions for {{agentName}}.\n\ncontext:\n{{providers}}\n\nrules[21]:\n- think briefly, then respond\n- always include a <thought> field, even for direct replies\n- actions execute in listed order\n- if replying without another grounded state/action query, REPLY goes first\n- REPLY means a direct chat reply in the current conversation only; it is not an email reply, inbox workflow, or external-channel send\n- set simple=true only when the planner's text should be sent directly as the final reply without running REPLY again\n- if actions are REPLY-only and you want the REPLY action to generate the final user-facing message, set simple=false\n- use IGNORE or STOP only by themselves\n- include providers only when needed\n- use only action and provider names that appear in the listed runtime surface; never invent new action names, provider names, benchmark ids, or paraphrased tool labels\n- when the user asks about uploaded files, documents, prior uploads, or knowledge-base contents, call the relevant providers before replying instead of asking the user to resend the material\n- when the user refers to \"the uploaded file\", \"the document I uploaded\", or a prior upload without naming it, treat that as a provider lookup request first; only ask which file after grounded document/knowledge lookup still leaves multiple plausible answers\n- use provider_hints from context when present instead of restating the same rules\n- if an action needs inputs, include them inside that action's <params> block\n- if a required param is unknown, ask for clarification in text\n- for live status questions or remaining-work queries, do not answer from recent conversation alone; call the relevant action/provider to refresh state, and do not pair it with a speculative REPLY that guesses the result\n- when an action will fetch the state and produce the final grounded answer, do not add REPLY just to say \"checking\", \"let me look\", or similar filler; use the action alone and leave text empty\n- when the user asks you to create, store, remember, schedule, remind, upload, follow up, route, escalate, or set a standing policy, choose the matching action instead of handling it in prose only\n- when the request names an external integration (Gmail, Discord, Slack, Telegram, GitHub, Google Sheets, Google Calendar, Google Drive, Notion, etc.) AND describes data movement between services or scheduled invocation of an external API, prefer CREATE_N8N_WORKFLOW; reserve CREATE_TRIGGER_TASK for self-driven scheduled prompts to the agent itself with no external API calls\n- for standing or future-condition requests like \"if/when X, do Y\", still choose the action that records, queues, or routes that behavior on the first turn\n- if a matching action can own the task and ask the missing follow-up itself, still select that action and put the clarification in text; do not reply in prose alone\n- when the user defines a durable preference, recurring block, escalation policy, upload policy, approval-gated workflow, or multi-device reminder rule, select the owning action even if some implementation details are still missing\n\t- do not wait for portal names, deck attachments, updated-id uploads, exact flight times, reservation ids, fee-risk item names, priority labels, event IDs, exact travel preferences, or the definition of \"important\" before selecting the owning action; let the action gather those details\n\t- future portal uploads, updated-id interventions, and cancellation-fee warning policies are operational workflows, not prose acknowledgements; choose LIFEOPS_COMPUTER_USE or PUBLISH_DEVICE_INTENT first and let those actions ask the missing follow-up\n\t- for LifeOps create requests with a clear defaultable habit or natural window, such as drinking water, stretch breaks during the day, weekday-after-lunch Invisalign checks, or brushing when waking up and before bed, call LIFE instead of asking for exact clock times unless the user explicitly asks for precise scheduling\n- only choose actions that directly satisfy the user's request or an explicit live-state question; do not opportunistically triage inboxes, summarize calendars, propose meetings, or call adjacent tools just because provider context makes them available\n- when the user is venting, reflecting, stating an opinion, or asking for generic advice about a domain, stay in REPLY or NONE unless they explicitly ask you to inspect state, change state, send something, schedule something, or perform a real operation\n\ncontrol_actions:\n- STOP means the task is done and the agent should end the run without executing more actions\n- STOP is a terminal control action even if it is not listed in available actions\n\nfields[5]{name,meaning}:\n- thought | short plan\n- actions | ordered <action> entries inside <actions>\n- providers | array of provider names, or empty\n- text | next message for {{agentName}}\n- simple | true only when text itself should be sent directly as the final reply; false when actions should run, including REPLY-driven finalization\n\nformatting:\n- wrap multi-line code in fenced code blocks\n- use inline backticks for short code identifiers\n\noutput:\nXML only. Return exactly one <response>...</response> document. No prose before or after it. No <think>.\n\nExample:\n<response>\n <thought>Reply briefly. No extra providers needed.</thought>\n <actions>\n <action>\n <name>REPLY</name>\n </action>\n </actions>\n <providers></providers>\n <text>Your message here</text>\n <simple>true</simple>\n</response>";
|
|
39
|
+
export declare const MESSAGE_HANDLER_TEMPLATE = "task: Generate dialog and actions for {{agentName}}.\n\ncontext:\n{{providers}}\n\nrules[21]:\n- think briefly, then respond\n- always include a <thought> field, even for direct replies\n- actions execute in listed order\n- if replying without another grounded state/action query, REPLY goes first\n- REPLY means a direct chat reply in the current conversation only; it is not an email reply, inbox workflow, or external-channel send\n- set simple=true only when the planner's text should be sent directly as the final reply without running REPLY again\n- if actions are REPLY-only and you want the REPLY action to generate the final user-facing message, set simple=false\n- use IGNORE or STOP only by themselves\n- include providers only when needed\n- use only action and provider names that appear in the listed runtime surface; never invent new action names, provider names, benchmark ids, or paraphrased tool labels\n- when the user asks about uploaded files, documents, prior uploads, or knowledge-base contents, call the relevant providers before replying instead of asking the user to resend the material\n- when the user refers to \"the uploaded file\", \"the document I uploaded\", or a prior upload without naming it, treat that as a provider lookup request first; only ask which file after grounded document/knowledge lookup still leaves multiple plausible answers\n- use provider_hints from context when present instead of restating the same rules\n- if an action needs inputs, include them inside that action's <params> block\n- if a required param is unknown, ask for clarification in text\n- for live status questions or remaining-work queries, do not answer from recent conversation alone; call the relevant action/provider to refresh state, and do not pair it with a speculative REPLY that guesses the result\n- when an action will fetch the state and produce the final grounded answer, do not add REPLY just to say \"checking\", \"let me look\", or similar filler; use the action alone and leave text empty\n- when the user asks you to create, store, remember, schedule, remind, upload, follow up, route, escalate, or set a standing policy, choose the matching action instead of handling it in prose only\n- when the request names an external integration (Gmail, Discord, Slack, Telegram, GitHub, Google Sheets, Google Calendar, Google Drive, Notion, etc.) AND describes data movement between services or scheduled invocation of an external API, prefer CREATE_N8N_WORKFLOW; reserve CREATE_TRIGGER_TASK for self-driven scheduled prompts to the agent itself with no external API calls\n- for standing or future-condition requests like \"if/when X, do Y\", still choose the action that records, queues, or routes that behavior on the first turn\n- if a matching action can own the task and ask the missing follow-up itself, still select that action and put the clarification in text; do not reply in prose alone\n- when the user defines a durable preference, recurring block, escalation policy, upload policy, approval-gated workflow, or multi-device reminder rule, select the owning action even if some implementation details are still missing\n\t- do not wait for portal names, deck attachments, updated-id uploads, exact flight times, reservation ids, fee-risk item names, priority labels, event IDs, exact travel preferences, or the definition of \"important\" before selecting the owning action; let the action gather those details\n\t- future portal uploads, updated-id interventions, and cancellation-fee warning policies are operational workflows, not prose acknowledgements; choose LIFEOPS_COMPUTER_USE or PUBLISH_DEVICE_INTENT first and let those actions ask the missing follow-up\n\t- for LifeOps create requests with a clear defaultable habit or natural window, such as drinking water, stretch breaks during the day, weekday-after-lunch Invisalign checks, or brushing when waking up and before bed, call LIFE instead of asking for exact clock times unless the user explicitly asks for precise scheduling\n- only choose actions that directly satisfy the user's request or an explicit live-state question; do not opportunistically triage inboxes, summarize calendars, propose meetings, or call adjacent tools just because provider context makes them available\n- when the user is venting, reflecting, stating an opinion, or asking for generic advice about a domain, stay in REPLY or NONE unless they explicitly ask you to inspect state, change state, send something, schedule something, or perform a real operation\n\ncontrol_actions:\n- STOP means the task is done and the agent should end the run without executing more actions\n- STOP is a terminal control action even if it is not listed in available actions\n\nfields[5]{name,meaning}:\n- thought | short plan\n- actions | ordered <action> entries inside <actions>\n- providers | array of provider names, or empty\n- text | next message for {{agentName}}\n- simple | true only when text itself should be sent directly as the final reply; false when actions should run, including REPLY-driven finalization\n\nformatting:\n- wrap multi-line code in fenced code blocks\n- use inline backticks for short code identifiers\n\noutput:\nXML only. Return exactly one <response>...</response> document. No prose before or after it. No <think>.\n\nExample:\n<response>\n <thought>Reply briefly. No extra providers needed.</thought>\n <actions>\n <action>\n <name>REPLY</name>\n </action>\n </actions>\n <providers></providers>\n <text>Your message here</text>\n <simple>true</simple>\n</response>";
|
|
40
40
|
export declare const multiStepDecisionTemplate = "Determine the next step the assistant should take in this conversation to help the user reach their goal.\n\n{{recentMessages}}\n\n# Multi-Step Workflow\n\nIn each step, decide:\n\n1. **Which providers (if any)** should be called to gather necessary data.\n2. **Which action (if any)** should be executed after providers return.\n3. Decide whether the task is complete. If so, set `isFinish: true`. Do not select the `REPLY` action; replies are handled separately after task completion.\n\nYou can select **multiple providers** and at most **one action** per step.\n\nUse only action and provider names that appear in the listed runtime surface. Never invent new action names, provider names, benchmark ids, or paraphrased tool labels.\n\nIf the task is fully resolved and no further steps are needed, mark the step as `isFinish: true`.\n\n---\n\n{{actionsWithDescriptions}}\n\n{{providersWithDescriptions}}\n\nThese are the actions or data provider calls that have already been used in this run. Use this to avoid redundancy and guide your next move.\n\n{{actionResults}}\n\nkeys:\n\"thought\" Clearly explain your reasoning for the selected providers and/or action, and how this step contributes to resolving the user's request.\n\"action\" Name of the action to execute after providers return (can be empty if no action is needed).\n\"providers\" List of provider names to call in this step (can be empty if none are needed).\n\"isFinish\" Set to true only if the task is fully complete.\n\n\u26A0\uFE0F IMPORTANT: Do **not** mark the task as `isFinish: true` immediately after calling an action. Wait for the action to complete before deciding the task is finished.\n\noutput:\nthought: Your thought here\naction: ACTION\nproviders[2]: PROVIDER1,PROVIDER2\nisFinish: false";
|
|
41
41
|
export declare const MULTI_STEP_DECISION_TEMPLATE = "Determine the next step the assistant should take in this conversation to help the user reach their goal.\n\n{{recentMessages}}\n\n# Multi-Step Workflow\n\nIn each step, decide:\n\n1. **Which providers (if any)** should be called to gather necessary data.\n2. **Which action (if any)** should be executed after providers return.\n3. Decide whether the task is complete. If so, set `isFinish: true`. Do not select the `REPLY` action; replies are handled separately after task completion.\n\nYou can select **multiple providers** and at most **one action** per step.\n\nUse only action and provider names that appear in the listed runtime surface. Never invent new action names, provider names, benchmark ids, or paraphrased tool labels.\n\nIf the task is fully resolved and no further steps are needed, mark the step as `isFinish: true`.\n\n---\n\n{{actionsWithDescriptions}}\n\n{{providersWithDescriptions}}\n\nThese are the actions or data provider calls that have already been used in this run. Use this to avoid redundancy and guide your next move.\n\n{{actionResults}}\n\nkeys:\n\"thought\" Clearly explain your reasoning for the selected providers and/or action, and how this step contributes to resolving the user's request.\n\"action\" Name of the action to execute after providers return (can be empty if no action is needed).\n\"providers\" List of provider names to call in this step (can be empty if none are needed).\n\"isFinish\" Set to true only if the task is fully complete.\n\n\u26A0\uFE0F IMPORTANT: Do **not** mark the task as `isFinish: true` immediately after calling an action. Wait for the action to complete before deciding the task is finished.\n\noutput:\nthought: Your thought here\naction: ACTION\nproviders[2]: PROVIDER1,PROVIDER2\nisFinish: false";
|
|
42
42
|
export declare const multiStepSummaryTemplate = "Summarize what the assistant has done so far and provide a final response to the user based on the completed steps.\n\n# Context Information\n{{bio}}\n\n---\n\n{{system}}\n\n---\n\n{{messageDirections}}\n\n# Conversation Summary\nBelow is the user's original request and conversation so far:\n{{recentMessages}}\n\n# Execution Trace\nHere are the actions taken by the assistant to fulfill the request:\n{{actionResults}}\n\n# Assistant's Last Reasoning Step\n{{recentMessage}}\n\n# Instructions\n\n - Review the execution trace and last reasoning step carefully\n\n - Your final output MUST be TOON in this format:\noutput:\nthought: Your thought here\ntext: Your final message to the user";
|