@superatomai/sdk-node 0.0.47-mds → 0.0.48-dsp

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/dist/index.d.mts CHANGED
@@ -1,15 +1,1033 @@
1
1
  import { z } from 'zod';
2
2
  import Anthropic from '@anthropic-ai/sdk';
3
3
 
4
+ /**
5
+ * Script Flow Types
6
+ *
7
+ * Defines interfaces for the script-based query architecture:
8
+ * - ScriptRecipe: metadata for matching, validation, and quality tracking
9
+ * - ScriptResult: output from executing a script
10
+ * - ScriptMatch: result from the LLM-based script matcher
11
+ */
12
+
13
+ /**
14
+ * Recipe metadata stored alongside each script.
15
+ * Used for matching, validation, and quality tracking.
16
+ */
17
+ interface ScriptRecipe {
18
+ /** Unique script identifier */
19
+ id: string;
20
+ /** Version number (incremented on regeneration) */
21
+ version: number;
22
+ /** Human-readable name (e.g., "Revenue by Dimension") */
23
+ name: string;
24
+ /** Natural language description of what this script does */
25
+ intentDescription: string;
26
+ /** Keyword tags for quick filtering */
27
+ tags: string[];
28
+ /** Source tool IDs this script queries (e.g., ["mssql-abc123_query"]) */
29
+ sourceIds: string[];
30
+ /** Table names used (for future schema drift detection) */
31
+ tables: string[];
32
+ /** Parameter definitions — what can vary */
33
+ parameters: ScriptParameter[];
34
+ /** The script function body as a string. Loaded from disk (scripts-store/<fileBase>.ts). */
35
+ scriptBody: string;
36
+ /**
37
+ * On-disk filename stem for the body: scripts-store/<fileBase>.ts.
38
+ * Editable in the IDE. Decided at authoring time (slug of `name`, with a
39
+ * short id suffix on collision) and stable across promotion.
40
+ */
41
+ fileBase?: string;
42
+ /** sha256 of the on-disk body — lets the runtime detect manual edits. */
43
+ bodyHash?: string;
44
+ /** Project scope (single-VM deployments may leave this undefined). */
45
+ projectId?: string;
46
+ /** Times this script was used successfully */
47
+ successCount: number;
48
+ /** Times this script failed */
49
+ failureCount: number;
50
+ /** ISO timestamp of last usage */
51
+ lastUsed: string;
52
+ /** Original user question that created this script */
53
+ createdFrom: string;
54
+ /** ISO timestamp */
55
+ createdAt: string;
56
+ /** ISO timestamp */
57
+ updatedAt: string;
58
+ /**
59
+ * `recipe.id` of the parent this script was forked from.
60
+ * Undefined for root scripts (those written from scratch by MainAgent).
61
+ * See backend/docs/SCRIPT-FLOW-FORK-ADAPT.md.
62
+ */
63
+ parentId?: string;
64
+ /** 0 for root scripts; `parent.forkDepth + 1` for forks. Capped at 3. */
65
+ forkDepth?: number;
66
+ /**
67
+ * Brief description of what this fork changed vs its parent
68
+ * (sourced from the matcher's `modificationHint`).
69
+ */
70
+ forkReason?: string;
71
+ /**
72
+ * Validated component specs captured at authoring time. On a tier-high
73
+ * replay these are rebound to fresh queryIds deterministically — no
74
+ * component-generation LLM call, and the rendered columns can't drift from
75
+ * what was validated when the script was authored. Absent on recipes
76
+ * authored before this landed; those fall back to LLM component generation.
77
+ * See backend/docs/SCRIPT-COMPONENT-CONSISTENCY.md.
78
+ */
79
+ components?: ScriptComponentSpec[];
80
+ /**
81
+ * What the user explicitly asked the output to LOOK like, set by a display
82
+ * edit ("show that as a bar chart", "make the bars horizontal").
83
+ *
84
+ * Deliberately SEPARATE from `components`. Those are validated bindings that
85
+ * must be cleared on a data edit — after "break it down by brand" the axis
86
+ * keys are wrong, and after "use the mode" the stored title still says
87
+ * "Average…". A rendering CHOICE, by contrast, is still valid afterwards.
88
+ * Keeping them in one field meant every data edit silently discarded the
89
+ * user's chart type.
90
+ *
91
+ * Fed to the component generator as a hint whenever specs are (re)generated,
92
+ * so the chosen rendering comes back even after the SQL changes.
93
+ */
94
+ displayPreference?: ScriptDisplayPreference;
95
+ /**
96
+ * Lifecycle stage of this recipe on disk.
97
+ * - 'draft': written by MainAgent's write_script during a turn; filtered out
98
+ * of FTS results (status='verified' only) so the matcher never picks it.
99
+ * Filename is suffixed with `turnId` to keep concurrent turns
100
+ * from clobbering each other's drafts.
101
+ * - 'verified': promoted after `execute_script` succeeded; the matcher sees it.
102
+ * Filename drops the turn suffix unless a verified file with
103
+ * the same slug already exists (collision case keeps the suffix).
104
+ *
105
+ * Recipes loaded from disk without this field default to 'verified' so
106
+ * existing scripts keep working unchanged.
107
+ */
108
+ status?: 'draft' | 'verified';
109
+ /**
110
+ * Per-turn unique suffix used for draft filenames (e.g. `1714745623-x9k2`).
111
+ * Set when the draft is saved; carried until the recipe is promoted.
112
+ */
113
+ turnId?: string;
114
+ /**
115
+ * Last execution error captured by `recordDraftError` while the recipe was
116
+ * still a draft. Lets users open the draft .json file and see why it failed
117
+ * without grepping logs. Cleared on promotion to 'verified'.
118
+ */
119
+ lastError?: {
120
+ phase: 'compile' | 'runtime' | 'timeout' | 'ipc';
121
+ message: string;
122
+ at: string;
123
+ attempt: number;
124
+ };
125
+ /** userId who committed the most recent edit (audit trail — recipes are project-scoped). */
126
+ editedBy?: string;
127
+ /** The instruction that produced the current version. */
128
+ editedFrom?: string;
129
+ /**
130
+ * Prior versions, newest last. The body itself is archived on disk as
131
+ * `<fileBase>.v<version>.ts`; this records what changed and who did it.
132
+ */
133
+ history?: ScriptVersionRecord[];
134
+ }
135
+ /**
136
+ * A durable, user-stated rendering choice for a recipe. Survives data edits.
137
+ */
138
+ interface ScriptDisplayPreference {
139
+ /** Component types the user's chosen rendering resolved to, e.g. ["DynamicBarChart"]. */
140
+ componentTypes: string[];
141
+ /** The instruction itself — carries nuance the types can't ("horizontal", "sorted descending"). */
142
+ instruction: string;
143
+ /** ISO timestamp of the display edit that set this. */
144
+ at: string;
145
+ }
146
+ /** One superseded version of a recipe body (see ScriptStore.commitEdit). */
147
+ interface ScriptVersionRecord {
148
+ /** Version number this record superseded (i.e. the OLD version). */
149
+ version: number;
150
+ /** ISO timestamp of the edit that superseded it. */
151
+ at: string;
152
+ /** userId who made the edit, when known. */
153
+ by?: string;
154
+ /** The edit instruction that caused the supersede. */
155
+ instruction?: string;
156
+ /** One-line summary of what changed, for the version picker. */
157
+ changeSummary?: string;
158
+ /** sha256 of the superseded body — pairs with `<fileBase>.v<version>.ts`. */
159
+ bodyHash?: string;
160
+ }
161
+ interface ScriptParameter {
162
+ /** Parameter name (used in script body as params.name) */
163
+ name: string;
164
+ /** Parameter type */
165
+ type: 'string' | 'number' | 'date' | 'date_range' | 'enum' | 'boolean';
166
+ /** Whether this parameter is required */
167
+ required: boolean;
168
+ /** Default value if not provided */
169
+ default?: any;
170
+ /** For enum type — maps user-facing values to internal values */
171
+ enumValues?: Record<string, string>;
172
+ /** Human-readable description (used in the matcher LLM prompt) */
173
+ description: string;
174
+ }
175
+ /**
176
+ * A reusable component binding captured when a script is authored. Stored on
177
+ * the recipe so tier-high replays rebuild components deterministically (rebind
178
+ * to fresh queryIds) instead of re-running the component-picker LLM.
179
+ */
180
+ interface ScriptComponentSpec {
181
+ /** Registered component name (e.g. "DynamicBarChart") — matched against the available component library. */
182
+ componentType: string;
183
+ /** `executedQuery.sourceId` to bind to (e.g. a tool id or 'computed:_final'), 'federation' for a cross-source component, or 'markdown' for a content-only narrative block (no data source). */
184
+ sourceRef: string;
185
+ /** Present only when sourceRef === 'federation' — the DuckDB SQL to re-execute on replay. */
186
+ federationSql?: string;
187
+ /** Present only when sourceRef === 'markdown' — the narrative text to render on replay (markdown has no data source, so its content must be persisted). */
188
+ content?: string;
189
+ title?: string;
190
+ description?: string;
191
+ /** Validated axis/value keys + aggregation — all referencing real columns of the bound source. */
192
+ config: Record<string, any>;
193
+ }
194
+ /**
195
+ * Result from executing a script via ScriptRunner.
196
+ */
197
+ interface ScriptResult {
198
+ /** Whether the script executed successfully */
199
+ success: boolean;
200
+ /** Combined data from all queries */
201
+ data: any[];
202
+ /** Program-generated narrative, when the script exports getAnalysis. */
203
+ analysis?: AnalysisOutput;
204
+ /**
205
+ * getAnalysis threw. `success` stays true — the data is valid, so the caller
206
+ * falls back to LLM prose rather than losing the answer.
207
+ */
208
+ analysisError?: string;
209
+ /** Program-generated component specs, when the script exports getComponents. */
210
+ components?: ScriptComponentSpec[];
211
+ /**
212
+ * getComponents threw or returned a non-array. `success` stays true — the data
213
+ * is valid, so the caller falls back to the recipe's stored specs and then to
214
+ * LLM generation rather than losing the dashboard.
215
+ */
216
+ componentsError?: string;
217
+ /** Individual query results tracked during execution */
218
+ executedQueries: ScriptQueryResult[];
219
+ /** Error message if failed */
220
+ error?: string;
221
+ /**
222
+ * Where in the lifecycle the error occurred. Lets MainAgent's fix-loop
223
+ * decide between "rewrite the whole draft" (compile) and "patch the
224
+ * specific line" (runtime).
225
+ */
226
+ errorPhase?: 'compile' | 'runtime' | 'timeout' | 'ipc';
227
+ /** Total execution time in milliseconds */
228
+ executionTimeMs: number;
229
+ }
230
+ /**
231
+ * A single query executed during script runtime.
232
+ * Tracked by ScriptContext for component generation and debugging.
233
+ */
234
+ interface ScriptQueryResult {
235
+ /** Source tool ID */
236
+ sourceId: string;
237
+ /** Human-readable source name */
238
+ sourceName: string;
239
+ /** The SQL that was executed */
240
+ sql: string;
241
+ /** Result data rows */
242
+ data: any[];
243
+ /** Number of rows returned */
244
+ count: number;
245
+ /** Total rows that matched before limit (if available) */
246
+ totalCount?: number;
247
+ /** Query execution time in milliseconds */
248
+ executionTimeMs: number;
249
+ /**
250
+ * True for rows that did NOT come from a real SQL execution — either a
251
+ * ctx.emit() dataset or the synthesized "computed:_final" entry that
252
+ * carries the script's post-JS returned data. The component generator
253
+ * uses this to route the resulting component through the script_dataset
254
+ * sentinel toolId so the frontend resolves it via the queryCache short-circuit.
255
+ */
256
+ virtual?: boolean;
257
+ }
258
+ /**
259
+ * Match tier returned by the LLM script matcher.
260
+ *
261
+ * - 'high': the script answers the question directly; only parameter values
262
+ * may differ. The runtime replays it with extracted params (cheapest path).
263
+ * - 'near': the script answers a STRUCTURALLY similar question but needs
264
+ * body modification (different metric, dimension, table, filter shape).
265
+ * The runtime forks the parent and adapts the body via MainAgent's normal
266
+ * write_script + execute_script loop — no SourceAgent dispatch needed.
267
+ * See backend/docs/SCRIPT-FLOW-FORK-ADAPT.md for the full design.
268
+ * - 'edit': the user is INSTRUCTING a change to the script that produced the
269
+ * previous answer (not asking a new question). Only reachable when the turn
270
+ * carries a ScriptBinding — without one the matcher coerces it to 'none', so
271
+ * a prompt regression can't turn this into a loose similarity path. The
272
+ * runtime runs MainAgent in edit mode and commits the result in place.
273
+ * See backend/docs/SCRIPT-EDIT-DESIGN.md.
274
+ * - 'none': no script is relevant; full agent flow runs.
275
+ */
276
+ type MatchTier = 'high' | 'near' | 'edit' | 'none';
277
+ /**
278
+ * Which recipe produced the answer the user is currently looking at.
279
+ *
280
+ * Set whenever a turn's answer came from a script (replay, fresh authoring, or
281
+ * a committed edit) and carried on the UIBlock + saved conversation row. Two
282
+ * consumers:
283
+ * 1. The matcher — the 'edit' tier is ONLY reachable when a binding exists, so
284
+ * "use mode instead of mean" resolves to a concrete script instead of being
285
+ * matched on keywords it shares with no script name.
286
+ * 2. Cache invalidation — after an edit commits, conversations bound to that
287
+ * recipeId must be dropped, or the exact-match cache replays the pre-edit
288
+ * answer and the edit looks like a no-op.
289
+ *
290
+ * See backend/docs/SCRIPT-EDIT-DESIGN.md § Component 1.
291
+ */
292
+ interface ScriptBinding {
293
+ recipeId: string;
294
+ /** Params the script ran with — the edit's starting point. */
295
+ params: Record<string, any>;
296
+ /** Recipe name at bind time (matcher catalog + user-facing confirmation). */
297
+ name: string;
298
+ /** Columns the last run returned — grounds the editor without a re-query. */
299
+ columns?: string[];
300
+ /**
301
+ * The question that produced this answer. Required for disambiguation when a
302
+ * thread ran several scripts — without it the candidates are just names and
303
+ * the matcher cannot resolve "use the mode for the WSP one".
304
+ */
305
+ userPrompt?: string;
306
+ }
307
+ /**
308
+ * Result from the LLM-based script matcher.
309
+ *
310
+ * For `tier: 'high'`, `extractedParams` carries the values to pass to the
311
+ * existing script. For `tier: 'near'`, `gaps` and `modificationHint` describe
312
+ * what the fork-author needs to change in the parent body.
313
+ */
314
+ interface ScriptMatch {
315
+ /** The matched script recipe */
316
+ recipe: ScriptRecipe;
317
+ /** Match tier — see MatchTier docs */
318
+ tier: MatchTier;
319
+ /** Similarity score (0-1, derived from LLM tier) */
320
+ similarity: number;
321
+ /**
322
+ * Legacy confidence level. Mirrors `tier === 'high'`/`'near'` for now;
323
+ * kept so existing callers compile while we migrate to tier-based logic.
324
+ */
325
+ confidence: 'high' | 'medium';
326
+ /** Parameters extracted from the user question by the LLM (tier='high') */
327
+ extractedParams?: Record<string, any>;
328
+ /**
329
+ * Proper nouns the question named, VERBATIM, with the parameter each fills.
330
+ *
331
+ * The matcher must NOT resolve these itself. Observed live: it substituted the
332
+ * customer name "PREMER ENRGES PHOTOOTAIC" into an id parameter believing that
333
+ * "the runtime will resolve the customer name to its PartyId(s)" — nothing on
334
+ * the replay path does, and `WHERE BillingPartyId IN (PREMER ENRGES
335
+ * PHOTOOTAIC)` reached SQL. Reported here, the runtime resolves them before
336
+ * replay and rejects the match when one cannot be resolved.
337
+ */
338
+ mentions?: Array<{
339
+ text: string;
340
+ param?: string;
341
+ }>;
342
+ /** Business concepts the question relies on (e.g. "outstanding balance"). */
343
+ entityTypes?: string[];
344
+ /** What the user question needs that the parent doesn't cover (tier='near') */
345
+ gaps?: string[];
346
+ /** One-sentence description of the change the fork-author should make (tier='near') */
347
+ modificationHint?: string;
348
+ /**
349
+ * Which HALF of the recipe the edit targets (tier='edit'). A recipe has two
350
+ * independently editable halves:
351
+ * - 'data' — the scriptBody: how the rows are produced (aggregation,
352
+ * filters, joins, grouping). Runs MainAgent in edit mode.
353
+ * - 'display' — the component specs: how those SAME rows are shown (chart
354
+ * type, orientation, columns, labels). Replays the proven SQL
355
+ * and regenerates the specs — never authors a script.
356
+ * Defaults to 'data' when the matcher omits it.
357
+ */
358
+ editTarget?: 'data' | 'display';
359
+ /**
360
+ * Self-contained restatement of the change the user asked for (tier='edit').
361
+ * MUST have pronouns/deixis resolved ("this", "it", "that column") — the edit
362
+ * prompt never sees the conversation history, so an unresolved instruction is
363
+ * unusable downstream.
364
+ */
365
+ editInstruction?: string;
366
+ /** Why the matcher made this choice (for logs and telemetry) */
367
+ reasoning?: string;
368
+ }
369
+
370
+ /**
371
+ * script-ipc.ts — Protocol definitions for parent/child IPC.
372
+ *
373
+ * Transport: newline-delimited JSON over the child's stdin/stdout.
374
+ * stderr is passed through for uncaught exceptions and compile errors.
375
+ *
376
+ * See backend/docs/SCRIPT-FLOW-IMPLEMENTATION.md § IPC Bridge.
377
+ */
378
+
379
+ /**
380
+ * What getAnalysis returns. `analysis` is the narrative and `summary` the short
381
+ * bullets the markdown block binds to — siblings over one dataset, never a
382
+ * summary OF the narrative. See backend/docs/ANALYSIS-AS-PROGRAM-DESIGN.md § 4.3.
383
+ */
384
+ interface AnalysisOutput {
385
+ analysis?: string;
386
+ summary?: string[];
387
+ method?: string;
388
+ }
389
+
390
+ /**
391
+ * StreamBuffer - Buffered streaming utility for smoother text delivery
392
+ * Batches small chunks together and flushes at regular intervals
393
+ */
394
+ type StreamCallback = (chunk: string) => void;
395
+ /**
396
+ * StreamBuffer class for managing buffered streaming output
397
+ * Provides smooth text delivery by batching small chunks
398
+ */
399
+ declare class StreamBuffer {
400
+ private buffer;
401
+ private flushTimer;
402
+ private callback;
403
+ private fullText;
404
+ constructor(callback?: StreamCallback);
405
+ /**
406
+ * Check if the buffer has a callback configured
407
+ */
408
+ hasCallback(): boolean;
409
+ /**
410
+ * Get all text that has been written (including already flushed)
411
+ */
412
+ getFullText(): string;
413
+ /**
414
+ * Write a chunk to the buffer
415
+ * Large chunks or chunks with newlines are flushed immediately
416
+ * Small chunks are batched and flushed after a short interval
417
+ *
418
+ * @param chunk - Text chunk to write
419
+ */
420
+ write(chunk: string): void;
421
+ /**
422
+ * Flush the buffer immediately
423
+ * Call this before tool execution or other operations that need clean output
424
+ */
425
+ flush(): void;
426
+ /**
427
+ * Internal flush implementation
428
+ */
429
+ private flushNow;
430
+ /**
431
+ * Clean up resources
432
+ * Call this when done with the buffer
433
+ */
434
+ dispose(): void;
435
+ }
436
+
437
+ /**
438
+ * ToolExecutorService - Handles execution of SQL queries and external tools
439
+ * Extracted from BaseLLM.generateTextResponse for better separation of concerns
440
+ */
441
+
442
+ /**
443
+ * External tool definition
444
+ */
445
+ interface ExternalTool {
446
+ id: string;
447
+ name: string;
448
+ description?: string;
449
+ /** Tool type: "source" = routed through SourceAgent, "direct" = called directly by MainAgent */
450
+ toolType?: 'source' | 'direct';
451
+ /** Full untruncated schema for source agent (all columns visible) */
452
+ fullSchema?: string;
453
+ /** Schema size tier: small (≤50 tables), medium (51-200), large (201-500), very_large (500+) */
454
+ schemaTier?: string;
455
+ /** Schema search function for very_large tier — keyword search over entities */
456
+ schemaSearchFn?: (keywords: string[]) => string;
457
+ /** `signal` fires when the user hits Stop mid-query — passed through to the backend's SourceTool.fn. */
458
+ fn: (input: any, signal?: AbortSignal) => Promise<any>;
459
+ limit?: number;
460
+ outputSchema?: any;
461
+ executionType?: 'immediate' | 'deferred';
462
+ userProvidedData?: any;
463
+ params?: Record<string, any>;
464
+ }
465
+ /**
466
+ * Executed tool tracking info
467
+ */
468
+ interface ExecutedToolInfo {
469
+ id: string;
470
+ name: string;
471
+ params: any;
472
+ result: {
473
+ _totalRecords: number;
474
+ _recordsShown: number;
475
+ _metadata?: any;
476
+ _sampleData: any[];
477
+ /** Bounded summary over the FULL fetched result (complete structure). */
478
+ _summary?: any;
479
+ /** Up to MAIN_AGENT_COMPLETE_ROWS rows — the complete result when small. */
480
+ _mainAgentRows?: any[];
481
+ };
482
+ outputSchema?: any;
483
+ sourceSchema?: string;
484
+ sourceType?: string;
485
+ }
486
+
487
+ /**
488
+ * Multi-Agent Architecture Types
489
+ *
490
+ * Defines interfaces for the hierarchical agent system:
491
+ * - Main Agent: ONE LLM.streamWithTools() call with source agent tools
492
+ * - Source Agents: independent agents that query individual data sources
493
+ *
494
+ * The main agent sees only source summaries. When it calls a source tool,
495
+ * the SourceAgent runs independently (own LLM, own retries) and returns clean data.
496
+ */
497
+
498
+ /**
499
+ * Per-entity detail: name, row count, and column names.
500
+ * Gives the main agent enough context to route to the right source.
501
+ */
502
+ interface EntityDetail {
503
+ /** Entity name (table, sheet, endpoint) */
504
+ name: string;
505
+ /** Approximate row count */
506
+ rowCount?: number;
507
+ /** Column/field names */
508
+ columns: string[];
509
+ /** Entity-level semantic summary (what the table means) — for main-agent routing. */
510
+ summary?: string;
511
+ }
512
+ /**
513
+ * Representation of a data source for the main agent.
514
+ * Contains entity names WITH column names so the LLM can route accurately.
515
+ */
516
+ interface SourceSummary {
517
+ /** Source ID (matches tool ID prefix) */
518
+ id: string;
519
+ /** Human-readable source name */
520
+ name: string;
521
+ /** Source type: postgres, excel, rest_api, etc. */
522
+ type: string;
523
+ /** Brief description of what data this source contains */
524
+ description: string;
525
+ /** Detailed entity info with column names for routing */
526
+ entityDetails: EntityDetail[];
527
+ /** The tool ID associated with this source */
528
+ toolId: string;
529
+ }
530
+ /**
531
+ * What a source agent returns after querying its data source.
532
+ * The main agent uses this to analyze and compose the final response.
533
+ */
534
+ interface SourceAgentResult {
535
+ /** Source ID */
536
+ sourceId: string;
537
+ /** Source name */
538
+ sourceName: string;
539
+ /** Whether the query succeeded */
540
+ success: boolean;
541
+ /** Result data rows */
542
+ data: any[];
543
+ /** Metadata about the query execution */
544
+ metadata: SourceAgentMetadata;
545
+ /** Tool execution info for the last successful query (backward compat) */
546
+ executedTool: ExecutedToolInfo;
547
+ /** All successful tool executions (primary + follow-up queries) */
548
+ allExecutedTools?: ExecutedToolInfo[];
549
+ /** Error message if failed */
550
+ error?: string;
551
+ }
552
+ interface SourceAgentMetadata {
553
+ /** Total rows that matched the query (before limit) */
554
+ totalRowsMatched: number;
555
+ /** Rows actually returned (after limit) */
556
+ rowsReturned: number;
557
+ /** Whether the result was truncated by the row limit */
558
+ isLimited: boolean;
559
+ /** The query/params that were executed */
560
+ queryExecuted?: string;
561
+ /** Execution time in milliseconds */
562
+ executionTimeMs: number;
563
+ }
564
+ /**
565
+ * A pre-built, multi-step UI flow registered with the SDK.
566
+ *
567
+ * When the main agent decides a user's question matches a workflow's whenToUse
568
+ * trigger, it picks the workflow instead of running source agents / generating
569
+ * dashboard components. The LLM extracts the workflow's required props from the
570
+ * prompt (using `propsSchema` as the tool input_schema) and the SDK returns the
571
+ * workflow component directly — no analysis text, no chart generation. The
572
+ * frontend renders the registered workflow component with the LLM-extracted
573
+ * props.
574
+ */
575
+ interface WorkflowDescriptor {
576
+ /** Unique workflow id (used as the LLM tool name) */
577
+ id: string;
578
+ /** Component name on the frontend (matches the registered React component) */
579
+ name: string;
580
+ /** Short human-readable description of what this workflow does */
581
+ description: string;
582
+ /**
583
+ * 1–2 sentence trigger condition. The LLM uses this to decide if the
584
+ * user's prompt matches this workflow. Be specific — e.g.
585
+ * "User wants to *initiate* an inventory transfer (review + submit POs),
586
+ * not just see analysis or charts."
587
+ */
588
+ whenToUse: string;
589
+ /**
590
+ * JSON-schema-style description of the props the workflow needs. Becomes
591
+ * the LLM tool's input_schema, so the model fills these from the prompt.
592
+ * Use the same shape as `params` on direct tools — string descriptors with
593
+ * an optional "(optional)" suffix.
594
+ *
595
+ * Example:
596
+ * ```
597
+ * {
598
+ * selectedStore: 'object — { id, name } of the source branch',
599
+ * minROI: 'number (optional) — only show transfers with ROI ≥ this',
600
+ * }
601
+ * ```
602
+ */
603
+ propsSchema: Record<string, string>;
604
+ /**
605
+ * Optional: static prop defaults merged with LLM-extracted props before
606
+ * the component is returned. Useful for things like the embedded
607
+ * `externalTool` config that the workflow uses to fetch its own data.
608
+ */
609
+ defaultProps?: Record<string, any>;
610
+ }
611
+ /**
612
+ * The workflow selection captured during a routing call.
613
+ * Set on AgentResponse when the LLM picks a workflow tool.
614
+ */
615
+ interface SelectedWorkflow {
616
+ /** Component name (matches WorkflowDescriptor.name) */
617
+ name: string;
618
+ /** Props extracted from the prompt + merged with workflow.defaultProps */
619
+ props: Record<string, any>;
620
+ }
621
+ /**
622
+ * Set when this turn applies a user-directed edit to an existing script instead
623
+ * of authoring a new one. MainAgent keeps the SAME harness (tools, loop,
624
+ * write_script/execute_script verification) and swaps only the system prompt —
625
+ * `agent-main-edit` instead of `agent-main`.
626
+ *
627
+ * The two framings contradict each other on whether to query a source first, so
628
+ * they must never be resident in one rendered prompt.
629
+ * See backend/docs/SCRIPT-EDIT-DESIGN.md § D3.
630
+ */
631
+ interface EditContext {
632
+ /** Recipe being edited — the shadow draft records it as parentId. */
633
+ recipeId: string;
634
+ parentName: string;
635
+ parentBody: string;
636
+ /** Self-contained restatement of the change (from the matcher). */
637
+ instruction: string;
638
+ /** Columns the last run returned — grounds the edit without a re-query. */
639
+ lastResultColumns?: string[];
640
+ /** Rendered parameter list of the parent, for the prompt. */
641
+ parentParams?: string;
642
+ }
643
+ /**
644
+ * The complete response from the multi-agent system.
645
+ * Contains everything needed for text display + component generation.
646
+ */
647
+ interface AgentResponse {
648
+ /** Generated text response (analysis of the data) */
649
+ text: string;
650
+ /**
651
+ * Program-generated narrative when the script exported getAnalysis. `text`
652
+ * already carries `analysis.analysis`; this also exposes `summary`, which
653
+ * the markdown block binds to instead of being an LLM summary of the prose.
654
+ */
655
+ analysis?: AnalysisOutput;
656
+ /** All executed tools across all source agents (for component generation) */
657
+ executedTools: ExecutedToolInfo[];
658
+ /** Individual results from each source agent */
659
+ sourceResults: SourceAgentResult[];
660
+ /**
661
+ * Populated when MainAgent wrote AND successfully executed a script during its turn.
662
+ * Caller (agent-user-response.ts) persists it via ScriptStore.save().
663
+ * Absent when MainAgent didn't write one (trivial question / all attempts failed).
664
+ */
665
+ savedScript?: AgentWrittenScript;
666
+ /** Failed execute_script tool_result texts this turn, in order — see RunTrace.script.failedAttempts. */
667
+ failedScriptAttempts?: string[];
668
+ /**
669
+ * Set when the LLM routed the question to a registered workflow component.
670
+ * When present, the upstream caller should skip component generation and
671
+ * return this workflow as the response.
672
+ */
673
+ workflow?: SelectedWorkflow;
674
+ /**
675
+ * Validated component specs the agent authored via `write_components`.
676
+ * When present the caller assembles the dashboard from these instead of
677
+ * running the component-generation LLM. Absent when the agent didn't call
678
+ * the tool — the caller then falls back to `generateScriptComponents`.
679
+ * See backend/docs/COMPONENT-GENERATION-V2.md §2.2.
680
+ */
681
+ componentSpecs?: ScriptComponentSpec[];
682
+ /** Layout title/description from the same `write_components` call. */
683
+ componentLayout?: {
684
+ title: string;
685
+ description?: string;
686
+ };
687
+ }
688
+ /**
689
+ * A script MainAgent authored + verified during its turn. Shape aligns with
690
+ * what ScriptStore.save() needs — minus store-assigned fields (id, timestamps, counts).
691
+ */
692
+ interface AgentWrittenScript {
693
+ /**
694
+ * `ScriptRecipe.id` of the draft that was authored + verified during this turn.
695
+ * The caller passes this to `ScriptStore.promoteToVerified(recipeId, …)` to
696
+ * flip the draft to verified status and (when possible) drop the turn-suffix
697
+ * from its filename.
698
+ */
699
+ recipeId: string;
700
+ name: string;
701
+ intentDescription: string;
702
+ tags: string[];
703
+ parameters: Array<{
704
+ name: string;
705
+ type: 'string' | 'number' | 'date' | 'date_range' | 'enum' | 'boolean';
706
+ required: boolean;
707
+ default?: any;
708
+ enumValues?: Record<string, string>;
709
+ description: string;
710
+ }>;
711
+ scriptBody: string;
712
+ /** Source IDs referenced by the script (extracted from ctx.query calls) */
713
+ sourceIds: string[];
714
+ /** Tables referenced in the script's SQL (regex-extracted) */
715
+ tables: string[];
716
+ /** Executed queries from the verified run — fed to component generation */
717
+ executedQueries: Array<{
718
+ sourceId: string;
719
+ sourceName: string;
720
+ sql: string;
721
+ data: any[];
722
+ count: number;
723
+ totalCount?: number;
724
+ executionTimeMs: number;
725
+ /**
726
+ * True for synthetic entries (ctx.emit datasets, the computed:_final
727
+ * post-JS data). The component generator routes virtual sources through
728
+ * the script_dataset sentinel toolId so the frontend resolves them via
729
+ * queryCache instead of attempting to re-execute SQL.
730
+ */
731
+ virtual?: boolean;
732
+ }>;
733
+ /** The tool_result JSON MainAgent's LLM got back from execute_script — see RunTrace.script.executionResult. */
734
+ executionResult?: string;
735
+ }
736
+ /**
737
+ * Debug trace for a single chat_agent turn — which KB/schema nodes were
738
+ * retrieved and considered, and which script (if any) produced the answer.
739
+ * Persisted separately from the answer itself (fusion-5's
740
+ * `conversation_traces` table, written via `saveTrace`), never sent through
741
+ * `analyticsClient` (data-residency — see design doc §5).
742
+ */
743
+ interface RunTrace {
744
+ version: 1;
745
+ kbNodes: {
746
+ /**
747
+ * Always-on nodes included regardless of the question (getGlobalKnowledgeBase).
748
+ * `content` is the node's full text AS IT WAS at retrieval time — captured so a
749
+ * later edit/delete of the KB node doesn't erase what the LLM actually saw.
750
+ */
751
+ global: Array<{
752
+ kbId: string;
753
+ title: string;
754
+ content?: string;
755
+ }>;
756
+ /** Semantically matched for this specific question (getKnowledgeBase). Same `content` reasoning as above. */
757
+ query: Array<{
758
+ kbId: string;
759
+ title: string;
760
+ similarity?: number;
761
+ content?: string;
762
+ }>;
763
+ };
764
+ schemaNodes: {
765
+ /** MainAgent's cross-source prefilter — which sources were even considered. */
766
+ routing: Array<{
767
+ sourceId: string;
768
+ sourceName?: string;
769
+ similarity: number;
770
+ }>;
771
+ /** SourceAgent-scope per-source table resolution (MainAgent.preResolveSchema). */
772
+ preResolve: Array<{
773
+ sourceId: string;
774
+ table?: string;
775
+ description?: string;
776
+ similarity: number;
777
+ }>;
778
+ /**
779
+ * The exact {{SOURCE_SUMMARIES}} text injected into MainAgent's system prompt
780
+ * (agent-prompt-builder.ts's formatSummariesForPrompt output) — every
781
+ * registered source's catalog entry, not retrieval-specific, captured once per
782
+ * turn. This is what the main agent actually saw when deciding which source(s)
783
+ * to call.
784
+ */
785
+ mainAgentCatalog?: string;
786
+ /**
787
+ * One entry per SourceAgent dispatch (a source called twice in one turn gets
788
+ * two entries) — the exact {{FULL_SCHEMA}} text injected into that
789
+ * SourceAgent's own system prompt, however it was sourced, plus any
790
+ * search_schema follow-up lookups it made mid-conversation when the schema
791
+ * shown wasn't enough.
792
+ */
793
+ sourceAgentSchemas: Array<{
794
+ sourceId: string;
795
+ sourceName?: string;
796
+ /**
797
+ * The exact intent text MainAgent wrote for this dispatch (before the
798
+ * resolved-entities block gets appended by code — see
799
+ * buildResolvedEntitiesBlock) — what MainAgent actually asked this
800
+ * source agent to go find.
801
+ */
802
+ intent: string;
803
+ /** How `schemaText` was sourced — see SourceAgent.buildPrompt's fullSchema fallback chain. */
804
+ method: 'preresolved-embedding' | 'tool-full-schema' | 'tool-description' | 'none';
805
+ schemaText: string;
806
+ /** In call order — each search_schema tool call this SourceAgent made, and the exact result text handed back to its own LLM. */
807
+ searchSchemaLookups: Array<{
808
+ keywords: string[];
809
+ result: string;
810
+ }>;
811
+ /** The tool_result text MainAgent's LLM read back for this dispatch (formatResultForMainAgent output). */
812
+ result?: string;
813
+ }>;
814
+ };
815
+ /** The script that produced this answer, if any. Null for a general (no-tool) answer. */
816
+ script: {
817
+ /** True when an existing recipe was replayed unchanged (ScriptMatcher tier='high'). */
818
+ reused: boolean;
819
+ recipeId?: string | null;
820
+ body?: string | null;
821
+ /** Set when reused — the matcher's reasoning for picking this recipe. */
822
+ reasoning?: string | null;
823
+ /** The winning execute_script tool_result text. Only set when reused=false — a replay never re-runs execute_script. Failed attempts aren't kept. */
824
+ executionResult?: string | null;
825
+ /** Failed execute_script tool_result texts this turn, in order (before the winning one, if any). */
826
+ failedAttempts?: string[];
827
+ } | null;
828
+ /**
829
+ * Everything ScriptMatcher.match() built and sent to its one LLM call this
830
+ * turn — Step 2 of the request flow, immediately after Step 1's exact-match
831
+ * check misses. Captured even when short-circuited before any LLM call, or
832
+ * when the call itself errored, so "why didn't this reuse a script" can
833
+ * always be answered from the trace alone, not just the outcome in `script`.
834
+ * See backend/docs/user-prompt-req-flow/SCRIPT-MATCH-IMPROVEMENTS.md.
835
+ */
836
+ scriptMatcher: {
837
+ /**
838
+ * Exactly what went INTO the one LLM call — every placeholder value
839
+ * substituted into `.prompts/script-match/system.md`, plus the routing
840
+ * facts (isExplicitEdit, the two counts) that aren't literal prompt text
841
+ * but explain WHY the catalog/active-script blocks look the way they do.
842
+ */
843
+ sent: {
844
+ /** Whether the raw prompt carried the explicit "edit :" prefix (see parseEditPrefix). */
845
+ isExplicitEdit: boolean;
846
+ /** The prefix-stripped question actually shown to the LLM (the USER_PROMPT placeholder). */
847
+ userPrompt: string;
848
+ /** The Edit Signal text handed to the LLM this turn (CONFIRMED/NOT CONFIRMED wording). */
849
+ editSignal: string;
850
+ /** The rendered "Scripts From Your Past Questions" catalog text (SCRIPT_CATALOG placeholder). */
851
+ scriptCatalog: string;
852
+ /** Distinct scripts actually in scriptCatalog, after health-filtering and the MAX_CATALOG_RECIPES cap. */
853
+ catalogRecipeCount: number;
854
+ /** The rendered "EDITABLE SCRIPTS" block text (ACTIVE_SCRIPT placeholder) — '' when the thread has no active bindings. */
855
+ activeScript: string;
856
+ /** Active bindings offered as edit candidates this turn. */
857
+ activeBindingCount: number;
858
+ /** The conversation-history text passed in (CONVERSATION_HISTORY placeholder). */
859
+ conversationHistory: string;
860
+ };
861
+ /**
862
+ * Everything that came back OUT — the LLM's raw answer plus what the
863
+ * runtime decided to do with it. `tier` here is the FINAL tier after
864
+ * every coercion (near→none, the edit-prefix gate, candidate checks) —
865
+ * it can legitimately differ from `rawResponse.tier`.
866
+ */
867
+ received: {
868
+ /** False when short-circuited before any LLM call (no catalog match AND no active bindings) — `rawResponse`/`tier` below don't apply. */
869
+ calledLLM: boolean;
870
+ /** The raw JSON the LLM returned, when calledLLM is true and the call didn't throw. */
871
+ rawResponse?: any;
872
+ /** Set when calledLLM is true and the call threw, or the response named an unknown script id. */
873
+ error?: string;
874
+ /** Final tier after ALL coercions. Null when short-circuited, errored, or the call/coercions landed on no match. */
875
+ tier: MatchTier | null;
876
+ };
877
+ } | null;
878
+ /**
879
+ * `resolve_entities` tool activity this turn (see main-agent.ts's
880
+ * RESOLVE_ENTITIES_TOOL_DEF / handleResolveEntities) — names/identifiers the
881
+ * user mentioned, resolved to database ids before any SQL was written.
882
+ * Absent/empty entirely for a project with no entity-search collection
883
+ * registered, or a turn that named nothing.
884
+ */
885
+ entityResolution: {
886
+ /**
887
+ * The entity-type catalog text injected into MainAgent's system prompt
888
+ * (loadEntityCatalog's output) — what let the LLM name a concept instead
889
+ * of guessing the project's vocabulary. Captured once per turn.
890
+ */
891
+ catalogText?: string;
892
+ /**
893
+ * One entry per `resolve_entities` tool call this turn (a turn can call it
894
+ * more than once) — the FULL raw response from the entity-search
895
+ * collection, not just the trimmed {mention,entityType,instanceId,
896
+ * displayName} MainAgent keeps for itself to build the dispatch block.
897
+ * `score`/`ambiguous`/`alternatives` only exist here, nowhere else.
898
+ */
899
+ calls: Array<{
900
+ mentions: Array<{
901
+ text: string;
902
+ entityType?: string;
903
+ }>;
904
+ entityTypes: string[];
905
+ resolved: Array<{
906
+ mention: string;
907
+ entityType: string;
908
+ instanceId: string;
909
+ displayName: string;
910
+ attrs?: Record<string, any>;
911
+ score?: number;
912
+ ambiguous?: boolean;
913
+ alternatives?: Array<{
914
+ instanceId: string;
915
+ displayName: string;
916
+ score: number;
917
+ }>;
918
+ }>;
919
+ unresolved: string[];
920
+ entityMap: Record<string, any>;
921
+ unmatchedEntityTypes?: Array<{
922
+ requested: string;
923
+ candidates?: string[];
924
+ }>;
925
+ /** Set when the collection call itself failed (fails open — see handleResolveEntities). */
926
+ error?: string;
927
+ /** Set on an early return (unavailable / nothing named) so the call is still visible in the trace, not indistinguishable from never having run. */
928
+ note?: string;
929
+ }>;
930
+ };
931
+ /**
932
+ * The prior-turn conversation context injected into this turn's prompt as
933
+ * CONVERSATION_HISTORY — exactly what each flow already builds for itself
934
+ * (chat: thread.getConversationContext(); report/dashboard: their own
935
+ * equivalents), captured as-is. Every call site sets this unconditionally
936
+ * (empty string '' when there's no prior context — new thread, or history
937
+ * trimmed to nothing), so an empty turn is visibly "no history" in the
938
+ * saved trace rather than a silently missing key. Optional only because
939
+ * traces saved before this field existed won't have it at all.
940
+ */
941
+ conversationHistory?: string;
942
+ /**
943
+ * The exact {{USER_ACCESS_CONTEXT}} text injected into MainAgent's system
944
+ * prompt — the per-user authorization config (sa-api users.config)
945
+ * rendered by buildUserAccessContext, as-is. Captured once (MainAgent's
946
+ * prompt is what SourceAgent's identical value is derived from — no need
947
+ * to duplicate it per source dispatch). Set unconditionally (empty string
948
+ * '' when there's no config for this user), so "no restrictions" is
949
+ * visible in the saved trace rather than a silently missing key. Optional
950
+ * only because traces saved before this field existed won't have it.
951
+ */
952
+ userAccessContext?: string;
953
+ }
954
+ /**
955
+ * Configuration for the multi-agent system.
956
+ * Controls limits, models, and behavior.
957
+ */
958
+ interface AgentConfig {
959
+ /** Max rows shown to the UI preview / inlined per source (default: 10) */
960
+ maxRowsPerSource: number;
961
+ /**
962
+ * Max rows a source query may FETCH from the DB server-side (default: 2000).
963
+ * Decoupled from what the main agent is shown: the full result is fetched and
964
+ * summarized (bounded), but only a small/complete slice enters LLM context.
965
+ * This lets small lookups (benchmark maps) arrive COMPLETE without letting
966
+ * large results blow up context.
967
+ */
968
+ maxRowsFetched: number;
969
+ /** Model for the main agent (routing + analysis in one LLM call) */
970
+ mainAgentModel: string;
971
+ /** Model for source agent query generation */
972
+ sourceAgentModel: string;
973
+ /** API key for LLM calls */
974
+ apiKey?: string;
975
+ /** Max retry attempts per source agent */
976
+ maxRetries: number;
977
+ /** Max tool calling iterations for the main agent loop */
978
+ maxIterations: number;
979
+ /** Global knowledge base context (static, same for all users/questions — cached in system prompt) */
980
+ globalKnowledgeBase?: string;
981
+ /** Per-request knowledge base context (user-specific + query-matched — dynamic, not cached) */
982
+ knowledgeBaseContext?: string;
983
+ /** Per-user authorization config (sa-api users.config), rendered to text — see buildUserAccessContext */
984
+ userAccessContext?: string;
985
+ /** Collections registry (ChromaDB search hooks) for embedding-based schema + source search */
986
+ collections?: any;
987
+ /** Optional project ID for scoping embedding searches */
988
+ projectId?: string;
989
+ /**
990
+ * Optional debug-trace accumulator for this turn (Phase 1, chat_agent only).
991
+ * When present, MainAgent-scope retrieval call sites (e.g. preResolveSchema)
992
+ * push their structured results into it. Absent for callers that don't care
993
+ * about trace capture (e.g. headless flows) — every push site must treat
994
+ * this as optional and never let a capture failure affect the real answer.
995
+ */
996
+ trace?: RunTrace;
997
+ }
998
+ /**
999
+ * Default agent configuration
1000
+ */
1001
+ declare const DEFAULT_AGENT_CONFIG: AgentConfig;
1002
+
4
1003
  /**
5
1004
  * Unified UIBlock structure for database storage
6
- * Used in both bookmarks and user-conversations tables
1005
+ * Used in both bookmarks and user-conversations tables.
1006
+ *
1007
+ * `analysis` always holds whatever real narration exists — the full answer on
1008
+ * success, or whatever was actually streamed before a failure (may be empty).
1009
+ * `error` is a dedicated field, null on success — it can be a plain string OR
1010
+ * a structured object/array (e.g. the agent's raw `errors` list), whatever
1011
+ * shape the failure naturally has; it's never coerced into `analysis`.
7
1012
  */
8
1013
  interface DBUIBlock {
9
1014
  id: string;
10
1015
  component: Record<string, any> | null;
11
1016
  analysis: string | null;
12
1017
  user_prompt: string;
1018
+ error?: unknown | null;
1019
+ /**
1020
+ * The script recipe that produced this answer, when one did. Read back via
1021
+ * `conversation-history.exactMatch` so an edit follow-up still has a target
1022
+ * after a reload (the in-memory thread is gone by then), and indexed so
1023
+ * committing an edit can purge every cached answer bound to the recipe.
1024
+ */
1025
+ scriptBinding?: {
1026
+ recipeId: string;
1027
+ params?: Record<string, any>;
1028
+ name?: string;
1029
+ columns?: string[];
1030
+ };
13
1031
  }
14
1032
 
15
1033
  /**
@@ -160,6 +1178,7 @@ declare const DSLRendererPropsSchema$1: z.ZodObject<{
160
1178
  dependencies?: string[] | undefined;
161
1179
  } | undefined;
162
1180
  props?: Record<string, any> | undefined;
1181
+ data?: Record<string, any> | undefined;
163
1182
  render?: any;
164
1183
  states?: Record<string, any> | undefined;
165
1184
  methods?: Record<string, {
@@ -170,7 +1189,6 @@ declare const DSLRendererPropsSchema$1: z.ZodObject<{
170
1189
  fn: string;
171
1190
  deps?: string[] | undefined;
172
1191
  }[] | undefined;
173
- data?: Record<string, any> | undefined;
174
1192
  pages?: {
175
1193
  id: string;
176
1194
  name: string;
@@ -192,6 +1210,7 @@ declare const DSLRendererPropsSchema$1: z.ZodObject<{
192
1210
  dependencies?: string[] | undefined;
193
1211
  } | undefined;
194
1212
  props?: Record<string, any> | undefined;
1213
+ data?: Record<string, any> | undefined;
195
1214
  render?: any;
196
1215
  states?: Record<string, any> | undefined;
197
1216
  methods?: Record<string, {
@@ -202,7 +1221,6 @@ declare const DSLRendererPropsSchema$1: z.ZodObject<{
202
1221
  fn: string;
203
1222
  deps?: string[] | undefined;
204
1223
  }[] | undefined;
205
- data?: Record<string, any> | undefined;
206
1224
  pages?: {
207
1225
  id: string;
208
1226
  name: string;
@@ -228,6 +1246,7 @@ declare const DSLRendererPropsSchema$1: z.ZodObject<{
228
1246
  dependencies?: string[] | undefined;
229
1247
  } | undefined;
230
1248
  props?: Record<string, any> | undefined;
1249
+ data?: Record<string, any> | undefined;
231
1250
  render?: any;
232
1251
  states?: Record<string, any> | undefined;
233
1252
  methods?: Record<string, {
@@ -238,7 +1257,6 @@ declare const DSLRendererPropsSchema$1: z.ZodObject<{
238
1257
  fn: string;
239
1258
  deps?: string[] | undefined;
240
1259
  }[] | undefined;
241
- data?: Record<string, any> | undefined;
242
1260
  pages?: {
243
1261
  id: string;
244
1262
  name: string;
@@ -264,6 +1282,7 @@ declare const DSLRendererPropsSchema$1: z.ZodObject<{
264
1282
  dependencies?: string[] | undefined;
265
1283
  } | undefined;
266
1284
  props?: Record<string, any> | undefined;
1285
+ data?: Record<string, any> | undefined;
267
1286
  render?: any;
268
1287
  states?: Record<string, any> | undefined;
269
1288
  methods?: Record<string, {
@@ -274,7 +1293,6 @@ declare const DSLRendererPropsSchema$1: z.ZodObject<{
274
1293
  fn: string;
275
1294
  deps?: string[] | undefined;
276
1295
  }[] | undefined;
277
- data?: Record<string, any> | undefined;
278
1296
  pages?: {
279
1297
  id: string;
280
1298
  name: string;
@@ -355,6 +1373,7 @@ declare const DSLRendererPropsSchema: z.ZodObject<{
355
1373
  dependencies?: string[] | undefined;
356
1374
  } | undefined;
357
1375
  props?: Record<string, any> | undefined;
1376
+ data?: Record<string, any> | undefined;
358
1377
  render?: any;
359
1378
  states?: Record<string, any> | undefined;
360
1379
  methods?: Record<string, {
@@ -365,7 +1384,6 @@ declare const DSLRendererPropsSchema: z.ZodObject<{
365
1384
  fn: string;
366
1385
  deps?: string[] | undefined;
367
1386
  }[] | undefined;
368
- data?: Record<string, any> | undefined;
369
1387
  }, {
370
1388
  id: string;
371
1389
  name?: string | undefined;
@@ -379,6 +1397,7 @@ declare const DSLRendererPropsSchema: z.ZodObject<{
379
1397
  dependencies?: string[] | undefined;
380
1398
  } | undefined;
381
1399
  props?: Record<string, any> | undefined;
1400
+ data?: Record<string, any> | undefined;
382
1401
  render?: any;
383
1402
  states?: Record<string, any> | undefined;
384
1403
  methods?: Record<string, {
@@ -389,7 +1408,6 @@ declare const DSLRendererPropsSchema: z.ZodObject<{
389
1408
  fn: string;
390
1409
  deps?: string[] | undefined;
391
1410
  }[] | undefined;
392
- data?: Record<string, any> | undefined;
393
1411
  }>;
394
1412
  data: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodAny>>;
395
1413
  context: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodAny>>;
@@ -407,6 +1425,7 @@ declare const DSLRendererPropsSchema: z.ZodObject<{
407
1425
  dependencies?: string[] | undefined;
408
1426
  } | undefined;
409
1427
  props?: Record<string, any> | undefined;
1428
+ data?: Record<string, any> | undefined;
410
1429
  render?: any;
411
1430
  states?: Record<string, any> | undefined;
412
1431
  methods?: Record<string, {
@@ -417,7 +1436,6 @@ declare const DSLRendererPropsSchema: z.ZodObject<{
417
1436
  fn: string;
418
1437
  deps?: string[] | undefined;
419
1438
  }[] | undefined;
420
- data?: Record<string, any> | undefined;
421
1439
  };
422
1440
  data?: Record<string, any> | undefined;
423
1441
  context?: Record<string, any> | undefined;
@@ -435,6 +1453,7 @@ declare const DSLRendererPropsSchema: z.ZodObject<{
435
1453
  dependencies?: string[] | undefined;
436
1454
  } | undefined;
437
1455
  props?: Record<string, any> | undefined;
1456
+ data?: Record<string, any> | undefined;
438
1457
  render?: any;
439
1458
  states?: Record<string, any> | undefined;
440
1459
  methods?: Record<string, {
@@ -445,7 +1464,6 @@ declare const DSLRendererPropsSchema: z.ZodObject<{
445
1464
  fn: string;
446
1465
  deps?: string[] | undefined;
447
1466
  }[] | undefined;
448
- data?: Record<string, any> | undefined;
449
1467
  };
450
1468
  data?: Record<string, any> | undefined;
451
1469
  context?: Record<string, any> | undefined;
@@ -861,6 +1879,10 @@ interface SuperatomSDKConfig {
861
1879
  bundleDir?: string;
862
1880
  promptsDir?: string;
863
1881
  databaseType?: DatabaseType;
1882
+ /** BCP-47 locale for `fmt` in generated analyses, e.g. 'en-IN', 'en-US'. Defaults to 'en-IN'. */
1883
+ locale?: string;
1884
+ /** ISO-4217 currency for `fmt`, e.g. 'INR', 'USD'. Defaults to 'INR'. */
1885
+ currency?: string;
864
1886
  ANTHROPIC_API_KEY?: string;
865
1887
  GROQ_API_KEY?: string;
866
1888
  GEMINI_API_KEY?: string;
@@ -1008,7 +2030,7 @@ declare const KbNodesRequestPayloadSchema: z.ZodObject<{
1008
2030
  content?: string | undefined;
1009
2031
  }>>;
1010
2032
  }, "strip", z.ZodTypeAny, {
1011
- operation: "create" | "getOne" | "update" | "delete" | "getAll" | "search" | "getByCategory" | "getByUser" | "getCategories" | "getTags";
2033
+ operation: "create" | "getOne" | "search" | "update" | "delete" | "getAll" | "getByCategory" | "getByUser" | "getCategories" | "getTags";
1012
2034
  data?: {
1013
2035
  id?: number | undefined;
1014
2036
  type?: "query" | "user" | "global" | undefined;
@@ -1031,7 +2053,7 @@ declare const KbNodesRequestPayloadSchema: z.ZodObject<{
1031
2053
  content?: string | undefined;
1032
2054
  } | undefined;
1033
2055
  }, {
1034
- operation: "create" | "getOne" | "update" | "delete" | "getAll" | "search" | "getByCategory" | "getByUser" | "getCategories" | "getTags";
2056
+ operation: "create" | "getOne" | "search" | "update" | "delete" | "getAll" | "getByCategory" | "getByUser" | "getCategories" | "getTags";
1035
2057
  data?: {
1036
2058
  id?: number | undefined;
1037
2059
  type?: "query" | "user" | "global" | undefined;
@@ -1256,338 +2278,381 @@ declare class DashboardManager {
1256
2278
  }
1257
2279
 
1258
2280
  /**
1259
- * ReportManager class to handle CRUD operations on reports
1260
- * All operations read/write directly to files (no in-memory caching)
1261
- */
1262
- declare class ReportManager {
1263
- private reportsBasePath;
1264
- private projectId;
1265
- /**
1266
- * Initialize ReportManager with project ID
1267
- * @param projectId - Project ID to use in file path
1268
- */
1269
- constructor(projectId?: string);
1270
- /**
1271
- * Get the file path for a specific report
1272
- * @param reportId - Report ID
1273
- * @returns Full path to report data.json file
1274
- */
1275
- private getReportPath;
1276
- /**
1277
- * Create a new report
1278
- * @param reportId - Unique report ID
1279
- * @param report - Report data
1280
- * @returns Created report with metadata
1281
- */
1282
- createReport(reportId: string, report: DSLRendererProps): DSLRendererProps;
1283
- /**
1284
- * Get a specific report by ID
1285
- * @param reportId - Report ID
1286
- * @returns Report data or null if not found
1287
- */
1288
- getReport(reportId: string): DSLRendererProps | null;
1289
- /**
1290
- * Get all reports
1291
- * @returns Array of report objects with their IDs
1292
- */
1293
- getAllReports(): Array<{
1294
- reportId: string;
1295
- report: DSLRendererProps;
1296
- }>;
1297
- /**
1298
- * Update an existing report
1299
- * @param reportId - Report ID
1300
- * @param report - Updated report data
1301
- * @returns Updated report or null if not found
1302
- */
1303
- updateReport(reportId: string, report: DSLRendererProps): DSLRendererProps | null;
1304
- /**
1305
- * Delete a report
1306
- * @param reportId - Report ID
1307
- * @returns True if deleted, false if not found
1308
- */
1309
- deleteReport(reportId: string): boolean;
1310
- /**
1311
- * Check if a report exists
1312
- * @param reportId - Report ID
1313
- * @returns True if report exists, false otherwise
1314
- */
1315
- reportExists(reportId: string): boolean;
1316
- /**
1317
- * Get report count
1318
- * @returns Number of reports
1319
- */
1320
- getReportCount(): number;
1321
- }
1322
-
1323
- /**
1324
- * StreamBuffer - Buffered streaming utility for smoother text delivery
1325
- * Batches small chunks together and flushes at regular intervals
1326
- */
1327
- type StreamCallback = (chunk: string) => void;
1328
- /**
1329
- * StreamBuffer class for managing buffered streaming output
1330
- * Provides smooth text delivery by batching small chunks
1331
- */
1332
- declare class StreamBuffer {
1333
- private buffer;
1334
- private flushTimer;
1335
- private callback;
1336
- private fullText;
1337
- constructor(callback?: StreamCallback);
1338
- /**
1339
- * Check if the buffer has a callback configured
1340
- */
1341
- hasCallback(): boolean;
1342
- /**
1343
- * Get all text that has been written (including already flushed)
1344
- */
1345
- getFullText(): string;
1346
- /**
1347
- * Write a chunk to the buffer
1348
- * Large chunks or chunks with newlines are flushed immediately
1349
- * Small chunks are batched and flushed after a short interval
1350
- *
1351
- * @param chunk - Text chunk to write
1352
- */
1353
- write(chunk: string): void;
1354
- /**
1355
- * Flush the buffer immediately
1356
- * Call this before tool execution or other operations that need clean output
1357
- */
1358
- flush(): void;
1359
- /**
1360
- * Internal flush implementation
1361
- */
1362
- private flushNow;
1363
- /**
1364
- * Clean up resources
1365
- * Call this when done with the buffer
1366
- */
1367
- dispose(): void;
1368
- }
1369
-
1370
- /**
1371
- * ToolExecutorService - Handles execution of SQL queries and external tools
1372
- * Extracted from BaseLLM.generateTextResponse for better separation of concerns
1373
- */
1374
-
1375
- /**
1376
- * External tool definition
1377
- */
1378
- interface ExternalTool {
1379
- id: string;
1380
- name: string;
1381
- description?: string;
1382
- /** Tool type: "source" = routed through SourceAgent, "direct" = called directly by MainAgent */
1383
- toolType?: 'source' | 'direct';
1384
- /** Full untruncated schema for source agent (all columns visible) */
1385
- fullSchema?: string;
1386
- /** Schema size tier: small (≤50 tables), medium (51-200), large (201-500), very_large (500+) */
1387
- schemaTier?: string;
1388
- /** Schema search function for very_large tier — keyword search over entities */
1389
- schemaSearchFn?: (keywords: string[]) => string;
1390
- fn: (input: any) => Promise<any>;
1391
- limit?: number;
1392
- outputSchema?: any;
1393
- executionType?: 'immediate' | 'deferred';
1394
- userProvidedData?: any;
1395
- params?: Record<string, any>;
1396
- }
1397
- /**
1398
- * Executed tool tracking info
1399
- */
1400
- interface ExecutedToolInfo {
1401
- id: string;
1402
- name: string;
1403
- params: any;
1404
- result: {
1405
- _totalRecords: number;
1406
- _recordsShown: number;
1407
- _metadata?: any;
1408
- _sampleData: any[];
1409
- };
1410
- outputSchema?: any;
1411
- sourceSchema?: string;
1412
- sourceType?: string;
1413
- }
1414
-
1415
- /**
1416
- * Multi-Agent Architecture Types
1417
- *
1418
- * Defines interfaces for the hierarchical agent system:
1419
- * - Main Agent: ONE LLM.streamWithTools() call with source agent tools
1420
- * - Source Agents: independent agents that query individual data sources
1421
- *
1422
- * The main agent sees only source summaries. When it calls a source tool,
1423
- * the SourceAgent runs independently (own LLM, own retries) and returns clean data.
1424
- */
1425
-
1426
- /**
1427
- * Per-entity detail: name, row count, and column names.
1428
- * Gives the main agent enough context to route to the right source.
1429
- */
1430
- interface EntityDetail {
1431
- /** Entity name (table, sheet, endpoint) */
1432
- name: string;
1433
- /** Approximate row count */
1434
- rowCount?: number;
1435
- /** Column/field names */
1436
- columns: string[];
1437
- }
1438
- /**
1439
- * Representation of a data source for the main agent.
1440
- * Contains entity names WITH column names so the LLM can route accurately.
1441
- */
1442
- interface SourceSummary {
1443
- /** Source ID (matches tool ID prefix) */
1444
- id: string;
1445
- /** Human-readable source name */
1446
- name: string;
1447
- /** Source type: postgres, excel, rest_api, etc. */
1448
- type: string;
1449
- /** Brief description of what data this source contains */
1450
- description: string;
1451
- /** Detailed entity info with column names for routing */
1452
- entityDetails: EntityDetail[];
1453
- /** The tool ID associated with this source */
1454
- toolId: string;
1455
- }
1456
- /**
1457
- * What a source agent returns after querying its data source.
1458
- * The main agent uses this to analyze and compose the final response.
1459
- */
1460
- interface SourceAgentResult {
1461
- /** Source ID */
1462
- sourceId: string;
1463
- /** Source name */
1464
- sourceName: string;
1465
- /** Whether the query succeeded */
1466
- success: boolean;
1467
- /** Result data rows */
1468
- data: any[];
1469
- /** Metadata about the query execution */
1470
- metadata: SourceAgentMetadata;
1471
- /** Tool execution info for the last successful query (backward compat) */
1472
- executedTool: ExecutedToolInfo;
1473
- /** All successful tool executions (primary + follow-up queries) */
1474
- allExecutedTools?: ExecutedToolInfo[];
1475
- /** Error message if failed */
1476
- error?: string;
1477
- }
1478
- interface SourceAgentMetadata {
1479
- /** Total rows that matched the query (before limit) */
1480
- totalRowsMatched: number;
1481
- /** Rows actually returned (after limit) */
1482
- rowsReturned: number;
1483
- /** Whether the result was truncated by the row limit */
1484
- isLimited: boolean;
1485
- /** The query/params that were executed */
1486
- queryExecuted?: string;
1487
- /** Execution time in milliseconds */
1488
- executionTimeMs: number;
1489
- }
1490
- /**
1491
- * A pre-built, multi-step UI flow registered with the SDK.
1492
- *
1493
- * When the main agent decides a user's question matches a workflow's whenToUse
1494
- * trigger, it picks the workflow instead of running source agents / generating
1495
- * dashboard components. The LLM extracts the workflow's required props from the
1496
- * prompt (using `propsSchema` as the tool input_schema) and the SDK returns the
1497
- * workflow component directly — no analysis text, no chart generation. The
1498
- * frontend renders the registered workflow component with the LLM-extracted
1499
- * props.
1500
- */
1501
- interface WorkflowDescriptor {
1502
- /** Unique workflow id (used as the LLM tool name) */
1503
- id: string;
1504
- /** Component name on the frontend (matches the registered React component) */
1505
- name: string;
1506
- /** Short human-readable description of what this workflow does */
1507
- description: string;
2281
+ * ReportManager class to handle CRUD operations on reports
2282
+ * All operations read/write directly to files (no in-memory caching)
2283
+ */
2284
+ declare class ReportManager {
2285
+ private reportsBasePath;
2286
+ private projectId;
1508
2287
  /**
1509
- * 1–2 sentence trigger condition. The LLM uses this to decide if the
1510
- * user's prompt matches this workflow. Be specific — e.g.
1511
- * "User wants to *initiate* an inventory transfer (review + submit POs),
1512
- * not just see analysis or charts."
2288
+ * Initialize ReportManager with project ID
2289
+ * @param projectId - Project ID to use in file path
1513
2290
  */
1514
- whenToUse: string;
2291
+ constructor(projectId?: string);
1515
2292
  /**
1516
- * JSON-schema-style description of the props the workflow needs. Becomes
1517
- * the LLM tool's input_schema, so the model fills these from the prompt.
1518
- * Use the same shape as `params` on direct tools — string descriptors with
1519
- * an optional "(optional)" suffix.
1520
- *
1521
- * Example:
1522
- * ```
1523
- * {
1524
- * selectedStore: 'object — { id, name } of the source branch',
1525
- * minROI: 'number (optional) — only show transfers with ROI ≥ this',
1526
- * }
1527
- * ```
2293
+ * Get the file path for a specific report
2294
+ * @param reportId - Report ID
2295
+ * @returns Full path to report data.json file
1528
2296
  */
1529
- propsSchema: Record<string, string>;
2297
+ private getReportPath;
1530
2298
  /**
1531
- * Optional: static prop defaults merged with LLM-extracted props before
1532
- * the component is returned. Useful for things like the embedded
1533
- * `externalTool` config that the workflow uses to fetch its own data.
2299
+ * Create a new report
2300
+ * @param reportId - Unique report ID
2301
+ * @param report - Report data
2302
+ * @returns Created report with metadata
1534
2303
  */
1535
- defaultProps?: Record<string, any>;
2304
+ createReport(reportId: string, report: DSLRendererProps): DSLRendererProps;
2305
+ /**
2306
+ * Get a specific report by ID
2307
+ * @param reportId - Report ID
2308
+ * @returns Report data or null if not found
2309
+ */
2310
+ getReport(reportId: string): DSLRendererProps | null;
2311
+ /**
2312
+ * Get all reports
2313
+ * @returns Array of report objects with their IDs
2314
+ */
2315
+ getAllReports(): Array<{
2316
+ reportId: string;
2317
+ report: DSLRendererProps;
2318
+ }>;
2319
+ /**
2320
+ * Update an existing report
2321
+ * @param reportId - Report ID
2322
+ * @param report - Updated report data
2323
+ * @returns Updated report or null if not found
2324
+ */
2325
+ updateReport(reportId: string, report: DSLRendererProps): DSLRendererProps | null;
2326
+ /**
2327
+ * Delete a report
2328
+ * @param reportId - Report ID
2329
+ * @returns True if deleted, false if not found
2330
+ */
2331
+ deleteReport(reportId: string): boolean;
2332
+ /**
2333
+ * Check if a report exists
2334
+ * @param reportId - Report ID
2335
+ * @returns True if report exists, false otherwise
2336
+ */
2337
+ reportExists(reportId: string): boolean;
2338
+ /**
2339
+ * Get report count
2340
+ * @returns Number of reports
2341
+ */
2342
+ getReportCount(): number;
1536
2343
  }
2344
+
1537
2345
  /**
1538
- * The workflow selection captured during a routing call.
1539
- * Set on AgentResponse when the LLM picks a workflow tool.
2346
+ * ScriptRecipeStore — injected metadata backend for the script flow.
2347
+ *
2348
+ * The SDK is standalone (no DB dependency). The backend implements this
2349
+ * interface over Postgres (full-text search + atomic counters) and injects it
2350
+ * via `collections['script-recipes']`, exactly like `collections['source-embeddings']`.
2351
+ * `ScriptStore` consumes it for all METADATA operations while keeping the
2352
+ * executable body on disk as scripts-store/<fileBase>.ts.
2353
+ *
2354
+ * All metadata rows are plain JSON (no scriptBody — that lives on disk).
2355
+ * See backend/docs/SCRIPT-FLOW-SCALING-ISSUES.md (#1, #3, #7).
1540
2356
  */
1541
- interface SelectedWorkflow {
1542
- /** Component name (matches WorkflowDescriptor.name) */
2357
+
2358
+ /** One recipe's metadata as stored in Postgres (mirrors the script_recipes table). */
2359
+ interface ScriptRecipeMetaRow {
2360
+ id: string;
2361
+ projectId?: string | null;
2362
+ version: number;
1543
2363
  name: string;
1544
- /** Props extracted from the prompt + merged with workflow.defaultProps */
1545
- props: Record<string, any>;
2364
+ intentDescription: string;
2365
+ tags: string[] | null;
2366
+ createdFrom: string | null;
2367
+ sourceIds: string[] | null;
2368
+ tables: string[] | null;
2369
+ parameters: ScriptParameter[] | null;
2370
+ components?: ScriptComponentSpec[] | null;
2371
+ displayPreference?: ScriptDisplayPreference | null;
2372
+ fileBase: string;
2373
+ bodyHash?: string | null;
2374
+ successCount: number;
2375
+ failureCount: number;
2376
+ lastUsed: string | null;
2377
+ parentId?: string | null;
2378
+ forkDepth?: number | null;
2379
+ forkReason?: string | null;
2380
+ status: 'draft' | 'verified' | string;
2381
+ turnId?: string | null;
2382
+ editedBy?: string | null;
2383
+ editedFrom?: string | null;
2384
+ history?: ScriptVersionRecord[] | null;
2385
+ lastError?: {
2386
+ phase: 'compile' | 'runtime' | 'timeout' | 'ipc';
2387
+ message: string;
2388
+ at: string;
2389
+ attempt: number;
2390
+ } | null;
2391
+ createdAt?: string | null;
2392
+ updatedAt?: string | null;
2393
+ }
2394
+ interface ScriptRecipeStore {
2395
+ /** FTS shortlist of healthy verified recipes for the matcher (metadata only). */
2396
+ search(params: {
2397
+ prompt: string;
2398
+ projectId?: string;
2399
+ limit?: number;
2400
+ }): Promise<ScriptRecipeMetaRow[]>;
2401
+ /** Fetch one recipe by id (any status). */
2402
+ getById(id: string): Promise<ScriptRecipeMetaRow | null>;
2403
+ /** Count healthy verified recipes (drives the "any scripts?" gate). */
2404
+ count(params?: {
2405
+ projectId?: string;
2406
+ }): Promise<number>;
2407
+ /** Insert or update a recipe row (keyed by id). */
2408
+ upsert(row: ScriptRecipeMetaRow): Promise<void>;
2409
+ /** Atomically bump counters / last-used. */
2410
+ updateStats(id: string, patch: {
2411
+ successDelta?: number;
2412
+ failureDelta?: number;
2413
+ lastUsed?: string;
2414
+ }): Promise<void>;
2415
+ /** Flip a draft to verified, applying provenance + optional fork lineage. */
2416
+ promote(id: string, patch: {
2417
+ sourceIds: string[];
2418
+ tables: string[];
2419
+ fileBase?: string;
2420
+ parentId?: string;
2421
+ forkDepth?: number;
2422
+ forkReason?: string;
2423
+ components?: ScriptComponentSpec[];
2424
+ }): Promise<ScriptRecipeMetaRow | null>;
2425
+ /**
2426
+ * Commit a verified edit onto an EXISTING recipe: bump `version`, replace the
2427
+ * body-bearing metadata, append a history record, reset health counters, and
2428
+ * clear the component specs (they were validated against the old shape).
2429
+ * Returns the updated row, or null when the target is gone.
2430
+ * See backend/docs/SCRIPT-EDIT-DESIGN.md § Component 5.
2431
+ */
2432
+ commitEdit?(id: string, patch: {
2433
+ name?: string;
2434
+ intentDescription?: string;
2435
+ tags?: string[];
2436
+ parameters?: ScriptParameter[];
2437
+ bodyHash: string;
2438
+ /** New on-disk stem when the edit renamed the script; omitted otherwise. */
2439
+ fileBase?: string;
2440
+ sourceIds?: string[];
2441
+ tables?: string[];
2442
+ editedBy?: string;
2443
+ editedFrom?: string;
2444
+ historyEntry: {
2445
+ version: number;
2446
+ at: string;
2447
+ by?: string;
2448
+ instruction?: string;
2449
+ changeSummary?: string;
2450
+ bodyHash?: string;
2451
+ };
2452
+ }): Promise<ScriptRecipeMetaRow | null>;
2453
+ /** Stamp a draft's last execution error. */
2454
+ recordDraftError(id: string, err: {
2455
+ phase: string;
2456
+ message: string;
2457
+ attempt: number;
2458
+ at: string;
2459
+ }): Promise<void>;
2460
+ /** Delete a recipe row (body file removed separately). */
2461
+ remove(id: string): Promise<void>;
2462
+ /** True if `fileBase` is taken by a different recipe in this project. */
2463
+ fileBaseTaken(fileBase: string, excludeId: string, projectId?: string): Promise<boolean>;
1546
2464
  }
2465
+ /** Pull the injected store off the collections bag (or null if not wired). */
2466
+ declare function resolveScriptRecipeStore(collections: any): ScriptRecipeStore | null;
2467
+
1547
2468
  /**
1548
- * The complete response from the multi-agent system.
1549
- * Contains everything needed for text display + component generation.
2469
+ * ScriptStore — Postgres metadata + on-disk body for script recipes.
2470
+ *
2471
+ * Split of responsibilities:
2472
+ * - METADATA → injected `ScriptRecipeStore` (Postgres FTS + atomic counters),
2473
+ * resolved from `collections['script-recipes']`.
2474
+ * - BODY → scripts-store/<fileBase>.ts, editable in your IDE. Written
2475
+ * atomically (temp + rename); `bodyHash` (sha256) detects edits.
2476
+ *
2477
+ * The old "read every file every turn + send the whole catalog to the LLM"
2478
+ * matcher is gone — matching is `store.search(prompt)` (FTS shortlist). The
2479
+ * draft/verified filename dance is gone too: `status` is a DB column and the
2480
+ * file keeps a stable `<fileBase>.ts` name across promotion.
2481
+ *
2482
+ * When no metadata store is injected, the store degrades to a safe no-op
2483
+ * (count 0 → script flow disabled) instead of crashing.
2484
+ *
2485
+ * See backend/docs/SCRIPT-FLOW-SCALING-ISSUES.md.
1550
2486
  */
1551
- interface AgentResponse {
1552
- /** Generated text response (analysis of the data) */
1553
- text: string;
1554
- /** All executed tools across all source agents (for component generation) */
1555
- executedTools: ExecutedToolInfo[];
1556
- /** Individual results from each source agent */
1557
- sourceResults: SourceAgentResult[];
2487
+
2488
+ interface SaveDraftInput {
2489
+ /** Reuse an existing draft (retry); omit to mint a new one. */
2490
+ recipeId?: string;
2491
+ /** Per-turn unique suffix, stable across retries within the turn. */
2492
+ turnId: string;
2493
+ name: string;
2494
+ intentDescription: string;
2495
+ tags: string[];
2496
+ parameters: ScriptParameter[];
2497
+ scriptBody: string;
2498
+ createdFrom: string;
2499
+ /**
2500
+ * Set when this draft is a SHADOW of an existing recipe being edited. The
2501
+ * draft is verified independently and merged back onto the parent via
2502
+ * `commitEdit`, so the working script is never clobbered by an edit that
2503
+ * turns out not to run. See backend/docs/SCRIPT-EDIT-DESIGN.md § D5.
2504
+ */
2505
+ parentId?: string;
2506
+ }
2507
+ interface PromoteToVerifiedInput {
2508
+ sourceIds: string[];
2509
+ tables: string[];
2510
+ parentId?: string;
2511
+ forkDepth?: number;
2512
+ forkReason?: string;
2513
+ components?: ScriptComponentSpec[];
2514
+ }
2515
+ interface ScriptStoreOptions {
2516
+ /** Explicit metadata store, or resolved from `collections['script-recipes']`. */
2517
+ store?: ScriptRecipeStore | null;
2518
+ collections?: any;
2519
+ /** Body directory (defaults to <cwd>/scripts-store). */
2520
+ baseDir?: string;
2521
+ /** Project scope stamped on every row. */
2522
+ projectId?: string;
2523
+ }
2524
+ declare function normalizeScriptBody(scriptBody: string): string;
2525
+ declare class ScriptStore {
2526
+ private store;
2527
+ private storeDir;
2528
+ private projectId?;
2529
+ constructor(opts?: ScriptStoreOptions);
2530
+ /** Whether a metadata store is wired (matcher / authoring are gated on this). */
2531
+ hasStore(): boolean;
2532
+ /** Number of healthy verified recipes (gates the script-matching path). */
2533
+ count(): Promise<number>;
2534
+ /**
2535
+ * FTS shortlist for the matcher (metadata only — bodies are loaded lazily by
2536
+ * `get()` once the LLM picks one). Returns verified, healthy recipes ranked
2537
+ * by relevance.
2538
+ */
2539
+ search(prompt: string, limit?: number): Promise<ScriptRecipe[]>;
2540
+ /** Fetch one recipe by id with its body loaded from disk. */
2541
+ get(id: string): Promise<ScriptRecipe | null>;
2542
+ /** Create or update a recipe (metadata upsert + body write when changed). */
2543
+ save(recipe: ScriptRecipe): Promise<void>;
2544
+ /**
2545
+ * Persist (or update) a draft. Within a turn, retries that pass the same
2546
+ * `recipeId` overwrite the same row + file; a fresh `recipeId` mints a new
2547
+ * draft. The body is visible at scripts-store/<fileBase>.ts immediately.
2548
+ */
2549
+ saveDraft(input: SaveDraftInput): Promise<ScriptRecipe>;
2550
+ /** Stamp a draft's last execution error (metadata only). */
2551
+ recordDraftError(recipeId: string, err: {
2552
+ phase: 'compile' | 'runtime' | 'timeout' | 'ipc';
2553
+ message: string;
2554
+ attempt: number;
2555
+ }): Promise<void>;
2556
+ /**
2557
+ * Promote a successfully-executed draft into a verified script.
2558
+ * The on-disk body already exists at <fileBase>.ts (written at write_script
2559
+ * time) and keeps its name — only the DB row flips status + provenance.
2560
+ */
2561
+ promoteToVerified(recipeId: string, input: PromoteToVerifiedInput): Promise<ScriptRecipe | null>;
2562
+ /**
2563
+ * Commit a user-directed edit: merge a VERIFIED shadow draft back onto the
2564
+ * recipe it was editing, as version N+1 under the SAME recipe id.
2565
+ *
2566
+ * Keeping the id stable is the point of the whole feature — every cached
2567
+ * conversation, `script_dataset` regeneration descriptor and persisted
2568
+ * component spec already points at it, so the correction applies retroactively
2569
+ * to replays instead of stranding them on the old body.
2570
+ *
2571
+ * Steps (see backend/docs/SCRIPT-EDIT-DESIGN.md § Component 5):
2572
+ * 1. archive the current body as `<fileBase>.v<version>.ts`
2573
+ * 2. write the edited body to the original fileBase (atomic)
2574
+ * 3. version++, copy name/description/params, append a history record
2575
+ * 4. reset health counters — the pre-edit failure history is stale
2576
+ * 5. clear component specs — they were validated against the OLD shape
2577
+ * 6. delete the shadow draft (row + file)
2578
+ *
2579
+ * Returns the updated recipe, or null when the commit could not be applied
2580
+ * (caller should then fall back to treating the draft as a new script).
2581
+ */
2582
+ commitEdit(targetId: string, draft: {
2583
+ recipeId: string;
2584
+ name?: string;
2585
+ intentDescription?: string;
2586
+ tags?: string[];
2587
+ parameters?: ScriptParameter[];
2588
+ scriptBody: string;
2589
+ sourceIds?: string[];
2590
+ tables?: string[];
2591
+ }, meta: {
2592
+ instruction?: string;
2593
+ changeSummary?: string;
2594
+ editedBy?: string;
2595
+ }): Promise<ScriptRecipe | null>;
2596
+ /**
2597
+ * Drop a draft (row + body file). MainAgent calls this at end-of-turn when a
2598
+ * draft was authored but never verified — failed drafts are never matched, so
2599
+ * deleting them immediately avoids unbounded accumulation (#5). No-op if the
2600
+ * recipe isn't a draft (so a promoted/verified script is never removed here).
2601
+ */
2602
+ discardDraft(recipeId: string): Promise<void>;
2603
+ /** Delete a recipe (row + body file). */
2604
+ delete(id: string): Promise<void>;
2605
+ /** Record a successful execution (atomic counter bump). */
2606
+ recordSuccess(id: string): Promise<void>;
2607
+ /** Record a failed execution (atomic counter bump). */
2608
+ recordFailure(id: string): Promise<void>;
2609
+ /** Absolute path to the .ts body for a recipe (used by the runner/MainAgent). */
2610
+ getScriptPath(recipe: ScriptRecipe): string;
2611
+ private removeById;
2612
+ private rowToRecipe;
2613
+ private recipeToRow;
2614
+ /** slug of name, with a short id suffix when the bare slug is already taken. */
2615
+ private computeFileBase;
2616
+ private toSlug;
2617
+ private hash;
2618
+ /**
2619
+ * Attach getComponents to the recipe body. The stored `components` column is
2620
+ * cleared at promotion (see promoteToVerified): once the body computes its own
2621
+ * specs, a stale spec array beside a live program is how the wrong one gets
2622
+ * read later. See backend/docs/COMPONENTS-AS-PROGRAM-DESIGN.md § 4.4.
2623
+ */
2624
+ attachComponents(recipeId: string, componentsBody: string): Promise<boolean>;
2625
+ /**
2626
+ * Append (or replace) the `getAnalysis` export on an existing draft body.
2627
+ *
2628
+ * The narrative is authored AFTER execution, so it lands on a file that
2629
+ * already holds a working getData — rewriting the whole body would risk
2630
+ * losing the query that just succeeded. Replaces any earlier getAnalysis so
2631
+ * a retry does not stack duplicate exports.
2632
+ */
2633
+ attachAnalysis(recipeId: string, analysisBody: string): Promise<boolean>;
2634
+ private bodyPath;
2635
+ private readBody;
2636
+ /** Directory holding superseded bodies. Dot-prefixed so IDEs/`ls` hide it. */
2637
+ private get archiveDir();
2638
+ /**
2639
+ * Archive a superseded body as `.versions/<fileBase>.v<n>.ts`.
2640
+ *
2641
+ * Kept out of the main store directory on purpose — see commitEdit step 1.
2642
+ * To roll back: copy the file back over `scripts-store/<fileBase>.ts`.
2643
+ */
2644
+ private writeArchive;
1558
2645
  /**
1559
- * Set when the LLM routed the question to a registered workflow component.
1560
- * When present, the upstream caller should skip component generation and
1561
- * return this workflow as the response.
2646
+ * Move a recipe's archived versions to a new prefix when its fileBase changes,
2647
+ * so all versions of one recipe stay grouped. Without this, two renames would
2648
+ * scatter a single recipe's history across three prefixes in `.versions/` with
2649
+ * nothing linking them back to the live script.
1562
2650
  */
1563
- workflow?: SelectedWorkflow;
1564
- }
1565
- /**
1566
- * Configuration for the multi-agent system.
1567
- * Controls limits, models, and behavior.
1568
- */
1569
- interface AgentConfig {
1570
- /** Max rows a source agent can return (default: 50) */
1571
- maxRowsPerSource: number;
1572
- /** Model for the main agent (routing + analysis in one LLM call) */
1573
- mainAgentModel: string;
1574
- /** Model for source agent query generation */
1575
- sourceAgentModel: string;
1576
- /** API key for LLM calls */
1577
- apiKey?: string;
1578
- /** Max retry attempts per source agent */
1579
- maxRetries: number;
1580
- /** Max tool calling iterations for the main agent loop */
1581
- maxIterations: number;
1582
- /** Global knowledge base context (static, same for all users/questions — cached in system prompt) */
1583
- globalKnowledgeBase?: string;
1584
- /** Per-request knowledge base context (user-specific + query-matched — dynamic, not cached) */
1585
- knowledgeBaseContext?: string;
2651
+ private renameArchives;
2652
+ /** Atomic body write (temp + rename) so concurrent reads never see a partial file. */
2653
+ private writeBody;
2654
+ private unlinkBody;
1586
2655
  }
1587
- /**
1588
- * Default agent configuration
1589
- */
1590
- declare const DEFAULT_AGENT_CONFIG: AgentConfig;
1591
2656
 
1592
2657
  /**
1593
2658
  * Main Agent (Orchestrator)
@@ -1609,7 +2674,73 @@ declare class MainAgent {
1609
2674
  private workflows;
1610
2675
  private config;
1611
2676
  private streamBuffer;
1612
- constructor(externalTools: ExternalTool[], config: AgentConfig, streamBuffer?: StreamBuffer, workflows?: WorkflowDescriptor[]);
2677
+ /**
2678
+ * Optional: when provided, MainAgent exposes the `write_script` /
2679
+ * `execute_script` tools to the LLM and persists drafts to disk via the
2680
+ * store. Headless callers (alert analyzer, metric resolver) omit these to
2681
+ * suppress script authoring entirely — drafts would otherwise leak onto
2682
+ * disk with no caller to promote or clean them up.
2683
+ */
2684
+ private scriptStore;
2685
+ private turnId;
2686
+ private createdFromPrompt;
2687
+ private scriptState;
2688
+ /** Answer-flow component catalog (filtered + projected by the caller). */
2689
+ private componentCatalog;
2690
+ /** Specs accepted by `write_components` this turn; empty until it succeeds. */
2691
+ /**
2692
+ * Entities resolved this turn, appended verbatim to every source dispatch.
2693
+ *
2694
+ * Not left to the model to copy into its intent prose: observed live, the
2695
+ * MainAgent wrote names instead of ids on the first dispatch AND re-spelled
2696
+ * 'F D C LIMITED' as 'FDC Limited', so the source agent fell back to
2697
+ * `PartyName LIKE '%FDC%'` and found 2 of 3 customers. Carrying the ids
2698
+ * structurally makes that impossible rather than instruction-dependent.
2699
+ */
2700
+ private resolvedEntities;
2701
+ private componentSpecs;
2702
+ private componentLayout;
2703
+ private renderComponentAttempts;
2704
+ /** Same repeated-violation tracking as ScriptState.lastAnalysisViolationTexts, for write_components. */
2705
+ private lastComponentsViolationTexts;
2706
+ /**
2707
+ * Fork mode — set when this turn is adapting a near-matching parent script.
2708
+ * In fork mode there is no legitimate "answer with bare text" outcome: the
2709
+ * only correct first move is a tool call (write_script, or a source tool for
2710
+ * schema discovery). We therefore force tool use on the first LLM iteration
2711
+ * so the model can't end its turn with a bare "I'll adapt…" preamble and zero
2712
+ * tool calls. Never set on the fresh-authoring / general-question path.
2713
+ */
2714
+ private forkMode;
2715
+ /**
2716
+ * Edit mode — set when this turn applies a user-directed change to an
2717
+ * existing script. Swaps the system prompt to `agent-main-edit` and stamps
2718
+ * the shadow draft's parentId. Like fork mode there is no legitimate
2719
+ * "answer with bare text" outcome, so tool use is forced on iteration 1.
2720
+ * See backend/docs/SCRIPT-EDIT-DESIGN.md § Component 4.
2721
+ */
2722
+ private editContext;
2723
+ /** The recipe's durable rendering choice — see the constructor. */
2724
+ private displayPreference;
2725
+ /**
2726
+ * Per-turn cancellation signal (user hit "Stop"). Set at the top of
2727
+ * handleQuestion and read by the tool handler, the SourceAgent dispatch, and
2728
+ * the script subprocess so an abort tears down every layer of the turn.
2729
+ */
2730
+ private abortSignal?;
2731
+ constructor(externalTools: ExternalTool[], config: AgentConfig, scriptStore?: ScriptStore, turnId?: string, streamBuffer?: StreamBuffer, workflows?: WorkflowDescriptor[], forkMode?: boolean, editContext?: EditContext, componentCatalog?: Component[],
2732
+ /**
2733
+ * The recipe's durable rendering choice, when it has one. A DATA edit
2734
+ * re-authors getComponents from scratch, so without this the user's chart
2735
+ * type is silently dropped whenever anyone changes the SQL.
2736
+ */
2737
+ displayPreference?: {
2738
+ componentTypes: string[];
2739
+ instruction: string;
2740
+ });
2741
+ /** True when the turn is applying a user-directed script edit. */
2742
+ private get editMode();
2743
+ private get scriptingEnabled();
1613
2744
  /**
1614
2745
  * Handle a user question using the multi-agent system.
1615
2746
  *
@@ -1620,7 +2751,161 @@ declare class MainAgent {
1620
2751
  * 4. Direct tools → fn() called directly with LLM params → returns data
1621
2752
  * 5. Generates final analysis text
1622
2753
  */
1623
- handleQuestion(userPrompt: string, apiKey?: string, conversationHistory?: string, streamCallback?: (chunk: string) => void): Promise<AgentResponse>;
2754
+ handleQuestion(userPrompt: string, apiKey?: string, conversationHistory?: string, streamCallback?: (chunk: string) => void, signal?: AbortSignal): Promise<AgentResponse>;
2755
+ /**
2756
+ * Tool definition, with the catalog rendered from the registered `Metadata`
2757
+ * the caller passed in. Generated rather than hand-written so it cannot drift
2758
+ * from what the frontend actually ships.
2759
+ */
2760
+ private buildWriteComponentsToolDef;
2761
+ /**
2762
+ * Validate the agent's component picks against the REAL columns of each bound
2763
+ * dataset. All-or-nothing: any error rejects the whole call and returns the
2764
+ * findings, because a partially-accepted dashboard makes the retry ambiguous.
2765
+ */
2766
+ private validateSpecs;
2767
+ /**
2768
+ * Author the dashboard as a program. Attaches getComponents to the draft, runs
2769
+ * it over the verified rows, then validates the specs it RETURNED — the program
2770
+ * is never trusted because it is a program, exactly as an authored spec is not.
2771
+ */
2772
+ private handleWriteComponents;
2773
+ /**
2774
+ * Author the answer as a program. Runs after execute_script, so the body is
2775
+ * written with the result already known and can react to what it found.
2776
+ *
2777
+ * Rejects a body that types numbers rather than computing them — see
2778
+ * analysis-lint. A hardcoded figure is worse than prose: it freezes into the
2779
+ * recipe and replays unchanged while the data moves underneath it.
2780
+ */
2781
+ private handleWriteAnalysis;
2782
+ private handleWriteScript;
2783
+ private handleExecuteScript;
2784
+ /**
2785
+ * Build the AgentWrittenScript payload the caller will hand to
2786
+ * `ScriptStore.promoteToVerified()`. Only returned when a verified
2787
+ * successful execution is on record.
2788
+ */
2789
+ private buildSavedScript;
2790
+ private normalizeParameterList;
2791
+ /**
2792
+ * Which declared parameter NAMES never actually appear wired into the
2793
+ * script body — checked as plain text, not a real parser, so it only
2794
+ * catches the worst case (completely unreferenced) rather than every
2795
+ * subtler variant (e.g. used for display text while the SQL itself still
2796
+ * hardcodes the value). That worst case is exactly what's been observed:
2797
+ * a parameter declared purely for show, with the actual filter hardcoded.
2798
+ * Accepts `params.name`, `params['name']`/`params["name"]`, and a
2799
+ * destructuring binding (`const { name } = params`) as valid wiring.
2800
+ */
2801
+ private findUnwiredParams;
2802
+ /**
2803
+ * Use the schema embedding collection to pre-select relevant tables for
2804
+ * this source + intent. Returns a formatted schema block if confidence is
2805
+ * high (top match ≥ 0.55 and ≥3 candidates), otherwise null.
2806
+ *
2807
+ * When this returns a block, we can skip the SourceAgent's `search_schema`
2808
+ * loop and reduce iteration budget. When it returns null, the SourceAgent
2809
+ * falls back to the existing LLM-driven keyword search (same as today).
2810
+ */
2811
+ /**
2812
+ * Ids + verbatim names for everything resolved this turn, appended by CODE to
2813
+ * each source dispatch so neither omission nor re-spelling by the model can
2814
+ * lose them. Empty string when nothing was resolved, so intents are untouched
2815
+ * for questions that name no entities.
2816
+ *
2817
+ * Also appends `attrs.scopeSql` when the resolved instance carries one —
2818
+ * same "guaranteed by code" reasoning as the ids/names above, extended to
2819
+ * the one attrs field with a documented, cross-entity-type meaning: a
2820
+ * ready-made SQL predicate an entity's index precomputed (see
2821
+ * ENTITY-SEARCH-DESIGN.md's hierarchy-broadening pattern — branch/region/
2822
+ * state entity types attach it so a lane/route question never needs its
2823
+ * own city-matching join). Confirmed real cost of not doing this: a
2824
+ * branch/state resolved with scopeSql sat unused while the source agent
2825
+ * spent 4 failed exploratory queries rediscovering the exact same
2826
+ * branch-id list by hand (Invalid column name 'StateName'/'CityId'/
2827
+ * 'OrganizationLocationId', in that order, ~144s, before landing on ids
2828
+ * that were sitting in scopeSql from the very first resolve_entities
2829
+ * call). Other attrs (code, counts, etc.) are not dumped here — they are
2830
+ * descriptive, not actionable the way a precomputed predicate is, and
2831
+ * bloating every dispatch with all of them for no clear gain isn't worth
2832
+ * it; scopeSql is the one thing worth this guarantee today.
2833
+ */
2834
+ private buildResolvedEntitiesBlock;
2835
+ /** True when the backend registered the entity-search collection. */
2836
+ private get entitySearchEnabled();
2837
+ /** True when the backend registered the concepts collection. */
2838
+ private get conceptsEnabled();
2839
+ /**
2840
+ * Concept names for the system prompt. Names ONLY — the body comes back from
2841
+ * resolve_concepts once the LLM has named one, exactly as with the entity
2842
+ * catalog. Putting bodies here would rebuild the always-on context problem
2843
+ * concepts exist to solve.
2844
+ *
2845
+ * Not cached, for the same reason loadEntityCatalog isn't: unchanged rows
2846
+ * render byte-identical text so the prompt-cache prefix still hits, and a
2847
+ * process cache would only buy a window where a new concept is invisible.
2848
+ */
2849
+ private loadConceptCatalog;
2850
+ /**
2851
+ * The ALWAYS-INJECTED tier: preconditions no question is semantically close
2852
+ * to — date encodings, valid-row filters. These cannot be retrieval-gated.
2853
+ * "What was revenue last quarter?" has no similarity to "dates are DD/MM/YYYY
2854
+ * text", so leaving them to be requested means they are silently dropped and
2855
+ * the answer is confidently wrong rather than visibly missing.
2856
+ *
2857
+ * Bodies ARE included here — unlike the catalog — because there is nothing to
2858
+ * request: being unrequestable is what makes them invariants.
2859
+ */
2860
+ private loadConceptInvariants;
2861
+ /**
2862
+ * Resolve the concepts for a turn, with a SERVER-SIDE FLOOR.
2863
+ *
2864
+ * Pinning a tool guarantees it is called; it does not guarantee the model
2865
+ * fills in the arguments. Observed: a question containing the exact words
2866
+ * "revenue forecast" produced a call with no concepts at all, and the agent
2867
+ * then used an incomplete copy of the formula from the knowledge base — the
2868
+ * resulting query filtered a customer id against a project column and
2869
+ * returned zero rows on every attempt.
2870
+ *
2871
+ * So when the model names nothing, scan the question itself for catalog names
2872
+ * and aliases on word boundaries. Precise (a literal name is evidence, not a
2873
+ * guess) and asymmetric in the safe direction: an unneeded definition costs a
2874
+ * few hundred ignorable tokens, a missing one costs a wrong answer.
2875
+ */
2876
+ /**
2877
+ * Returns the tool-facing fields to spread into the resolve_entities JSON
2878
+ * response, PLUS a `_trace` field with everything the trace needs that the
2879
+ * model does not (asked/viaFloor/unmatched). Callers must pull `_trace` out
2880
+ * before spreading the rest into what the model sees — see handleResolveEntities.
2881
+ */
2882
+ private resolveConceptsForTurn;
2883
+ /**
2884
+ * Never throws: a concept-store outage must degrade to "no definition found"
2885
+ * and leave the agent deriving the formula as it does today, not take the
2886
+ * whole answer down.
2887
+ */
2888
+ private handleResolveConcepts;
2889
+ /**
2890
+ * Compact catalog (type + gloss) for the system prompt. This is what lets the
2891
+ * LLM NAME a concept instead of guessing at our vocabulary — it can infer
2892
+ * that a question is about unpaid money, but not that we call that
2893
+ * `outstanding-balance`. Full `resolution` detail is fetched by the tool.
2894
+ *
2895
+ * Deliberately NOT cached in-process. The token cost is already handled by
2896
+ * prompt caching (the system prompt carries a cache_control breakpoint), and
2897
+ * re-reading a tiny PK-ordered table costs ~nothing. Fetching fresh does not
2898
+ * weaken the prompt cache either: unchanged data renders byte-identical text,
2899
+ * so the prefix still hits. A process cache would only buy a staleness window
2900
+ * in which a newly indexed entity is invisible to the agent.
2901
+ */
2902
+ private loadEntityCatalog;
2903
+ /**
2904
+ * Never throws: a resolver outage must degrade to "nothing resolved" and
2905
+ * leave the agent exactly as it was, not take the whole answer down.
2906
+ */
2907
+ private handleResolveEntities;
2908
+ private preResolveSchema;
1624
2909
  /**
1625
2910
  * Execute a direct tool — call fn() with LLM-provided params, no SourceAgent.
1626
2911
  */
@@ -1688,6 +2973,43 @@ interface LLMOptions {
1688
2973
  apiKey?: string;
1689
2974
  baseURL?: string;
1690
2975
  partial?: (chunk: string) => void;
2976
+ /**
2977
+ * Per-request cancellation. When the caller aborts this signal (user hit
2978
+ * "Stop"), the underlying provider request is cancelled and the call throws
2979
+ * a RequestAbortedError. Threaded into the provider `messages.create` request
2980
+ * options and checked between tool-loop iterations. Currently honored on the
2981
+ * Anthropic path (the agent flow's default provider).
2982
+ */
2983
+ signal?: AbortSignal;
2984
+ /**
2985
+ * Forces a tool call on the FIRST iteration of streamWithTools only
2986
+ * (subsequent iterations revert to auto). Used by fork mode to stop the
2987
+ * model from ending its turn with a bare "I'll adapt the script…" preamble
2988
+ * and zero tool calls. `{ type: 'any' }` lets the model pick which tool
2989
+ * (write_script in the common case, a source tool for schema discovery);
2990
+ * `{ type: 'tool', name }` pins a specific tool. Honored on both the
2991
+ * Anthropic path and the OpenAI/OpenRouter path (mapped to OpenAI's
2992
+ * tool_choice: 'required' / a named function).
2993
+ */
2994
+ firstIterationToolChoice?: {
2995
+ type: 'any';
2996
+ } | {
2997
+ type: 'tool';
2998
+ name: string;
2999
+ };
3000
+ /**
3001
+ * Internal — set only by the OpenRouter wrappers when the target is a Claude
3002
+ * model. Tells the OpenAI-wire path to emit Anthropic `cache_control`
3003
+ * breakpoints (OpenRouter forwards them to Anthropic for prompt caching).
3004
+ * Never set for direct OpenAI/Groq calls, so their requests are unchanged.
3005
+ */
3006
+ _openrouterClaudeCaching?: boolean;
3007
+ /**
3008
+ * Internal — OpenRouter provider-routing preferences (forwarded as the
3009
+ * `provider` body field). Set by the OpenRouter wrappers to steer routing to
3010
+ * a fast backend (e.g. {sort:'throughput'}). Never set for direct OpenAI/Groq.
3011
+ */
3012
+ _openrouterProvider?: Record<string, unknown>;
1691
3013
  }
1692
3014
  interface Tool {
1693
3015
  name: string;
@@ -1740,15 +3062,41 @@ declare class LLM {
1740
3062
  * (e.g. "claude-sonnet-4.5"). OpenRouter slugs drop the date suffix and use dotted versions.
1741
3063
  */
1742
3064
  private static _toOpenRouterSlug;
3065
+ /**
3066
+ * Per-provider proxy base URL. Returns `${SUPERATOM_LLM_PROXY_URL}/<provider>`
3067
+ * when our Cloudflare LLM proxy is configured, else undefined (→ talk to the
3068
+ * provider directly, legacy behaviour). An explicit options.baseURL (e.g.
3069
+ * OpenRouter) always wins and is never overridden. See backend/docs/llm-proxy.md.
3070
+ */
3071
+ private static _proxyBaseURL;
1743
3072
  private static _openrouterOptions;
3073
+ private static _isRetryableProviderError;
3074
+ private static _withOpenrouterRetry;
1744
3075
  private static _openrouterText;
1745
3076
  private static _openrouterStream;
1746
3077
  private static _openrouterStreamWithTools;
3078
+ /**
3079
+ * Build an Anthropic client. Routes through our Cloudflare LLM proxy when
3080
+ * SUPERATOM_LLM_PROXY_URL is set (each client ships a per-client proxy key as
3081
+ * ANTHROPIC_API_KEY and never holds the real key); otherwise talks to
3082
+ * api.anthropic.com directly. See backend/docs/llm-proxy.md.
3083
+ */
3084
+ private static _anthropicClient;
3085
+ /** True when OpenRouter is configured as a fail-open fallback for Claude. */
3086
+ private static _openrouterAvailable;
3087
+ /** Remap an Anthropic model id to the OpenRouter model path for fail-open. */
3088
+ private static _anthropicFallbackModel;
1747
3089
  private static _anthropicText;
1748
3090
  private static _anthropicStream;
1749
3091
  private static _anthropicStreamWithTools;
1750
3092
  private static _groqText;
1751
3093
  private static _groqStream;
3094
+ /**
3095
+ * Gemini request options carrying the proxy base URL, or undefined → talk to
3096
+ * generativelanguage.googleapis.com directly. The Google SDK takes baseUrl as a
3097
+ * per-model request option, not a constructor arg. See backend/docs/llm-proxy.md.
3098
+ */
3099
+ private static _geminiRequestOptions;
1752
3100
  private static _geminiText;
1753
3101
  private static _geminiStream;
1754
3102
  /**
@@ -1757,8 +3105,28 @@ declare class LLM {
1757
3105
  */
1758
3106
  private static _cleanSchemaForGemini;
1759
3107
  private static _geminiStreamWithTools;
3108
+ /** True for Anthropic/Claude model ids — gates OpenRouter prompt caching. */
3109
+ private static _isClaudeModel;
3110
+ /**
3111
+ * Build the OpenAI-wire system message. For OpenRouter + Claude
3112
+ * (cacheClaude=true) it emits content parts carrying Anthropic
3113
+ * `cache_control` breakpoints (preserving any the caller set, else marking
3114
+ * the last block), so OpenRouter forwards them to Anthropic for prompt
3115
+ * caching. Otherwise it returns a plain flattened string — unchanged for
3116
+ * direct OpenAI/Groq.
3117
+ */
3118
+ private static _openaiSystemMessage;
3119
+ /**
3120
+ * Split an OpenAI-wire usage object. `prompt_tokens` INCLUDES cached tokens,
3121
+ * so we subtract them out (Anthropic-style: input excludes cache reads) and
3122
+ * report cached separately — this makes calculateCost price cache reads at
3123
+ * the discounted rate and reflects OpenRouter prompt-cache savings in logs.
3124
+ */
3125
+ private static _openaiUsage;
1760
3126
  private static _openaiText;
1761
3127
  private static _openaiStream;
3128
+ /** Map the Anthropic-style firstIterationToolChoice to OpenAI's tool_choice. */
3129
+ private static _openaiToolChoice;
1762
3130
  private static _openaiStreamWithTools;
1763
3131
  /**
1764
3132
  * Parse JSON string, handling markdown code blocks and surrounding text
@@ -1860,6 +3228,13 @@ declare class UIBlock {
1860
3228
  private textResponse;
1861
3229
  private actions;
1862
3230
  private createdAt;
3231
+ /**
3232
+ * Which script recipe produced this answer, when a script did. Read on the
3233
+ * NEXT turn so the user can say "use mode instead" and have the matcher
3234
+ * resolve it to a concrete script (the `edit` tier is unreachable without it).
3235
+ * See backend/docs/SCRIPT-EDIT-DESIGN.md § Component 1.
3236
+ */
3237
+ private scriptBinding;
1863
3238
  /**
1864
3239
  * Creates a new UIBlock instance
1865
3240
  * @param userQuestion - The user's question or input
@@ -1951,9 +3326,22 @@ declare class UIBlock {
1951
3326
  * Clear all actions
1952
3327
  */
1953
3328
  clearActions(): void;
3329
+ /** The program-generated half of the answer — see setProgramAnswer. */
3330
+ programAnswer?: string | null;
1954
3331
  /**
1955
- * Get creation timestamp
3332
+ * Bind this block to the script recipe that produced its answer.
3333
+ */
3334
+ setScriptBinding(binding: Record<string, any> | null): void;
3335
+ /**
3336
+ * The program-generated half of the answer, kept verbatim so a reload can
3337
+ * replace exactly that text without disturbing the streamed narration.
1956
3338
  */
3339
+ setProgramAnswer(text: string | null): void;
3340
+ getProgramAnswer(): string | null;
3341
+ /**
3342
+ * The script recipe bound to this block, if any.
3343
+ */
3344
+ getScriptBinding(): Record<string, any> | null;
1957
3345
  getCreatedAt(): Date;
1958
3346
  /**
1959
3347
  * Convert UIBlock to JSON-serializable object
@@ -2021,6 +3409,32 @@ declare class Thread {
2021
3409
  * @param currentUIBlockId - ID of current UIBlock to exclude from context (optional)
2022
3410
  * @returns Formatted conversation history string
2023
3411
  */
3412
+ /**
3413
+ * The script recipe bound to the most recent completed UIBlock — i.e. the
3414
+ * script behind the answer the user is currently looking at. Drives the
3415
+ * matcher's `edit` tier: without it, "use mode instead" has no target and
3416
+ * falls through to regeneration.
3417
+ * See backend/docs/SCRIPT-EDIT-DESIGN.md § Component 1.
3418
+ */
3419
+ getActiveScriptBinding(currentUIBlockId?: string): Record<string, any> | null;
3420
+ /**
3421
+ * The recent script-backed answers in this thread, newest first — the
3422
+ * candidate set a user-directed edit can target.
3423
+ *
3424
+ * Returning several rather than only the newest is what lets an instruction
3425
+ * name its own target ("use the mode for the WSP one"). With a single
3426
+ * candidate every edit lands on the most recent script, which silently edits
3427
+ * the wrong recipe whenever the user meant an earlier one.
3428
+ *
3429
+ * Deduped by recipeId (newest occurrence wins) so a long editing session on
3430
+ * one script doesn't crowd out the others. Each entry carries the question
3431
+ * that produced it — without that the candidates are indistinguishable.
3432
+ *
3433
+ * In-memory only: dies with the process. The caller falls back to the
3434
+ * persisted bindings when this comes back empty.
3435
+ * See backend/docs/SCRIPT-EDIT-DESIGN.md § Component 1.
3436
+ */
3437
+ getScriptBindings(limit?: number, currentUIBlockId?: string): Record<string, any>[];
2024
3438
  getConversationContext(limit?: number, currentUIBlockId?: string): string;
2025
3439
  /**
2026
3440
  * Convert Thread to JSON-serializable object
@@ -2683,7 +4097,7 @@ declare abstract class BaseLLM {
2683
4097
  * This helps provide intelligent suggestions for follow-up queries
2684
4098
  * For general/conversational questions without components, pass textResponse instead
2685
4099
  */
2686
- generateNextQuestions(originalUserPrompt: string, component?: Component | null, componentData?: Record<string, unknown>, apiKey?: string, conversationHistory?: string, textResponse?: string): Promise<string[]>;
4100
+ generateNextQuestions(originalUserPrompt: string, component?: Component | null, componentData?: Record<string, unknown>, apiKey?: string, conversationHistory?: string, textResponse?: string, signal?: AbortSignal): Promise<string[]>;
2687
4101
  }
2688
4102
 
2689
4103
  interface AnthropicLLMConfig extends BaseLLMConfig {
@@ -2889,6 +4303,198 @@ declare class DashboardConversationHistory {
2889
4303
  }
2890
4304
  declare const dashboardConversationHistory: DashboardConversationHistory;
2891
4305
 
4306
+ /**
4307
+ * Whole-dashboard generation via Pi, a terminal coding agent — as opposed to
4308
+ * DASH_COMP_REQ's single-widget-at-a-time flow. Runs Pi in-process via its
4309
+ * SDK (createAgentSession), not as a subprocess: no shell, no argument
4310
+ * quoting, no stdin/stdout piping, none of the Windows-specific subprocess
4311
+ * issues that came with spawning the `pi` CLI directly.
4312
+ *
4313
+ * Called from sdk-nodejs/src/dashboardAgent/index.ts (DASHBOARD_AGENT_REQ),
4314
+ * which owns the generic streaming/abort machinery (mirrors USER_PROMPT_REQ)
4315
+ * and passes `signal`/`onProgress` alongside the normal params — this stays
4316
+ * within CollectionHandler's loose (params) => Promise<result> typing, no
4317
+ * change needed to that shared type.
4318
+ *
4319
+ * This mechanism is generic and reusable across any deployment. What's
4320
+ * genuinely project-specific — where AGENTS.md lives, which model to use —
4321
+ * is supplied via `DashboardAgentCollectionConfig`, with defaults sensible
4322
+ * enough that most callers don't need to override them (see below). The
4323
+ * data-source tool list and the dashboard's current state both come from
4324
+ * things sdk-nodejs already exposes generically: `sdk.getTools()` (whatever
4325
+ * this deployment registered via `sdk.setTools()`) and `sdk.callCollection
4326
+ * ('dashboards', 'query', ...)` (whatever this deployment already registered
4327
+ * under that name/shape) — no per-deployment callback needed for either.
4328
+ * Same convention on the way out: after a successful run, the prompt and the
4329
+ * full response text are handed to `sdk.callCollection('dashboard-agent-
4330
+ * conversations', 'create', ...)` if this deployment has registered one —
4331
+ * skipped silently otherwise, since conversation history is optional.
4332
+ *
4333
+ * Pi verifies every query against the live database itself (via whatever
4334
+ * local tool-execution bridge the deployment exposes, e.g. an HTTP bridge
4335
+ * on localhost), but does NOT persist the result itself — it writes the
4336
+ * finished DSL to an absolute path inside `runtimeDir`, told to it explicitly
4337
+ * in the prompt, and stops there. This handler reads that file after the run
4338
+ * finishes and returns its content as `dashboard` in the result. The caller
4339
+ * (frontend) is the one that actually saves it, via whatever authenticated
4340
+ * create/update path any other dashboard edit goes through — Pi has no user
4341
+ * session/auth context of its own, so persistence shouldn't happen from
4342
+ * inside it.
4343
+ *
4344
+ * Session persistence: the FIRST call for a dashboardId pays the full cost
4345
+ * (explore KB, discover schema, plan, verify, build). Every call after that
4346
+ * resumes the same session file (SessionManager.open) so Pi has everything
4347
+ * it already learned — it only needs to reason about the new, smaller ask,
4348
+ * not rediscover the whole dashboard from scratch. The session's file path
4349
+ * (AgentSession.sessionFile) is captured right after creation and persisted
4350
+ * in a small local file, keyed by dashboardId, inside `runtimeDir`.
4351
+ */
4352
+ interface DashboardAgentCollectionConfig {
4353
+ /**
4354
+ * Working directory Pi runs from — must contain AGENTS.md. This is a
4355
+ * version-controlled prompt file, so `cwd` is expected to live somewhere
4356
+ * like a `.prompts/` folder alongside the deployment's other prompts.
4357
+ * Default: `<process.cwd()>/.prompts/dashboard-agent` — the same
4358
+ * process.cwd()-based convention PromptLoader already uses for the main
4359
+ * agent's prompts, which needs no explicit override in the common case
4360
+ * (the backend process's own cwd already is its project root).
4361
+ */
4362
+ cwd?: string;
4363
+ /**
4364
+ * Where drafts/, the session-id map, and dashboard.log get written —
4365
+ * separate from `cwd` deliberately, so this deployment's runtime state
4366
+ * (regenerated per session, safe to gitignore) doesn't sit inside the
4367
+ * same folder as the version-controlled AGENTS.md prompt.
4368
+ * Default: `<process.cwd()>/.pi-dashboard-agent-runtime`.
4369
+ */
4370
+ runtimeDir?: string;
4371
+ /** Model provider (default: process.env.PI_AGENT_PROVIDER || 'openrouter'). */
4372
+ provider?: string;
4373
+ /** Model id (default: process.env.PI_AGENT_MODEL || 'anthropic/claude-sonnet-4.5'). */
4374
+ model?: string;
4375
+ /**
4376
+ * true (default): every request starts a brand-new pi session, with the 2
4377
+ * most recent prior responses (if any) injected into the prompt as
4378
+ * context — bounded cost per request, but pi re-explores schema/KB facts
4379
+ * it already verified in an earlier turn on this same dashboard.
4380
+ * false: resumes the same session file across requests on a given
4381
+ * dashboard — pi keeps everything it already learned, but context (and
4382
+ * cost) grows unbounded across turns (one observed turn: 2M+ cache-read
4383
+ * tokens after a handful of edits on the same dashboard).
4384
+ * Default: process.env.PI_AGENT_FRESH_SESSION !== 'false'.
4385
+ */
4386
+ freshSession?: boolean;
4387
+ }
4388
+ declare function registerDashboardAgentCollection(sdk: SuperatomSDK, config?: DashboardAgentCollectionConfig): void;
4389
+
4390
+ /**
4391
+ * ScriptMatcher — LLM-Based Script Matching + Parameter Extraction
4392
+ *
4393
+ * Uses ONE LLM call to:
4394
+ * 1. Pick the best matching script from the library (or "none")
4395
+ * 2. Extract parameter values from the user question
4396
+ *
4397
+ * Why LLM over embeddings:
4398
+ * - Embeddings capture topic similarity ("overstock" ≈ "inventory" ≈ "revenue")
4399
+ * but can't distinguish structurally different questions about the same domain
4400
+ * - LLM understands that "overstock by warehouse" needs a different script than
4401
+ * "revenue by warehouse" even though they're semantically close
4402
+ * - One call does both matching AND parameter extraction
4403
+ *
4404
+ * When script library grows past ~50, add an embedding pre-filter
4405
+ * (ChromaDB narrows to top 10 → LLM picks from those 10).
4406
+ */
4407
+
4408
+ declare class ScriptMatcher {
4409
+ private store;
4410
+ private collections?;
4411
+ private userId?;
4412
+ private trace?;
4413
+ constructor(store: ScriptStore, opts?: {
4414
+ collections?: any;
4415
+ userId?: string;
4416
+ trace?: RunTrace;
4417
+ });
4418
+ /**
4419
+ * Find the best matching script for a user question.
4420
+ * Uses ONE LLM call that picks the script AND extracts parameters.
4421
+ * Returns null if no script matches.
4422
+ *
4423
+ * Thin wrapper around `doMatch` whose only job is guaranteeing the trace
4424
+ * capture happens exactly once, on every exit path (short-circuit, normal
4425
+ * return, or the LLM call erroring) — see RunTrace.scriptMatcher.
4426
+ */
4427
+ match(userPrompt: string, apiKey?: string, model?: string, signal?: AbortSignal, activeBindings?: ScriptBinding[], conversationHistory?: string): Promise<ScriptMatch | null>;
4428
+ private doMatch;
4429
+ /**
4430
+ * Renders a recipe's declared parameters the same way in every prompt
4431
+ * section (catalog, active-script, edit candidates) so the LLM sees one
4432
+ * consistent format regardless of which block a script came from.
4433
+ */
4434
+ private formatParamList;
4435
+ /**
4436
+ * Semantic search over THIS user's own past prompts (`conversation-history`
4437
+ * ChromaDB embeddings, already user-scoped) — not a project-wide name/tag
4438
+ * search. Groups hits by the recipe that answered them, so a script gets
4439
+ * ONE catalog entry carrying every matched past question, not one per hit.
4440
+ *
4441
+ * Scope is deliberate (see SCRIPT-MATCH-IMPROVEMENTS.md, Change 2): a
4442
+ * script only shows up here because THIS user has, before, asked something
4443
+ * similar that it answered — not because some other user's question did.
4444
+ */
4445
+ private searchPromptHistory;
4446
+ /**
4447
+ * Build the script catalog string for the LLM prompt from prompt-history
4448
+ * matches: each script's declared parameters PLUS the actual past questions
4449
+ * of this user's that it answered (real precedent, not a hand-written
4450
+ * description) and what params they ran with.
4451
+ */
4452
+ private buildPromptHistoryCatalog;
4453
+ /**
4454
+ * The recent script-backed answers in this thread — the bounded set an edit
4455
+ * may target. Rendered as its own prompt section (never merged into the
4456
+ * ranked catalog) so the `edit` rules have an unambiguous referent set, and
4457
+ * numbered newest-first so the prompt's "prefer the most recent when the
4458
+ * instruction is ambiguous" tie-break has something to point at.
4459
+ *
4460
+ * Each entry carries the QUESTION that produced it plus the columns it
4461
+ * returned — that is what lets the matcher resolve "use the mode for the WSP
4462
+ * one" instead of blindly taking the newest.
4463
+ */
4464
+ private buildActiveScriptBlock;
4465
+ }
4466
+
4467
+ /**
4468
+ * ScriptRunner — Execute scripts in an isolated tsx subprocess.
4469
+ *
4470
+ * The subprocess approach replaces the earlier `new Function()` eval and gives us:
4471
+ * - Real sandbox (separate process, SIGKILL on timeout).
4472
+ * - Real TypeScript (tsx transpiles on the fly).
4473
+ * - npm imports available to scripts (clustering, stats, geo, etc.).
4474
+ *
4475
+ * Protocol: NDJSON over the child's stdin/stdout. See script-ipc.ts + backend/docs/SCRIPT-FLOW-IMPLEMENTATION.md.
4476
+ */
4477
+
4478
+ interface RunScriptOptions {
4479
+ /** Data sources the script is allowed to query via ctx.query */
4480
+ externalTools: ExternalTool[];
4481
+ /** Optional — for propagating per-query UI progress to the user */
4482
+ streamBuffer?: StreamBuffer;
4483
+ /** Override the wall-clock timeout (default `SCRIPT_TIMEOUT_MS`, 60s). */
4484
+ timeoutMs?: number;
4485
+ /**
4486
+ * Per-turn cancellation signal. When the user hits "Stop" mid-run, the child
4487
+ * process group is SIGKILLed and the run resolves as an aborted failure (the
4488
+ * caller is already unwinding, so the result is discarded).
4489
+ */
4490
+ signal?: AbortSignal;
4491
+ }
4492
+ /**
4493
+ * Execute a recipe by spawning a tsx child on the script's .ts file.
4494
+ * `scriptPath` is the absolute path to the saved `.ts` body.
4495
+ */
4496
+ declare function runScript(recipe: ScriptRecipe, scriptPath: string, params: Record<string, any>, options: RunScriptOptions): Promise<ScriptResult>;
4497
+
2892
4498
  type MessageTypeHandler = (message: IncomingMessage) => void | Promise<void>;
2893
4499
  declare class SuperatomSDK {
2894
4500
  private ws;
@@ -2924,6 +4530,8 @@ declare class SuperatomSDK {
2924
4530
  private lastPong;
2925
4531
  private readonly PING_INTERVAL_MS;
2926
4532
  private readonly PONG_TIMEOUT_MS;
4533
+ private pendingOutbox;
4534
+ private readonly MAX_OUTBOX_SIZE;
2927
4535
  constructor(config: SuperatomSDKConfig);
2928
4536
  /**
2929
4537
  * Initialize PromptLoader and load prompts into memory
@@ -2968,6 +4576,20 @@ declare class SuperatomSDK {
2968
4576
  * Does NOT throw on closed connections — callers can check the return value if needed.
2969
4577
  */
2970
4578
  send(message: Message): boolean;
4579
+ /**
4580
+ * Queue a message that couldn't be delivered because the socket was down,
4581
+ * to be resent once it reconnects. Drops the oldest entry once the bound is
4582
+ * hit — an outage long enough to fill this queue means the oldest queued
4583
+ * responses are for requests the caller has likely already given up on.
4584
+ */
4585
+ private queuePendingMessage;
4586
+ /**
4587
+ * Resend everything queued while the socket was down, now that it's back
4588
+ * up. Uses this.ws.send() directly (not send()) so a message that fails
4589
+ * again goes back through queuePendingMessage() rather than being silently
4590
+ * dropped a second time.
4591
+ */
4592
+ private flushPendingOutbox;
2971
4593
  /**
2972
4594
  * Register a message handler to receive all messages
2973
4595
  */
@@ -3007,6 +4629,14 @@ declare class SuperatomSDK {
3007
4629
  */
3008
4630
  private handlePong;
3009
4631
  private storeComponents;
4632
+ /**
4633
+ * The live, frontend-registered component catalog (name, type, description,
4634
+ * and full prop schema per component) — the same authoritative source
4635
+ * DASH_COMP_REQ's LLM prompt is built from. Exposed so other integrations
4636
+ * (e.g. the dashboard-agent script bridge) can read real component
4637
+ * contracts instead of maintaining a separate, driftable hand-written copy.
4638
+ */
4639
+ getComponents(): Component[];
3010
4640
  /**
3011
4641
  * Set tools for the SDK instance
3012
4642
  */
@@ -3015,6 +4645,16 @@ declare class SuperatomSDK {
3015
4645
  * Get the stored tools
3016
4646
  */
3017
4647
  getTools(): Tool$1[];
4648
+ /**
4649
+ * Call a registered collection operation in-process — no WebSocket
4650
+ * round-trip, since the caller is already running inside this same SDK
4651
+ * instance. Lets SDK-internal features (e.g. the dashboard agent) reuse
4652
+ * whatever collection a deployment has already registered (e.g.
4653
+ * 'dashboards'.'query') by name/convention, instead of requiring a
4654
+ * separate callback purely to re-expose data a collection already serves.
4655
+ * Throws if the collection or operation isn't registered.
4656
+ */
4657
+ callCollection<TResult = any>(collectionName: string, operation: string, params?: any): Promise<TResult>;
3018
4658
  /**
3019
4659
  * Register workflow components for the SDK instance.
3020
4660
  *
@@ -3058,4 +4698,4 @@ declare class SuperatomSDK {
3058
4698
  getConversationSimilarityThreshold(): number;
3059
4699
  }
3060
4700
 
3061
- export { type Action, type AgentConfig, type AgentResponse, BM25L, type BM25LOptions, type BaseLLMConfig, CONTEXT_CONFIG, type CapturedLog, CleanupService, type CollectionHandler, type CollectionOperation, type DBUIBlock, DEFAULT_AGENT_CONFIG, type DatabaseType, type HybridSearchOptions, type IncomingMessage, type KbNodesQueryFilters, type KbNodesRequestPayload, LLM, type LLMUsageEntry, type LogLevel, MainAgent, type Message, type ModelStrategy, type OutputField, type RerankedResult, STORAGE_CONFIG, type SelectedWorkflow, SuperatomSDK, type SuperatomSDKConfig, type TaskType, Thread, ThreadManager, type Tool$1 as Tool, type ToolOutputSchema, UIBlock, UILogCollector, type User, UserManager, type UsersData, type WorkflowDescriptor, anthropicLLM, dashboardConversationHistory, geminiLLM, groqLLM, hybridRerank, llmUsageLogger, logger, openaiLLM, queryCache, rerankChromaResults, rerankConversationResults, userPromptErrorLogger };
4701
+ export { type Action, type AgentConfig, type AgentResponse, BM25L, type BM25LOptions, type BaseLLMConfig, CONTEXT_CONFIG, type CapturedLog, CleanupService, type CollectionHandler, type CollectionOperation, type DBUIBlock, DEFAULT_AGENT_CONFIG, type DashboardAgentCollectionConfig, type DatabaseType, type HybridSearchOptions, type IncomingMessage, type KbNodesQueryFilters, type KbNodesRequestPayload, LLM, type LLMUsageEntry, type LogLevel, MainAgent, type Message, type ModelStrategy, type OutputField, type RerankedResult, STORAGE_CONFIG, type ScriptComponentSpec, ScriptMatcher, type ScriptParameter, type ScriptRecipe, type ScriptRecipeMetaRow, type ScriptRecipeStore, type ScriptResult, ScriptStore, type ScriptStoreOptions, type SelectedWorkflow, SuperatomSDK, type SuperatomSDKConfig, type TaskType, Thread, ThreadManager, type Tool$1 as Tool, type ToolOutputSchema, UIBlock, UILogCollector, type User, UserManager, type UsersData, type WorkflowDescriptor, anthropicLLM, dashboardConversationHistory, geminiLLM, groqLLM, hybridRerank, llmUsageLogger, logger, normalizeScriptBody, openaiLLM, queryCache, registerDashboardAgentCollection, rerankChromaResults, rerankConversationResults, resolveScriptRecipeStore, runScript, userPromptErrorLogger };