@mastra/libsql 1.19.0-alpha.0 → 1.19.0-alpha.1

package/CHANGELOG.md

@@ -1,5 +1,47 @@
 # @mastra/libsql
 
+## 1.19.0-alpha.1
+
+### Patch Changes
+
+- Stored workflow definitions now persist across restarts on every major database backend. ([#20471](https://github.com/mastra-ai/mastra/pull/20471))
+
+  Implement the `workflowDefinitions` storage domain for libsql, pg, mysql, mssql, mongodb, and spanner. Previously the stored-workflow persistence path (`POST /stored/workflows`, `Mastra.addStoredWorkflow`) only worked against `@mastra/core`'s in-memory store. Persistent adapters returned `undefined` from `storage.getStore('workflowDefinitions')` and threw when the HTTP handler tried to read/write a workflow.
+
+  ```ts
+  const workflowDefinitions = await storage.getStore('workflowDefinitions');
+  if (!workflowDefinitions) {
+    throw new Error('This storage adapter does not support the workflowDefinitions domain');
+  }
+
+  await workflowDefinitions.upsert({
+    id: 'greeting-workflow',
+    inputSchema: { type: 'object', properties: { name: { type: 'string' } }, required: ['name'] },
+    outputSchema: { type: 'object', properties: { text: { type: 'string' } }, required: ['text'] },
+    graph: [{ type: 'agent', id: 'greet', agentId: 'greeter-agent' }],
+  });
+
+  const { definitions, total } = await workflowDefinitions.list({ status: 'active' });
+  const definition = await workflowDefinitions.get('greeting-workflow');
+  await workflowDefinitions.delete('greeting-workflow');
+  ```
+
+  Each adapter now ships a `WorkflowDefinitions*` domain that:
+
+  - Creates the shared `mastra_workflow_definitions` table (or Mongo collection) from `WORKFLOW_DEFINITIONS_SCHEMA` during `init()`, plus a default index on `status`.
+  - Implements `upsert` / `get` / `list` / `delete` matching `WorkflowDefinitionsStorage` semantics (`list` supports `status` and `authorId` filters and orders by `updatedAt` desc). Partial upserts preserve unspecified fields, including `authorId` updates and `createdAt` / `updatedAt` semantics.
+  - Handles concurrent first-writes race-safely: if two callers upsert the same new id simultaneously, the losing insert detects the duplicate key, re-reads the row, and applies the partial-update path instead of failing.
+  - Round-trips the JSON columns (`inputSchema`, `outputSchema`, `stateSchema`, `requestContextSchema`, `metadata`, `graph`) through each adapter's JSON handling, so declarative workflow graphs rehydrate identically no matter which backend they were stored in. Malformed persisted JSON surfaces as an actionable error naming the row and column instead of hydrating raw strings.
+
+  Exported class names by adapter: `WorkflowDefinitionsLibSQL`, `WorkflowDefinitionsPG`, `WorkflowDefinitionsMySQL`, `WorkflowDefinitionsMSSQL`, `MongoDBWorkflowDefinitionsStore`, `WorkflowDefinitionsSpanner`. The composite stores (`LibSQLStore`, `PostgresStore`, `MySQLStore`, `MSSQLStore`, `MongoDBStore`, `SpannerStore`) auto-wire the new domain, so callers do not need to construct it manually — `storage.getStore('workflowDefinitions')` now returns a live handle.
+
+  The pg adapter reads `createdAt` / `updatedAt` from the auto-added `createdAtZ` / `updatedAtZ` `timestamptz` companion columns to avoid the naive-timestamp / local-TZ drift that a plain `TIMESTAMP` read exhibits under node-pg.
+
+  `@mastra/clickhouse` and `@mastra/cloudflare` register the new `mastra_workflow_definitions` table in their table/type maps so shared table constants stay exhaustive (no workflow-definitions domain implementation yet).
+
+- Updated dependencies [[`4844167`](https://github.com/mastra-ai/mastra/commit/4844167cff2d5ec5004e94edd34970833040fa3f), [`5faf93f`](https://github.com/mastra-ai/mastra/commit/5faf93f03e19daea394b9e2a923f2e4f833407f2), [`80ad891`](https://github.com/mastra-ai/mastra/commit/80ad891f8cd10379aa5b5af7510c763783b2ab56), [`a1cb98d`](https://github.com/mastra-ai/mastra/commit/a1cb98d11990b560b98482292a1f34aa1a2d9092), [`598ad82`](https://github.com/mastra-ai/mastra/commit/598ad82d41c41389a686338a1d0e50b7400e1938), [`1fd6aad`](https://github.com/mastra-ai/mastra/commit/1fd6aad1ea4a9d32f65efa832307c35e981a4c0a)]:
+  - @mastra/core@1.56.0-alpha.4
+
 ## 1.19.0-alpha.0
 
 ### Minor Changes

package/dist/docs/SKILL.md

@@ -3,7 +3,7 @@ name: mastra-libsql
 description: Documentation for @mastra/libsql. Use when working with @mastra/libsql APIs, configuration, or implementation.
 metadata:
   package: "@mastra/libsql"
-  version: "1.19.0-alpha.0"
+  version: "1.19.0-alpha.1"
 ---
 
 ## When to use

package/dist/docs/assets/SOURCE_MAP.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.19.0-alpha.0",
+  "version": "1.19.0-alpha.1",
   "package": "@mastra/libsql",
   "exports": {},
   "modules": {}

package/dist/docs/references/docs-agents-agent-approval.md

@@ -108,7 +108,7 @@ A tool's own `requireApproval` setting takes precedence over the function above.
 
 For sensitive tools, bind the approval to the exact tool name and arguments that were shown to the reviewer. If those arguments drift before execution, the tool shouldn't run under the old approval.
 
-The `tool-call-approval` chunk already includes `toolName`, `toolCallId`, and `args`. You can fingerprint those fields when the approval request is shown. The example below uses a simple JSON string as the fingerprint, but in production you should use a stable hash of the tool name and arguments:
+The `tool-call-approval` chunk already includes `toolName`, `toolCallId`, and `args`. You can fingerprint those fields when the approval request is shown. The example below uses a JSON string as the fingerprint, but in production you should use a stable hash of the tool name and arguments:
 
 ```typescript
 import { Agent } from '@mastra/core/agent'
@@ -174,7 +174,7 @@ async function approveReviewedToolCall(runId: string, toolCallId: string, finger
 await consumeApprovalStream(stream)
 ```
 
-In production, store the approved fingerprint in durable storage scoped to the user, run, tool call, and policy version. The `Set` above is intentionally small so the boundary is easy to see: the approval is consumed once, and only for the same canonical tool arguments that were reviewed.
+In production, store the approved fingerprint in durable storage scoped to the user, run, tool call, and policy version. The `Set` above is intentionally small so the boundary is clear: the approval is consumed once, and only for the same canonical tool arguments that were reviewed.
 
 ### Runtime suspension with `suspend()`
 

package/dist/docs/references/docs-deployment-workers.md

@@ -17,7 +17,7 @@ Workers matter when any of these apply:
 - Different parts of the system need to scale independently (e.g., more orchestration capacity without more API instances)
 - Background tool calls should run on dedicated compute
 
-If your application handles light traffic and workflows complete quickly, the default in-process setup works fine. Skip the worker infrastructure until you need it.
+If your application handles light traffic and workflows complete fast, the default in-process setup works fine. Skip the worker infrastructure until you need it.
 
 ## Worker types
 
@@ -33,11 +33,11 @@ The orchestration worker requires a PubSub backend that supports pull mode (e.g.
 
 ### Scheduler worker
 
-Polls storage for due cron schedules and publishes `workflow.start` events. It is a producer only, meaning it creates work for the orchestration worker to pick up.
+Polls storage for due cron schedules and publishes `workflow.start` events. It's a producer only, meaning it creates work for the orchestration worker to pick up.
 
 The scheduler reads declarative `schedule` fields from your workflow definitions automatically. See [Scheduled workflows](https://mastra.ai/docs/workflows/scheduled-workflows) for how to declare schedules.
 
-**Do not run more than one scheduler instance.** Multiple schedulers polling the same storage would fire duplicate events for the same schedule.
+**Don't run more than one scheduler instance.** Multiple schedulers polling the same storage would fire duplicate events for the same schedule.
 
 ### Background task worker
 
@@ -47,7 +47,7 @@ The background task worker manages concurrency limits, task lifecycle, and resul
 
 ## How workers run
 
-### In-process (default)
+### In-process mode (default)
 
 With no configuration, Mastra creates and starts workers inside the API process. Events flow through an in-memory PubSub, and everything shares a single Node.js runtime.
 
@@ -64,7 +64,7 @@ This setup needs no external infrastructure beyond your storage adapter. It does
 
 ### Split processes
 
-To run workers separately, configure a distributed [PubSub](https://mastra.ai/docs/server/pubsub) backend and use the `MASTRA_WORKERS` environment variable to control which workers start in each process.
+To run workers in their own processes, configure a distributed [PubSub](https://mastra.ai/docs/server/pubsub) backend and use the `MASTRA_WORKERS` environment variable to control which workers start in each process.
 
 **Redis Streams + PostgreSQL**:
 
@@ -100,38 +100,38 @@ export const mastra = new Mastra({
 })
 ```
 
-Any [supported storage backend](https://mastra.ai/reference/workers/overview) works — swap the storage adapter for your preferred database.
+Any [supported storage backend](https://mastra.ai/reference/workers/overview) works. Swap the storage adapter for your preferred database.
 
 Run the same build artifact in multiple containers, each with a different [`MASTRA_WORKERS`](https://mastra.ai/reference/workers/overview) value to control which worker starts in each process.
 
 Split deployments require a distributed PubSub backend ([`RedisStreamsPubSub`](https://mastra.ai/reference/pubsub/redis-streams) or [`GoogleCloudPubSub`](https://mastra.ai/reference/pubsub/google-cloud-pubsub)), a shared [storage backend](https://mastra.ai/reference/workers/overview), and network connectivity between the orchestration worker and the API.
 
-The [worker deployment guide](https://mastra.ai/guides/deployment/mastra-workers) walks through this setup with a Docker Compose example.
+The [worker deployment guide](https://mastra.ai/guides/deployment/mastra-workers) walks through this setup with Docker Compose and Kubernetes examples.
 
 ## Network architecture
 
-Workers are internal infrastructure. They are not exposed to end users and do not need their own subdomain, public URL, or inbound HTTP route.
+Workers are internal infrastructure. They're not exposed to end users and don't need their own subdomain, public URL, or inbound HTTP route.
 
 In a split deployment:
 
-- **The API server is the only public-facing process.** It serves all client HTTP requests — REST endpoints, agent interactions, workflow triggers, and any custom routes.
-- **Workers connect outbound only.** They pull events from the distributed PubSub backend and read/write to the shared storage database. They do not accept inbound traffic from clients.
-- **The orchestration worker calls the API internally.** It sends step execution requests to the API over the container network using `MASTRA_STEP_EXECUTION_URL`. This is internal service-to-service communication, not a public endpoint.
+- **The API server is the only public-facing process**: It serves all client HTTP requests, including REST endpoints, agent interactions, workflow triggers, and any custom routes.
+- **Workers connect outbound only**: They pull events from the distributed PubSub backend and read/write to the shared storage database. They don't accept inbound traffic from clients.
+- **The orchestration worker calls the API internally**: It sends step execution requests to the API over the container network using `MASTRA_STEP_EXECUTION_URL`. This is internal service-to-service communication, not a public endpoint.
 
 All three worker types (orchestration, scheduler, background task) sit behind the API on a private network. They share access to the PubSub backend and storage database but never receive traffic directly from clients. If a worker-related feature needs an HTTP route (for example, token minting for a voice integration), that route runs on the API server, not on the worker process.
 
 ## Known limitations
 
-- **No dead-letter queue**: Failed events are nacked and retried, but there is no DLQ for events that repeatedly fail.
+- **No dead-letter queue**: Failed events are nacked and retried, but there's no DLQ for events that fail after all retries.
 - **No built-in health endpoint**: Workers don't expose an HTTP health check. Use container-level liveness probes or process monitoring.
 - **Scheduler is single-instance**: Running multiple scheduler processes causes duplicate schedule fires.
 - **Runs stuck in "running" after API crash**: If the API process crashes while executing a workflow step, the run remains in `running` status with no automatic retry. For [durable agents](https://mastra.ai/docs/long-running-agents/durable-agents), set `recovery.durableAgents` to `'auto'` in the Mastra config to automatically re-drive orphaned runs on server restart. See [Crash recovery](https://mastra.ai/docs/long-running-agents/durable-agents) for details.
 
 ## Related
 
-- [Worker deployment guide](https://mastra.ai/guides/deployment/mastra-workers): Docker Compose example and topology options
+- [Worker deployment guide](https://mastra.ai/guides/deployment/mastra-workers): Docker Compose and Kubernetes examples
 - [Worker authentication](https://mastra.ai/docs/server/auth/workers): Secure worker-to-API communication
-- [Workers reference](https://mastra.ai/reference/workers/overview): Environment variables, worker types, and storage backends
+- [Workers reference](https://mastra.ai/reference/workers/overview): Details about worker environment variables and types, with a list of supported storage backends
 - [CLI reference](https://mastra.ai/reference/cli/mastra): `mastra worker build` and `mastra worker start`
 - [PubSub](https://mastra.ai/docs/server/pubsub): Event delivery backends
 - [Scheduled workflows](https://mastra.ai/docs/workflows/scheduled-workflows): Declare cron schedules on workflows

package/dist/docs/references/docs-memory-overview.md

@@ -172,6 +172,20 @@ export const memoryAgent = new Agent({
 
 See [Observational Memory](https://mastra.ai/docs/memory/observational-memory) for details on how observations and reflections work, and [the reference](https://mastra.ai/reference/memory/observational-memory) for all configuration options.
 
+## What the model sees
+
+Each memory feature is added to either the system messages or the conversation messages in the request sent to the model. The layers depend on the features you've enabled. Working memory and semantic recall only appear when configured. The same applies to Observational Memory, while message history is on by default. The diagram shows where each enabled layer is placed in the request. The list below describes what each layer contributes:
+
+![Diagram showing how Mastra assembles the model context: system messages containing agent instructions, call-time system messages, working memory, cross-thread semantic recall, and Observational Memory, followed by conversation messages where message history and same-thread semantic recall interleave by timestamp, then call-time context messages, and finally the new user message](/img/memory/memory-context-window-light.svg)
+
+- [Working memory](https://mastra.ai/docs/memory/working-memory) is injected as a system message containing the template and the stored data. With `useStateSignals`, it's delivered as a state signal instead.
+- [Semantic recall](https://mastra.ai/docs/memory/semantic-recall) matches from the current thread are inserted as regular messages and interleave with message history by timestamp. Matches from other threads are formatted into a system message instead.
+- [Message history](https://mastra.ai/docs/memory/message-history) adds the last N messages in chronological order. Your new message always comes last.
+- [Observational Memory](https://mastra.ai/docs/memory/observational-memory) replaces old raw history: reflections and observations live in a system message, and only messages that haven't been observed yet remain in the conversation. A short continuation reminder is placed at the start of the conversation messages.
+- Context messages are the optional `context` array passed on a call, for example `agent.generate(msg, { context: [...] })`. Use them for one-off background such as app state or your own RAG results. They appear as regular conversation messages for that request only and are never saved to memory.
+
+Conversation messages are ordered by timestamp and deduplicated by message ID, so recalled older messages appear before recent history. Context messages passed at call time are stamped with the current time, which places them after history and recall but before your new message. To inspect the exact context for a real request, use [Tracing](https://mastra.ai/docs/observability/tracing/overview) and open the LLM call spans, see [Observability](#observability) below.
+
 ## Memory in multi-agent systems
 
 When a [supervisor agent](https://mastra.ai/docs/agents/supervisor-agents) delegates to a subagent, Mastra isolates subagent memory automatically. No flag enables this as it happens on every delegation. Understanding how this scoping works lets you decide what stays private and what to share intentionally.

package/dist/docs/references/reference-core-mastra-class.md

@@ -135,7 +135,7 @@ Visit the [Configuration reference](https://mastra.ai/reference/configuration) f
 
 Re-drives every orphaned `running` durable-agent run across all registered durable agents. Called automatically on boot when `recovery.durableAgents` is `'auto'`. You can also call it directly for manual recovery or from a scheduled task.
 
-Requires persistent storage — with an in-memory store there is nothing to recover after a process restart.
+Requires persistent storage. With an in-memory store, there's nothing to recover after a process restart.
 
 ```typescript
 const result = await mastra.recoverAllDurableAgents()

package/dist/index.cjs

@@ -2854,7 +2854,7 @@ function serializeJson(v) {
 	if (typeof v === "object" && v != null) return JSON.stringify(v);
 	return v ?? null;
 }
-function parseJson$2(val) {
+function parseJson$3(val) {
 	if (val == null) return void 0;
 	if (typeof val === "string") try {
 		return JSON.parse(val);
@@ -2869,14 +2869,14 @@ function rowToTask(row) {
 		status: String(row.status),
 		toolName: String(row.tool_name),
 		toolCallId: String(row.tool_call_id),
-		args: parseJson$2(row.args) ?? {},
+		args: parseJson$3(row.args) ?? {},
 		agentId: String(row.agent_id),
 		threadId: row.thread_id != null ? String(row.thread_id) : void 0,
 		resourceId: row.resource_id != null ? String(row.resource_id) : void 0,
 		runId: String(row.run_id),
-		result: parseJson$2(row.result),
-		error: parseJson$2(row.error),
-		suspendPayload: parseJson$2(row.suspend_payload),
+		result: parseJson$3(row.result),
+		error: parseJson$3(row.error),
+		suspendPayload: parseJson$3(row.suspend_payload),
 		retryCount: Number(row.retry_count),
 		maxRetries: Number(row.max_retries),
 		timeoutMs: Number(row.timeout_ms),
@@ -8530,7 +8530,7 @@ const statusTimestamp = (status, now) => {
 	if (status === "discarded") return { discardedAt: now };
 	return {};
 };
-function parseJson$1(value) {
+function parseJson$2(value) {
 	if (value == null) return void 0;
 	if (typeof value === "string") try {
 		return JSON.parse(value);
@@ -8552,14 +8552,14 @@ function rowToNotification(row) {
 		priority: String(row.priority),
 		status: String(row.status),
 		summary: String(row.summary),
-		payload: parseJson$1(row.payload),
+		payload: parseJson$2(row.payload),
 		resourceId: row.resourceId == null ? void 0 : String(row.resourceId),
 		agentId: row.agentId == null ? void 0 : String(row.agentId),
 		sourceId: row.sourceId == null ? void 0 : String(row.sourceId),
 		dedupeKey: row.dedupeKey == null ? void 0 : String(row.dedupeKey),
 		coalesceKey: row.coalesceKey == null ? void 0 : String(row.coalesceKey),
 		coalescedCount: Number(row.coalescedCount ?? 1),
-		attributes: parseJson$1(row.attributes),
+		attributes: parseJson$2(row.attributes),
 		createdAt: new Date(String(row.createdAt)),
 		updatedAt: new Date(String(row.updatedAt)),
 		deliveredAt: parseDate(row.deliveredAt),
@@ -8575,7 +8575,7 @@ function rowToNotification(row) {
 		lastDeliveryError: row.lastDeliveryError == null ? void 0 : String(row.lastDeliveryError),
 		deliveredSignalId: row.deliveredSignalId == null ? void 0 : String(row.deliveredSignalId),
 		summarySignalId: row.summarySignalId == null ? void 0 : String(row.summarySignalId),
-		metadata: parseJson$1(row.metadata)
+		metadata: parseJson$2(row.metadata)
 	};
 }
 function addArrayFilter(conditions, args, column, value) {
@@ -9766,7 +9766,7 @@ var PromptBlocksLibSQL = class extends _mastra_core_storage.PromptBlocksStorage
 };
 //#endregion
 //#region src/storage/domains/schedules/index.ts
-function parseJson(val) {
+function parseJson$1(val) {
 	if (val == null) return void 0;
 	if (typeof val === "string") try {
 		return JSON.parse(val);
@@ -9780,7 +9780,7 @@ function toNumber(val) {
 	return Number(val);
 }
 function rowToSchedule(row) {
-	const target = parseJson(row.target);
+	const target = parseJson$1(row.target);
 	if (!target) throw new Error(`Schedule row ${row.id} has invalid target`);
 	const schedule = {
 		id: String(row.id),
@@ -9794,7 +9794,7 @@ function rowToSchedule(row) {
 	if (row.timezone != null) schedule.timezone = String(row.timezone);
 	if (row.last_fire_at != null) schedule.lastFireAt = toNumber(row.last_fire_at);
 	if (row.last_run_id != null) schedule.lastRunId = String(row.last_run_id);
-	const metadata = parseJson(row.metadata);
+	const metadata = parseJson$1(row.metadata);
 	if (metadata !== void 0) schedule.metadata = metadata;
 	if (row.owner_type != null) schedule.ownerType = String(row.owner_type);
 	if (row.owner_id != null) schedule.ownerId = String(row.owner_id);
@@ -9812,7 +9812,7 @@ function rowToTrigger(row) {
 	};
 	if (row.error != null) trigger.error = String(row.error);
 	if (row.parent_trigger_id != null) trigger.parentTriggerId = String(row.parent_trigger_id);
-	const metadata = parseJson(row.metadata);
+	const metadata = parseJson$1(row.metadata);
 	if (metadata !== void 0) trigger.metadata = metadata;
 	return trigger;
 }
@@ -11693,6 +11693,159 @@ var ToolProviderConnectionsLibSQL = class extends _mastra_core_storage.ToolProvi
 	}
 };
 //#endregion
+//#region src/storage/domains/workflow-definitions/index.ts
+function parseJson(val, column, rowId) {
+	if (val == null) return void 0;
+	if (typeof val === "string") try {
+		return JSON.parse(val);
+	} catch {
+		throw new Error(`Workflow definition row "${String(rowId)}" has malformed JSON in column "${column}".`);
+	}
+	return val;
+}
+function rowToDefinition(row) {
+	const inputSchema = parseJson(row.inputSchema, "inputSchema", row.id);
+	const outputSchema = parseJson(row.outputSchema, "outputSchema", row.id);
+	const graph = parseJson(row.graph, "graph", row.id);
+	if (inputSchema === void 0 || outputSchema === void 0 || graph === void 0) throw new Error(`Workflow definition row "${row.id}" is missing required JSON columns.`);
+	const def = {
+		id: String(row.id),
+		inputSchema,
+		outputSchema,
+		graph,
+		status: row.status,
+		source: row.source,
+		createdAt: new Date(row.createdAt),
+		updatedAt: new Date(row.updatedAt)
+	};
+	if (row.description != null) def.description = String(row.description);
+	const metadata = parseJson(row.metadata, "metadata", row.id);
+	if (metadata !== void 0) def.metadata = metadata;
+	const stateSchema = parseJson(row.stateSchema, "stateSchema", row.id);
+	if (stateSchema !== void 0) def.stateSchema = stateSchema;
+	const requestContextSchema = parseJson(row.requestContextSchema, "requestContextSchema", row.id);
+	if (requestContextSchema !== void 0) def.requestContextSchema = requestContextSchema;
+	if (row.authorId != null) def.authorId = String(row.authorId);
+	return def;
+}
+var WorkflowDefinitionsLibSQL = class extends _mastra_core_storage.WorkflowDefinitionsStorage {
+	#db;
+	#client;
+	constructor(config) {
+		super();
+		const client = resolveClient(config);
+		this.#client = client;
+		this.#db = new LibSQLDB({
+			client,
+			maxRetries: config.maxRetries,
+			initialBackoffMs: config.initialBackoffMs
+		});
+	}
+	async init() {
+		await this.#db.createTable({
+			tableName: _mastra_core_storage.TABLE_WORKFLOW_DEFINITIONS,
+			schema: _mastra_core_storage.TABLE_SCHEMAS[_mastra_core_storage.TABLE_WORKFLOW_DEFINITIONS]
+		});
+		await this.#client.execute({
+			sql: `CREATE INDEX IF NOT EXISTS idx_workflow_definitions_status ON "${_mastra_core_storage.TABLE_WORKFLOW_DEFINITIONS}" ("status")`,
+			args: []
+		});
+	}
+	async dangerouslyClearAll() {
+		await this.#db.deleteData({ tableName: _mastra_core_storage.TABLE_WORKFLOW_DEFINITIONS });
+	}
+	async upsert(input) {
+		const now = /* @__PURE__ */ new Date();
+		if (!await this.get(input.id)) {
+			if (!("inputSchema" in input) || !input.inputSchema) throw new Error(`Cannot create workflow definition "${input.id}": inputSchema is required.`);
+			if (!("outputSchema" in input) || !input.outputSchema) throw new Error(`Cannot create workflow definition "${input.id}": outputSchema is required.`);
+			if (!("graph" in input) || !input.graph) throw new Error(`Cannot create workflow definition "${input.id}": graph is required.`);
+			const record = {
+				id: input.id,
+				description: input.description ?? null,
+				metadata: input.metadata ?? null,
+				inputSchema: input.inputSchema,
+				outputSchema: input.outputSchema,
+				stateSchema: input.stateSchema ?? null,
+				requestContextSchema: input.requestContextSchema ?? null,
+				graph: input.graph,
+				status: "active",
+				source: "storage",
+				authorId: "authorId" in input ? input.authorId ?? null : null,
+				createdAt: now,
+				updatedAt: now
+			};
+			try {
+				await this.#db.insertOnly({
+					tableName: _mastra_core_storage.TABLE_WORKFLOW_DEFINITIONS,
+					record
+				});
+			} catch (error) {
+				if (!await this.get(input.id)) throw error;
+				return this.#applyUpdate(input, now);
+			}
+			const created = await this.get(input.id);
+			if (!created) throw new Error(`Failed to persist workflow definition "${input.id}".`);
+			return created;
+		}
+		return this.#applyUpdate(input, now);
+	}
+	async #applyUpdate(input, now) {
+		const data = { updatedAt: now };
+		if ("description" in input && input.description !== void 0) data.description = input.description;
+		if ("metadata" in input && input.metadata !== void 0) data.metadata = input.metadata;
+		if ("inputSchema" in input && input.inputSchema !== void 0) data.inputSchema = input.inputSchema;
+		if ("outputSchema" in input && input.outputSchema !== void 0) data.outputSchema = input.outputSchema;
+		if ("stateSchema" in input && input.stateSchema !== void 0) data.stateSchema = input.stateSchema;
+		if ("requestContextSchema" in input && input.requestContextSchema !== void 0) data.requestContextSchema = input.requestContextSchema;
+		if ("graph" in input && input.graph !== void 0) data.graph = input.graph;
+		if ("status" in input && input.status !== void 0) data.status = input.status;
+		if ("authorId" in input && input.authorId !== void 0) data.authorId = input.authorId;
+		await this.#db.update({
+			tableName: _mastra_core_storage.TABLE_WORKFLOW_DEFINITIONS,
+			keys: { id: input.id },
+			data
+		});
+		const updated = await this.get(input.id);
+		if (!updated) throw new Error(`Failed to update workflow definition "${input.id}".`);
+		return updated;
+	}
+	async get(id) {
+		const row = (await this.#client.execute({
+			sql: `SELECT ${buildSelectColumns(_mastra_core_storage.TABLE_WORKFLOW_DEFINITIONS)} FROM "${_mastra_core_storage.TABLE_WORKFLOW_DEFINITIONS}" WHERE id = ?`,
+			args: [id]
+		})).rows[0];
+		return row ? rowToDefinition(row) : null;
+	}
+	async list(args) {
+		const conditions = [];
+		const params = [];
+		if (args?.status) {
+			conditions.push("status = ?");
+			params.push(args.status);
+		}
+		if (args?.authorId !== void 0) {
+			conditions.push("authorId = ?");
+			params.push(args.authorId);
+		}
+		const where = conditions.length > 0 ? `WHERE ${conditions.join(" AND ")}` : "";
+		const definitions = (await this.#client.execute({
+			sql: `SELECT ${buildSelectColumns(_mastra_core_storage.TABLE_WORKFLOW_DEFINITIONS)} FROM "${_mastra_core_storage.TABLE_WORKFLOW_DEFINITIONS}" ${where} ORDER BY updatedAt DESC`,
+			args: params
+		})).rows.map((row) => rowToDefinition(row));
+		return {
+			definitions,
+			total: definitions.length
+		};
+	}
+	async delete(id) {
+		await this.#client.execute({
+			sql: `DELETE FROM "${_mastra_core_storage.TABLE_WORKFLOW_DEFINITIONS}" WHERE id = ?`,
+			args: [id]
+		});
+	}
+};
+//#endregion
 //#region src/storage/domains/workflows/index.ts
 var WorkflowsLibSQL = class WorkflowsLibSQL extends _mastra_core_storage.WorkflowsStorage {
 	/**
@@ -12987,6 +13140,7 @@ var LibSQLStore = class extends _mastra_core_storage.MastraCompositeStore {
 		};
 		const scores = new ScoresLibSQL(domainConfig);
 		const workflows = new WorkflowsLibSQL(domainConfig);
+		const workflowDefinitions = new WorkflowDefinitionsLibSQL(domainConfig);
 		const memory = new MemoryLibSQL(domainConfig);
 		const observability = new ObservabilityLibSQL(domainConfig);
 		const agents = new AgentsLibSQL(domainConfig);
@@ -13010,6 +13164,7 @@ var LibSQLStore = class extends _mastra_core_storage.MastraCompositeStore {
 		this.stores = {
 			scores,
 			workflows,
+			workflowDefinitions,
 			memory,
 			observability,
 			agents,
@@ -13223,6 +13378,7 @@ exports.ScoresLibSQL = ScoresLibSQL;
 exports.SkillsLibSQL = SkillsLibSQL;
 exports.ThreadStateLibSQL = ThreadStateLibSQL;
 exports.ToolProviderConnectionsLibSQL = ToolProviderConnectionsLibSQL;
+exports.WorkflowDefinitionsLibSQL = WorkflowDefinitionsLibSQL;
 exports.WorkflowsLibSQL = WorkflowsLibSQL;
 exports.WorkspacesLibSQL = WorkspacesLibSQL;