\n\n \n\n \n \n\n\n `;\n return c.html(html);\n});\n\n// ============================================================================\n// Export for Val Town HTTP\n// ============================================================================\n\nexport default app.fetch; // This is the entry point for HTTP vals",[],[268,274],{"_106":282,"_96":283,"_161":284,"_163":269,"_164":144,"_165":166,"_167":120,"_108":285,"_102":32,"_169":286,"_171":287,"_172":22,"_173":-5,"_174":288,"_100":289},"ae1aeff8-c55f-11f0-a174-42dde27851f2","cron-trigger.ts","019a9cd0-c1e3-73bc-99fb-efe3ff367c31",["D",1763567518186],"interval","/**\n * Example: Triggering workflows from a Cron val\n *\n * This demonstrates how to use the workflow engine from a Val Town Cron trigger.\n * Schedule this as a cron val to run workflows periodically.\n */\n\nimport { greetingWorkflow } from \"./simple-workflow.ts\";\n\nexport default async function (_interval: Interval) {\n\tconsole.log(`Cron triggered at ${new Date().toISOString()}`);\n\n\t// Example: Process a batch of users\n\tconst userIds = [\"user-1\", \"user-2\", \"user-3\"];\n\n\tconst results = [];\n\n\tfor (const userId of userIds) {\n\t\ttry {\n\t\t\tconst run = await greetingWorkflow.createRun();\n\n\t\t\tconst result = await run.start({\n\t\t\t\tinputData: { userId },\n\t\t\t});\n\n\t\t\tresults.push({\n\t\t\t\tuserId,\n\t\t\t\tsuccess: true,\n\t\t\t\trunId: run.runId,\n\t\t\t\tresult,\n\t\t\t});\n\n\t\t\tconsole.log(`✅ Processed ${userId}: ${result.messageId}`);\n\t\t} catch (error) {\n\t\t\tresults.push({\n\t\t\t\tuserId,\n\t\t\t\tsuccess: false,\n\t\t\t\terror: error instanceof Error ? error.message : String(error),\n\t\t\t});\n\n\t\t\tconsole.error(`❌ Failed to process ${userId}:`, error);\n\t\t}\n\t}\n\n\tconsole.log(`\\nProcessed ${results.length} users`);\n\tconsole.log(`Success: ${results.filter((r) => r.success).length}`);\n\tconsole.log(`Failed: ${results.filter((r) => !r.success).length}`);\n\n\treturn results;\n}\n",[],[268,283],{"_106":291,"_96":292,"_161":293,"_163":269,"_164":144,"_165":166,"_167":120,"_108":294,"_102":32,"_169":277,"_171":295,"_172":22,"_173":-5,"_174":296,"_100":297},"ae1af1ba-c55f-11f0-a174-42dde27851f2","http-trigger.ts","019a9cd0-c1e3-73bc-99fb-f29f1504741a",["D",1763567518186],"/**\n * Example: Triggering a workflow from an HTTP val\n *\n * This demonstrates how to use the workflow engine from a Val Town HTTP trigger.\n * Deploy this as an HTTP val to trigger workflows via HTTP requests.\n */\n\nimport { greetingWorkflow } from \"./simple-workflow.ts\";\n\nexport default async function (req: Request): Promise {\n\tconst url = new URL(req.url);\n\n\t// Get userId from query params\n\tconst userId = url.searchParams.get(\"userId\");\n\n\tif (!userId) {\n\t\treturn Response.json(\n\t\t\t{ error: \"Missing userId parameter\" },\n\t\t\t{ status: 400 },\n\t\t);\n\t}\n\n\ttry {\n\t\t// Create and start a workflow run\n\t\tconst run = await greetingWorkflow.createRun();\n\n\t\tconst result = await run.start({\n\t\t\tinputData: { userId },\n\t\t});\n\n\t\t// Get the snapshot for debugging info\n\t\tconst snapshot = await run.getSnapshot();\n\n\t\treturn Response.json({\n\t\t\tsuccess: true,\n\t\t\trunId: run.runId,\n\t\t\tresult,\n\t\t\tsteps: Object.keys(snapshot?.stepResults || {}),\n\t\t\tstatus: snapshot?.status,\n\t\t});\n\t} catch (error) {\n\t\treturn Response.json(\n\t\t\t{\n\t\t\t\tsuccess: false,\n\t\t\t\terror: error instanceof Error ? error.message : String(error),\n\t\t\t},\n\t\t\t{ status: 500 },\n\t\t);\n\t}\n}\n",[],[268,292],{"_106":299,"_96":300,"_161":301,"_163":269,"_164":144,"_165":166,"_167":120,"_108":302,"_102":32,"_169":181,"_171":303,"_172":22,"_173":-5,"_174":304,"_100":305},"ae1af566-c55f-11f0-a174-42dde27851f2","prebuilt-steps-simple.ts","019a9cd0-c1e3-73bc-99fb-f473ce581211",["D",1763567518186],"/**\n * Simple examples demonstrating prebuilt workflow steps\n *\n * Each example shows a practical use case for the prebuilt steps\n */\n\nimport { z } from \"npm:zod@^3.23\";\nimport {\n\tcreateStep,\n\tcreateWorkflow,\n\tdelay,\n\tfilterArray,\n\thttpGet,\n\tlogger,\n\tmapArray,\n\tpickFields,\n\ttemplate,\n} from \"../backend/index.ts\";\n\n// ============================================================================\n// Example 1: API Data Processing\n// ============================================================================\n\n/**\n * Fetch data from JSONPlaceholder API and process it\n */\nconst apiDataWorkflow = createWorkflow({\n\tid: \"api-data-processing\",\n\tdescription: \"Fetch and process posts from JSONPlaceholder API\",\n\tinputSchema: z.object({\n\t\turl: z.string().url(),\n\t}),\n\toutputSchema: z.object({\n\t\tstatus: z.number(),\n\t\tdata: z.unknown(),\n\t\theaders: z.record(z.string()),\n\t}),\n})\n\t.then(httpGet)\n\t.commit();\n\n// ============================================================================\n// Example 2: Template String Generation\n// ============================================================================\n\nconst templateWorkflow = createWorkflow({\n\tid: \"template-generation\",\n\tdescription: \"Generate personalized message from template\",\n\tinputSchema: z.object({\n\t\ttemplate: z.string(),\n\t\tvariables: z.record(z.union([z.string(), z.number(), z.boolean()])),\n\t}),\n\toutputSchema: z.object({\n\t\tresult: z.string(),\n\t}),\n})\n\t.then(template)\n\t.commit();\n\n// ============================================================================\n// Example 3: Array Filtering\n// ============================================================================\n\nconst filterWorkflow = createWorkflow({\n\tid: \"filter-workflow\",\n\tdescription: \"Filter array of numbers\",\n\tinputSchema: z.object({\n\t\tarray: z.array(z.unknown()),\n\t\tfilterFn: z.string(),\n\t}),\n\toutputSchema: z.object({\n\t\tfiltered: z.array(z.unknown()),\n\t\toriginalCount: z.number(),\n\t\tfilteredCount: z.number(),\n\t}),\n})\n\t.then(filterArray)\n\t.commit();\n\n// ============================================================================\n// Example 4: Multi-step workflow with custom steps\n// ============================================================================\n\n// Custom step to prepare API request\nconst prepareRequest = createStep({\n\tid: \"prepare-request\",\n\tinputSchema: z.object({\n\t\tuserId: z.number(),\n\t}),\n\toutputSchema: z.object({\n\t\turl: z.string().url(),\n\t\theaders: z.record(z.string()).optional(),\n\t\tqueryParams: z.record(z.string()).optional(),\n\t}),\n\texecute: async ({ inputData }) => {\n\t\treturn {\n\t\t\turl: `https://jsonplaceholder.typicode.com/posts`,\n\t\t\tqueryParams: {\n\t\t\t\tuserId: String(inputData.userId),\n\t\t\t},\n\t\t};\n\t},\n});\n\n// Custom step to extract titles\nconst extractTitles = createStep({\n\tid: \"extract-titles\",\n\tinputSchema: z.object({\n\t\tstatus: z.number(),\n\t\tdata: z.unknown(),\n\t\theaders: z.record(z.string()),\n\t}),\n\toutputSchema: z.object({\n\t\tarray: z.array(z.unknown()),\n\t\tmapFn: z.string(),\n\t}),\n\texecute: async ({ inputData }) => {\n\t\tconst posts = inputData.data as any[];\n\t\treturn {\n\t\t\tarray: posts,\n\t\t\tmapFn: \"(post) => post.title\",\n\t\t};\n\t},\n});\n\n// Custom step to format final output\nconst formatTitles = createStep({\n\tid: \"format-titles\",\n\tinputSchema: z.object({\n\t\tmapped: z.array(z.unknown()),\n\t\tcount: z.number(),\n\t}),\n\toutputSchema: z.object({\n\t\ttitles: z.array(z.string()),\n\t\tcount: z.number(),\n\t}),\n\texecute: async ({ inputData }) => {\n\t\treturn {\n\t\t\ttitles: inputData.mapped as string[],\n\t\t\tcount: inputData.count,\n\t\t};\n\t},\n});\n\n// Build the workflow\nconst userPostsWorkflow = createWorkflow({\n\tid: \"user-posts-workflow\",\n\tdescription: \"Fetch posts for a user and extract titles\",\n\tinputSchema: z.object({\n\t\tuserId: z.number(),\n\t}),\n\toutputSchema: z.object({\n\t\ttitles: z.array(z.string()),\n\t\tcount: z.number(),\n\t}),\n})\n\t.then(prepareRequest) // Convert userId to API request\n\t.then(httpGet) // Fetch from API\n\t.then(extractTitles) // Prepare for mapping\n\t.then(mapArray) // Extract titles\n\t.then(formatTitles) // Format output\n\t.commit();\n\n// ============================================================================\n// Example 5: Logging and Delays\n// ============================================================================\n\n// Custom step to prepare log data\nconst prepareLog = createStep({\n\tid: \"prepare-log\",\n\tinputSchema: z.object({\n\t\tmessage: z.string(),\n\t}),\n\toutputSchema: z.object({\n\t\tlevel: z.enum([\"debug\", \"info\", \"warn\", \"error\"]),\n\t\tmessage: z.string(),\n\t\tdata: z.unknown().optional(),\n\t}),\n\texecute: async ({ inputData }) => {\n\t\treturn {\n\t\t\tlevel: \"info\" as const,\n\t\t\tmessage: inputData.message,\n\t\t\tdata: { timestamp: Date.now() },\n\t\t};\n\t},\n});\n\n// Custom step to prepare delay\nconst prepareDelay = createStep({\n\tid: \"prepare-delay\",\n\tinputSchema: z.object({\n\t\tlevel: z.enum([\"debug\", \"info\", \"warn\", \"error\"]),\n\t\tmessage: z.string(),\n\t\tdata: z.unknown().optional(),\n\t\ttimestamp: z.string(),\n\t}),\n\toutputSchema: z.object({\n\t\tdurationMs: z.number(),\n\t}),\n\texecute: async ({ inputData }) => {\n\t\treturn {\n\t\t\tdurationMs: 2000, // 2 second delay\n\t\t};\n\t},\n});\n\n// Custom step for final message\nconst finalMessage = createStep({\n\tid: \"final-message\",\n\tinputSchema: z.object({\n\t\tdurationMs: z.number(),\n\t\tcompletedAt: z.string(),\n\t}),\n\toutputSchema: z.object({\n\t\tmessage: z.string(),\n\t\tcompletedAt: z.string(),\n\t}),\n\texecute: async ({ inputData }) => {\n\t\treturn {\n\t\t\tmessage: `Completed after ${inputData.durationMs}ms delay`,\n\t\t\tcompletedAt: inputData.completedAt,\n\t\t};\n\t},\n});\n\nconst logDelayWorkflow = createWorkflow({\n\tid: \"log-delay-workflow\",\n\tdescription: \"Log a message, wait, then complete\",\n\tinputSchema: z.object({\n\t\tmessage: z.string(),\n\t}),\n\toutputSchema: z.object({\n\t\tmessage: z.string(),\n\t\tcompletedAt: z.string(),\n\t}),\n})\n\t.then(prepareLog)\n\t.then(logger)\n\t.then(prepareDelay)\n\t.then(delay)\n\t.then(finalMessage)\n\t.commit();\n\n// ============================================================================\n// Run Examples\n// ============================================================================\n\nif (import.meta.main) {\n\tconsole.log(\"=\".repeat(60));\n\tconsole.log(\"Prebuilt Steps Examples\");\n\tconsole.log(\"=\".repeat(60));\n\n\t// Example 1: Simple HTTP GET\n\tconsole.log(\"\\n[Example 1] Simple HTTP GET\");\n\tconsole.log(\"-\".repeat(60));\n\ttry {\n\t\tconst run1 = await apiDataWorkflow.createRun();\n\t\tconst result1 = await run1.start({\n\t\t\tinputData: {\n\t\t\t\turl: \"https://jsonplaceholder.typicode.com/posts/1\",\n\t\t\t},\n\t\t});\n\t\tconsole.log(\"Status:\", result1.status);\n\t\tconsole.log(\"Data:\", result1.data);\n\t} catch (error) {\n\t\tconsole.error(\"Error:\", error);\n\t}\n\n\t// Example 2: Template String\n\tconsole.log(\"\\n[Example 2] Template String\");\n\tconsole.log(\"-\".repeat(60));\n\ttry {\n\t\tconst run2 = await templateWorkflow.createRun();\n\t\tconst result2 = await run2.start({\n\t\t\tinputData: {\n\t\t\t\ttemplate: \"Hello {{name}}! You have {{count}} new messages.\",\n\t\t\t\tvariables: {\n\t\t\t\t\tname: \"Alice\",\n\t\t\t\t\tcount: 5,\n\t\t\t\t},\n\t\t\t},\n\t\t});\n\t\tconsole.log(\"Result:\", result2.result);\n\t} catch (error) {\n\t\tconsole.error(\"Error:\", error);\n\t}\n\n\t// Example 3: Array Filtering\n\tconsole.log(\"\\n[Example 3] Array Filtering\");\n\tconsole.log(\"-\".repeat(60));\n\ttry {\n\t\tconst run3 = await filterWorkflow.createRun();\n\t\tconst result3 = await run3.start({\n\t\t\tinputData: {\n\t\t\t\tarray: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10],\n\t\t\t\tfilterFn: \"(n) => n % 2 === 0\", // Even numbers only\n\t\t\t},\n\t\t});\n\t\tconsole.log(\"Original count:\", result3.originalCount);\n\t\tconsole.log(\"Filtered count:\", result3.filteredCount);\n\t\tconsole.log(\"Filtered values:\", result3.filtered);\n\t} catch (error) {\n\t\tconsole.error(\"Error:\", error);\n\t}\n\n\t// Example 4: Multi-step Workflow\n\tconsole.log(\"\\n[Example 4] Multi-step User Posts Workflow\");\n\tconsole.log(\"-\".repeat(60));\n\ttry {\n\t\tconst run4 = await userPostsWorkflow.createRun();\n\t\tconst result4 = await run4.start({\n\t\t\tinputData: {\n\t\t\t\tuserId: 1,\n\t\t\t},\n\t\t});\n\t\tconsole.log(\"Post count:\", result4.count);\n\t\tconsole.log(\"First 3 titles:\", result4.titles.slice(0, 3));\n\t} catch (error) {\n\t\tconsole.error(\"Error:\", error);\n\t}\n\n\t// Example 5: Logging and Delays\n\tconsole.log(\"\\n[Example 5] Logging and Delays\");\n\tconsole.log(\"-\".repeat(60));\n\ttry {\n\t\tconst run5 = await logDelayWorkflow.createRun();\n\t\tconst result5 = await run5.start({\n\t\t\tinputData: {\n\t\t\t\tmessage: \"Starting workflow with delay...\",\n\t\t\t},\n\t\t});\n\t\tconsole.log(\"Result:\", result5.message);\n\t\tconsole.log(\"Completed at:\", result5.completedAt);\n\t} catch (error) {\n\t\tconsole.error(\"Error:\", error);\n\t}\n\n\tconsole.log(\"\\n\" + \"=\".repeat(60));\n\tconsole.log(\"All examples completed!\");\n\tconsole.log(\"=\".repeat(60));\n}\n",[],[268,300],{"_106":307,"_96":308,"_161":309,"_163":269,"_164":144,"_165":166,"_167":120,"_108":310,"_102":32,"_169":181,"_171":311,"_172":22,"_173":-5,"_174":312,"_100":313},"ae1afb6a-c55f-11f0-a174-42dde27851f2","simple-workflow.ts","019a9cd0-c1e3-73bc-99fb-fb5525650512",["D",1763567518186],"/**\n * Simple workflow example demonstrating the core API\n *\n * This example shows:\n * - Creating strongly-typed steps\n * - Chaining steps with type inference\n * - Accessing previous step results\n * - Running a workflow\n */\n\nimport { z } from \"npm:zod@^3.23\";\nimport { createStep, createWorkflow } from \"../backend/index.ts\";\n\n// Step 1: Fetch user data\nconst fetchUser = createStep({\n\tid: \"fetch-user\",\n\tdescription: \"Fetch user information\",\n\tinputSchema: z.object({ userId: z.string() }),\n\toutputSchema: z.object({\n\t\tuserId: z.string(),\n\t\tname: z.string(),\n\t\temail: z.string(),\n\t}),\n\texecute: async ({ inputData }) => {\n\t\t// Simulate API call\n\t\tconsole.log(`Fetching user ${inputData.userId}...`);\n\n\t\treturn {\n\t\t\tuserId: inputData.userId,\n\t\t\tname: \"John Doe\",\n\t\t\temail: \"john@example.com\",\n\t\t};\n\t},\n});\n\n// Step 2: Generate personalized message\nconst generateMessage = createStep({\n\tid: \"generate-message\",\n\tdescription: \"Generate personalized greeting\",\n\tinputSchema: z.object({\n\t\tuserId: z.string(),\n\t\tname: z.string(),\n\t\temail: z.string(),\n\t}),\n\toutputSchema: z.object({\n\t\tmessage: z.string(),\n\t\trecipient: z.string(),\n\t}),\n\texecute: async ({ inputData }) => {\n\t\tconsole.log(`Generating message for ${inputData.name}...`);\n\n\t\treturn {\n\t\t\tmessage: `Hello ${inputData.name}! Welcome to our service.`,\n\t\t\trecipient: inputData.email,\n\t\t};\n\t},\n});\n\n// Step 3: Send message (accessing previous step results)\nconst sendMessage = createStep({\n\tid: \"send-message\",\n\tdescription: \"Send the message\",\n\tinputSchema: z.object({\n\t\tmessage: z.string(),\n\t\trecipient: z.string(),\n\t}),\n\toutputSchema: z.object({\n\t\tsent: z.boolean(),\n\t\tmessageId: z.string(),\n\t}),\n\texecute: async ({ inputData, getStepResult }) => {\n\t\t// Access previous step result\n\t\tconst user = getStepResult(fetchUser);\n\n\t\tconsole.log(`Sending message to ${inputData.recipient}...`);\n\t\tconsole.log(`User from previous step: ${user.name}`);\n\n\t\t// Simulate sending\n\t\treturn {\n\t\t\tsent: true,\n\t\t\tmessageId: `msg-${Date.now()}`,\n\t\t};\n\t},\n});\n\n// Create the workflow with full type inference\nexport const greetingWorkflow = createWorkflow({\n\tid: \"greeting-workflow\",\n\tdescription: \"Send a personalized greeting to a user\",\n\tinputSchema: z.object({ userId: z.string() }),\n\toutputSchema: z.object({ sent: z.boolean(), messageId: z.string() }),\n})\n\t.then(fetchUser) // Input: { userId: string }\n\t.then(generateMessage) // Input: fetchUser's output (type inferred!)\n\t.then(sendMessage) // Input: generateMessage's output (type inferred!)\n\t.commit();\n\n// Example usage (for testing outside Val Town)\nif (import.meta.main) {\n\tconsole.log(\"Running greeting workflow example...\\n\");\n\n\tconst run = await greetingWorkflow.createRun();\n\n\ttry {\n\t\tconst result = await run.start({\n\t\t\tinputData: { userId: \"user-123\" },\n\t\t});\n\n\t\tconsole.log(\"\\n✅ Workflow completed successfully!\");\n\t\tconsole.log(\"Result:\", result);\n\n\t\t// Get the snapshot\n\t\tconst snapshot = await run.getSnapshot();\n\t\tconsole.log(\"\\nSnapshot:\", {\n\t\t\trunId: snapshot?.runId,\n\t\t\tstatus: snapshot?.status,\n\t\t\tsteps: Object.keys(snapshot?.stepResults || {}),\n\t\t});\n\t} catch (error) {\n\t\tconsole.error(\"\\n❌ Workflow failed:\");\n\t\tconsole.error(error);\n\t}\n}\n",[],[268,308],{"_106":315,"_96":316,"_161":317,"_163":269,"_164":144,"_165":166,"_167":120,"_108":318,"_102":32,"_169":181,"_171":319,"_172":22,"_173":-5,"_174":320,"_100":321},"ae1afe3a-c55f-11f0-a174-42dde27851f2","workflow-visualization.ts","019a9cd0-c1e3-73bc-99fb-fc4c60738360",["D",1763567518186],"/**\n * Workflow Visualization Example\n *\n * This example demonstrates how to visualize workflows using the built-in\n * visualization features. It shows both static workflow structure visualization\n * and dynamic execution state visualization.\n */\n\nimport { z } from \"npm:zod@^3.23\";\nimport { createStep, createWorkflow } from \"../backend/index.ts\";\n\n// Define steps for a simple data processing workflow\nconst fetchData = createStep({\n\tid: \"fetch-data\",\n\tdescription: \"Fetch data from API\",\n\tinputSchema: z.object({ url: z.string() }),\n\toutputSchema: z.object({ data: z.array(z.any()) }),\n\texecute: async ({ inputData }) => {\n\t\tconsole.log(`Fetching from ${inputData.url}...`);\n\t\t// Simulate API call\n\t\tawait new Promise((resolve) => setTimeout(resolve, 100));\n\t\treturn {\n\t\t\tdata: [\n\t\t\t\t{ id: 1, name: \"Item 1\", value: 100 },\n\t\t\t\t{ id: 2, name: \"Item 2\", value: 200 },\n\t\t\t\t{ id: 3, name: \"Item 3\", value: 50 },\n\t\t\t],\n\t\t};\n\t},\n});\n\nconst filterData = createStep({\n\tid: \"filter-data\",\n\tdescription: \"Filter items by threshold\",\n\tinputSchema: z.object({ data: z.array(z.any()) }),\n\toutputSchema: z.object({ filtered: z.array(z.any()) }),\n\texecute: async ({ inputData }) => {\n\t\tconsole.log(`Filtering ${inputData.data.length} items...`);\n\t\tconst threshold = 75;\n\t\tconst filtered = inputData.data.filter((item) => item.value > threshold);\n\t\treturn { filtered };\n\t},\n});\n\nconst transformData = createStep({\n\tid: \"transform-data\",\n\tdescription: \"Transform data to summary format\",\n\tinputSchema: z.object({ filtered: z.array(z.any()) }),\n\toutputSchema: z.object({\n\t\ttotal: z.number(),\n\t\tcount: z.number(),\n\t\titems: z.array(z.string()),\n\t}),\n\texecute: async ({ inputData }) => {\n\t\tconsole.log(`Transforming ${inputData.filtered.length} items...`);\n\t\tconst total = inputData.filtered.reduce(\n\t\t\t(sum, item) => sum + item.value,\n\t\t\t0,\n\t\t);\n\t\tconst count = inputData.filtered.length;\n\t\tconst items = inputData.filtered.map((item) => item.name);\n\t\treturn { total, count, items };\n\t},\n});\n\nconst saveResults = createStep({\n\tid: \"save-results\",\n\tdescription: \"Save results to database\",\n\tinputSchema: z.object({\n\t\ttotal: z.number(),\n\t\tcount: z.number(),\n\t\titems: z.array(z.string()),\n\t}),\n\toutputSchema: z.object({ saved: z.boolean(), recordId: z.string() }),\n\texecute: async ({ inputData }) => {\n\t\tconsole.log(`Saving ${inputData.count} results...`);\n\t\t// Simulate database save\n\t\tawait new Promise((resolve) => setTimeout(resolve, 100));\n\t\treturn {\n\t\t\tsaved: true,\n\t\t\trecordId: crypto.randomUUID(),\n\t\t};\n\t},\n});\n\n// Create workflow\nconst dataProcessingWorkflow = createWorkflow({\n\tid: \"data-processing\",\n\tdescription: \"Fetch, filter, transform, and save data\",\n\tinputSchema: z.object({ url: z.string() }),\n\toutputSchema: z.object({ saved: z.boolean(), recordId: z.string() }),\n})\n\t.then(fetchData)\n\t.then(filterData)\n\t.then(transformData)\n\t.then(saveResults)\n\t.commit();\n\n// Example 1: Visualize static workflow structure\nconsole.log(\"=\".repeat(60));\nconsole.log(\"STATIC WORKFLOW VISUALIZATION\");\nconsole.log(\"=\".repeat(60));\nconsole.log();\n\nconst staticDiagram = dataProcessingWorkflow.visualize(\"mermaid\", {\n\tincludeDescriptions: true,\n});\nconsole.log(staticDiagram);\nconsole.log();\n\n// Example 2: Execute workflow and visualize execution state\nconsole.log(\"=\".repeat(60));\nconsole.log(\"EXECUTING WORKFLOW\");\nconsole.log(\"=\".repeat(60));\nconsole.log();\n\nconst run = await dataProcessingWorkflow.createRun();\n\n// You could visualize during execution in a real scenario\n// For this example, we'll execute and then visualize the final state\nconst result = await run.start({\n\tinputData: { url: \"https://api.example.com/data\" },\n});\n\nconsole.log(\"Workflow completed!\");\nconsole.log(\"Result:\", result);\nconsole.log();\n\n// Example 3: Visualize execution state\nconsole.log(\"=\".repeat(60));\nconsole.log(\"EXECUTION STATE VISUALIZATION\");\nconsole.log(\"=\".repeat(60));\nconsole.log();\n\nconst executionDiagram = await run.visualize(\"mermaid\", {\n\tincludeDescriptions: true,\n\thighlightCurrentStep: true,\n\tshowStatus: true,\n});\n\nif (executionDiagram) {\n\tconsole.log(executionDiagram);\n} else {\n\tconsole.log(\"No execution snapshot available\");\n}\nconsole.log();\n\n// Example 4: Compact visualization without descriptions\nconsole.log(\"=\".repeat(60));\nconsole.log(\"COMPACT VISUALIZATION\");\nconsole.log(\"=\".repeat(60));\nconsole.log();\n\nconst compactDiagram = dataProcessingWorkflow.visualize(\"mermaid\", {\n\tincludeDescriptions: false,\n});\nconsole.log(compactDiagram);\nconsole.log();\n\nconsole.log(\"=\".repeat(60));\nconsole.log(\"To render these diagrams:\");\nconsole.log(\"1. Copy the Mermaid code\");\nconsole.log(\"2. Paste into https://mermaid.live\");\nconsole.log(\"3. Or use a Markdown renderer that supports Mermaid\");\nconsole.log(\"=\".repeat(60));\n",[],[268,316],[268],{"_106":324,"_96":325,"_161":326,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":327,"_102":32,"_169":170,"_171":-5,"_172":22,"_173":-5,"_174":328,"_100":471},"ae1b2946-c55f-11f0-a174-42dde27851f2","frontend","019a9cd0-c1e3-73bc-99fc-4f53513858e9",["D",1763567518186],[329,415,423,431,439,447,455,463],{"_106":330,"_96":331,"_161":332,"_163":326,"_164":144,"_165":166,"_167":120,"_108":333,"_102":32,"_169":170,"_171":-5,"_172":22,"_173":-5,"_174":334,"_100":414},"ae1b1dde-c55f-11f0-a174-42dde27851f2","src","019a9cd0-c1e3-73bc-99fc-2dbd6bd93121",["D",1763567518186],[335,375,383,391,399,407],{"_106":336,"_96":337,"_161":338,"_163":332,"_164":144,"_165":166,"_167":120,"_108":339,"_102":32,"_169":170,"_171":-5,"_172":22,"_173":-5,"_174":340,"_100":374},"ae1b0f74-c55f-11f0-a174-42dde27851f2","components","019a9cd0-c1e3-73bc-99fc-14a5c626f4ac",["D",1763567518186],[341,350,358,366],{"_106":342,"_96":343,"_161":344,"_163":338,"_164":144,"_165":166,"_167":120,"_108":345,"_102":32,"_169":346,"_171":347,"_172":22,"_173":-5,"_174":348,"_100":349},"ae1b03bc-c55f-11f0-a174-42dde27851f2","StepNode.css","019a9cd0-c1e3-73bc-99fc-06115c806860",["D",1763567518186],"file",".step-node {\n background: white;\n border: 2px solid #e0e0e0;\n border-radius: 8px;\n padding: 12px;\n min-width: 220px;\n max-width: 320px;\n box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);\n transition: all 0.2s;\n}\n\n.step-node:hover {\n box-shadow: 0 4px 12px rgba(0, 0, 0, 0.15);\n transform: translateY(-2px);\n}\n\n.step-node.running {\n border-color: #2196F3;\n background: #E3F2FD;\n}\n\n.step-node.success {\n border-color: #4CAF50;\n background: #E8F5E9;\n}\n\n.step-node.failed {\n border-color: #F44336;\n background: #FFEBEE;\n}\n\n.step-header {\n display: flex;\n justify-content: space-between;\n align-items: center;\n margin-bottom: 8px;\n}\n\n.step-index {\n font-size: 11px;\n font-weight: 600;\n color: #999;\n background: #f5f5f5;\n padding: 2px 6px;\n border-radius: 3px;\n}\n\n.step-status-icon {\n font-size: 16px;\n font-weight: bold;\n}\n\n.step-label {\n font-weight: 600;\n font-size: 14px;\n margin-bottom: 4px;\n word-break: break-word;\n}\n\n.step-description {\n font-size: 12px;\n color: #666;\n margin-bottom: 8px;\n line-height: 1.4;\n}\n\n.step-details {\n margin-top: 8px;\n padding-top: 8px;\n border-top: 1px solid #e0e0e0;\n}\n\n.step-running {\n display: flex;\n align-items: center;\n gap: 8px;\n color: #2196F3;\n font-size: 12px;\n font-weight: 500;\n}\n\n.spinner {\n width: 14px;\n height: 14px;\n border: 2px solid #E3F2FD;\n border-top-color: #2196F3;\n border-radius: 50%;\n animation: spin 0.8s linear infinite;\n}\n\n@keyframes spin {\n to { transform: rotate(360deg); }\n}\n\n.step-output,\n.step-error {\n font-size: 11px;\n}\n\n.output-label,\n.error-label {\n font-weight: 600;\n margin-bottom: 4px;\n font-size: 10px;\n text-transform: uppercase;\n letter-spacing: 0.5px;\n}\n\n.output-label {\n color: #4CAF50;\n}\n\n.error-label {\n color: #F44336;\n}\n\n.step-output pre {\n background: #f9f9f9;\n padding: 8px;\n border-radius: 4px;\n overflow-x: auto;\n max-height: 120px;\n overflow-y: auto;\n font-size: 10px;\n line-height: 1.4;\n margin: 0;\n white-space: pre-wrap;\n word-wrap: break-word;\n}\n\n.error-message {\n background: #FFF3E0;\n padding: 8px;\n border-radius: 4px;\n color: #D84315;\n font-size: 11px;\n line-height: 1.4;\n}\n\n.react-flow__handle {\n width: 8px;\n height: 8px;\n background: #2196F3;\n border: 2px solid white;\n}\n",[],[325,331,337,343],{"_106":351,"_96":352,"_161":353,"_163":338,"_164":144,"_165":166,"_167":120,"_108":354,"_102":32,"_169":181,"_171":355,"_172":22,"_173":-5,"_174":356,"_100":357},"ae1b060a-c55f-11f0-a174-42dde27851f2","StepNode.tsx","019a9cd0-c1e3-73bc-99fc-0a6719ce5922",["D",1763567518186],"import { memo } from 'react'\nimport { Handle, Position, NodeProps } from 'reactflow'\nimport './StepNode.css'\n\ninterface StepNodeData {\n label: string\n description?: string\n status: 'pending' | 'running' | 'success' | 'failed'\n output?: unknown\n error?: string\n index: number\n}\n\nfunction StepNode({ data }: NodeProps) {\n const { label, description, status, output, error, index } = data\n\n const getStatusIcon = () => {\n switch (status) {\n case 'success': return '✓'\n case 'failed': return '✗'\n case 'running': return '●'\n default: return '○'\n }\n }\n\n const getStatusColor = () => {\n switch (status) {\n case 'success': return '#4CAF50'\n case 'failed': return '#F44336'\n case 'running': return '#2196F3'\n default: return '#999'\n }\n }\n\n return (\n

\n \n\n

#{index}

\n \n {getStatusIcon()}\n

\n\n

{label}

\n\n {description && (\n

{description}

\n )}\n\n {status !== 'pending' && (\n

\n {status === 'running' && (\n

\n Executing...\n

\n )}\n\n {status === 'success' && output && (\n

Output:

{JSON.stringify(output, null, 2)}

\n )}\n\n {status === 'failed' && error && (\n

Error:

{error}

\n )}\n

\n )}\n\n \n \n )\n}\n\nexport default memo(StepNode)\n",[],[325,331,337,352],{"_106":359,"_96":360,"_161":361,"_163":338,"_164":144,"_165":166,"_167":120,"_108":362,"_102":32,"_169":346,"_171":363,"_172":22,"_173":-5,"_174":364,"_100":365},"ae1b081c-c55f-11f0-a174-42dde27851f2","WorkflowVisualizer.css","019a9cd0-c1e3-73bc-99fc-0f0cae38fa31",["D",1763567518186],".workflow-visualizer {\n width: 100%;\n height: 100%;\n display: flex;\n flex-direction: column;\n background: white;\n}\n\n.visualizer-header {\n padding: 20px 24px;\n border-bottom: 1px solid #e0e0e0;\n background: white;\n display: flex;\n justify-content: space-between;\n align-items: center;\n}\n\n.visualizer-header h1 {\n font-size: 24px;\n font-weight: 600;\n margin-bottom: 4px;\n}\n\n.visualizer-header p {\n font-size: 14px;\n color: #666;\n}\n\n.run-info {\n text-align: right;\n}\n\n.run-status {\n display: flex;\n align-items: center;\n gap: 8px;\n margin-bottom: 6px;\n font-weight: 600;\n text-transform: capitalize;\n}\n\n.status-indicator {\n width: 12px;\n height: 12px;\n border-radius: 50%;\n}\n\n.status-indicator.running {\n background: #2196F3;\n animation: pulse 1.5s ease-in-out infinite;\n}\n\n.status-indicator.success {\n background: #4CAF50;\n}\n\n.status-indicator.failed {\n background: #F44336;\n}\n\n@keyframes pulse {\n 0%, 100% { opacity: 1; }\n 50% { opacity: 0.5; }\n}\n\n.run-meta {\n font-size: 12px;\n color: #666;\n}\n\n.run-meta code {\n background: #f5f5f5;\n padding: 2px 6px;\n border-radius: 3px;\n font-family: monospace;\n}\n\n.react-flow__node {\n font-size: 12px;\n}\n",[],[325,331,337,360],{"_106":367,"_96":368,"_161":369,"_163":338,"_164":144,"_165":166,"_167":120,"_108":370,"_102":32,"_169":181,"_171":371,"_172":22,"_173":-5,"_174":372,"_100":373},"ae1b0948-c55f-11f0-a174-42dde27851f2","WorkflowVisualizer.tsx","019a9cd0-c1e3-73bc-99fc-1336f106768d",["D",1763567518186],"import { useCallback, useEffect, useMemo } from 'react'\nimport ReactFlow, {\n Node,\n Edge,\n Background,\n Controls,\n MiniMap,\n useNodesState,\n useEdgesState,\n MarkerType,\n} from 'reactflow'\nimport 'reactflow/dist/style.css'\nimport { WorkflowData, WorkflowRunData, StepResult } from '../types'\nimport StepNode from './StepNode'\nimport './WorkflowVisualizer.css'\n\ninterface WorkflowVisualizerProps {\n workflow: WorkflowData\n run?: WorkflowRunData | null\n}\n\nconst nodeTypes = {\n stepNode: StepNode,\n}\n\nfunction WorkflowVisualizer({ workflow, run }: WorkflowVisualizerProps) {\n const [nodes, setNodes, onNodesChange] = useNodesState([])\n const [edges, setEdges, onEdgesChange] = useEdgesState([])\n\n const getStepStatus = useCallback((stepId: string): StepResult['status'] | 'pending' => {\n if (!run?.stepResults?.[stepId]) return 'pending'\n return run.stepResults[stepId].status\n }, [run])\n\n const getStepOutput = useCallback((stepId: string): unknown => {\n if (!run?.stepResults?.[stepId]) return undefined\n const result = run.stepResults[stepId]\n return result.status === 'success' ? result.output : undefined\n }, [run])\n\n const getStepError = useCallback((stepId: string): string | undefined => {\n if (!run?.stepResults?.[stepId]) return undefined\n const result = run.stepResults[stepId]\n return result.status === 'failed' ? result.error : undefined\n }, [run])\n\n // Build graph layout\n const buildGraph = useCallback(() => {\n const nodeWidth = 220\n const nodeHeight = 100\n const horizontalGap = 100\n const verticalGap = 80\n\n const newNodes: Node[] = []\n const newEdges: Edge[] = []\n\n // Start node\n newNodes.push({\n id: 'start',\n type: 'input',\n position: { x: 50, y: 50 },\n data: {\n label: workflow.id,\n },\n style: {\n background: '#C8E6C9',\n border: '2px solid #2E7D32',\n borderRadius: 8,\n padding: 16,\n fontWeight: 600,\n },\n })\n\n let currentX = 50\n let currentY = 50 + nodeHeight + verticalGap\n\n // Step nodes\n workflow.steps.forEach((step, index) => {\n const status = getStepStatus(step.id)\n const output = getStepOutput(step.id)\n const error = getStepError(step.id)\n\n newNodes.push({\n id: step.id,\n type: 'stepNode',\n position: { x: currentX, y: currentY },\n data: {\n label: step.id,\n description: step.description,\n status,\n output,\n error,\n index: index + 1,\n },\n })\n\n // Edge from previous node\n const sourceId = index === 0 ? 'start' : workflow.steps[index - 1].id\n newEdges.push({\n id: `${sourceId}-${step.id}`,\n source: sourceId,\n target: step.id,\n type: 'smoothstep',\n animated: status === 'running',\n style: {\n stroke: status === 'success' ? '#4CAF50' :\n status === 'failed' ? '#F44336' :\n status === 'running' ? '#2196F3' : '#999',\n strokeWidth: 2,\n },\n markerEnd: {\n type: MarkerType.ArrowClosed,\n color: status === 'success' ? '#4CAF50' :\n status === 'failed' ? '#F44336' :\n status === 'running' ? '#2196F3' : '#999',\n },\n })\n\n currentY += nodeHeight + verticalGap\n })\n\n // End node\n const lastStep = workflow.steps[workflow.steps.length - 1]\n newNodes.push({\n id: 'end',\n type: 'output',\n position: { x: currentX, y: currentY },\n data: {\n label: run?.status === 'success' ? '✓ Complete' :\n run?.status === 'failed' ? '✗ Failed' :\n run?.status === 'running' ? '● Running' : 'End',\n },\n style: {\n background: run?.status === 'success' ? '#C8E6C9' :\n run?.status === 'failed' ? '#FFCDD2' :\n run?.status === 'running' ? '#BBDEFB' : '#E0E0E0',\n border: run?.status === 'success' ? '2px solid #2E7D32' :\n run?.status === 'failed' ? '2px solid #C62828' :\n run?.status === 'running' ? '2px solid #1976D2' : '2px solid #999',\n borderRadius: 8,\n padding: 16,\n fontWeight: 600,\n },\n })\n\n newEdges.push({\n id: `${lastStep.id}-end`,\n source: lastStep.id,\n target: 'end',\n type: 'smoothstep',\n animated: run?.status === 'running',\n style: {\n stroke: run?.status === 'success' ? '#4CAF50' :\n run?.status === 'failed' ? '#F44336' :\n run?.status === 'running' ? '#2196F3' : '#999',\n strokeWidth: 2,\n },\n markerEnd: {\n type: MarkerType.ArrowClosed,\n color: run?.status === 'success' ? '#4CAF50' :\n run?.status === 'failed' ? '#F44336' :\n run?.status === 'running' ? '#2196F3' : '#999',\n },\n })\n\n setNodes(newNodes)\n setEdges(newEdges)\n }, [workflow, run, getStepStatus, getStepOutput, getStepError, setNodes, setEdges])\n\n useEffect(() => {\n buildGraph()\n }, [buildGraph])\n\n return (\n

{workflow.id}

\n {workflow.description &&

{workflow.description}

}\n

\n {run && (\n

\n \n {run.status}\n

\n Run ID: {run.runId.slice(0, 12)}...\n

\n )}\n

\n \n \n \n {\n if (node.type === 'input') return '#C8E6C9'\n if (node.type === 'output') return '#E0E0E0'\n const status = node.data.status\n return status === 'success' ? '#C8E6C9' :\n status === 'failed' ? '#FFCDD2' :\n status === 'running' ? '#BBDEFB' : '#F5F5F5'\n }}\n />\n \n

\n )\n}\n\nexport default WorkflowVisualizer\n",[],[325,331,337,368],[325,331,337],{"_106":376,"_96":377,"_161":378,"_163":332,"_164":144,"_165":166,"_167":120,"_108":379,"_102":32,"_169":346,"_171":380,"_172":22,"_173":-5,"_174":381,"_100":382},"ae1b10b4-c55f-11f0-a174-42dde27851f2","App.css","019a9cd0-c1e3-73bc-99fc-1995614be837",["D",1763567518186],".app {\n display: flex;\n height: 100vh;\n background: #f5f5f5;\n}\n\n.sidebar {\n width: 320px;\n background: white;\n border-right: 1px solid #e0e0e0;\n display: flex;\n flex-direction: column;\n overflow-y: auto;\n}\n\n.sidebar-section {\n padding: 20px;\n border-bottom: 1px solid #e0e0e0;\n}\n\n.sidebar-section h2 {\n font-size: 14px;\n font-weight: 600;\n text-transform: uppercase;\n color: #666;\n margin-bottom: 12px;\n}\n\n.section-header {\n display: flex;\n justify-content: space-between;\n align-items: center;\n margin-bottom: 12px;\n}\n\n.btn-create {\n padding: 6px 12px;\n background: #2196F3;\n color: white;\n border: none;\n border-radius: 4px;\n cursor: pointer;\n font-size: 12px;\n font-weight: 500;\n}\n\n.btn-create:hover {\n background: #1976D2;\n}\n\n.workflow-list,\n.runs-list {\n display: flex;\n flex-direction: column;\n gap: 8px;\n}\n\n.workflow-item,\n.run-item {\n padding: 12px;\n background: #f9f9f9;\n border-radius: 6px;\n cursor: pointer;\n transition: all 0.2s;\n border: 2px solid transparent;\n}\n\n.workflow-item:hover,\n.run-item:hover {\n background: #f0f0f0;\n}\n\n.workflow-item.active,\n.run-item.active {\n background: #E3F2FD;\n border-color: #2196F3;\n}\n\n.workflow-name {\n font-weight: 600;\n font-size: 14px;\n margin-bottom: 4px;\n}\n\n.workflow-description {\n font-size: 12px;\n color: #666;\n}\n\n.run-header {\n display: flex;\n justify-content: space-between;\n align-items: center;\n margin-bottom: 6px;\n}\n\n.status-badge {\n padding: 3px 8px;\n border-radius: 4px;\n font-size: 11px;\n font-weight: 600;\n text-transform: uppercase;\n}\n\n.status-badge.running {\n background: #FFF3E0;\n color: #E65100;\n}\n\n.status-badge.success {\n background: #E8F5E9;\n color: #2E7D32;\n}\n\n.status-badge.failed {\n background: #FFEBEE;\n color: #C62828;\n}\n\n.run-time {\n font-size: 11px;\n color: #999;\n}\n\n.run-id {\n font-family: monospace;\n font-size: 11px;\n color: #666;\n}\n\n.auto-refresh {\n display: flex;\n align-items: center;\n gap: 8px;\n font-size: 13px;\n cursor: pointer;\n user-select: none;\n}\n\n.auto-refresh input[type=\"checkbox\"] {\n cursor: pointer;\n}\n\n.main-content {\n flex: 1;\n position: relative;\n}\n",[],[325,331,377],{"_106":384,"_96":385,"_161":386,"_163":332,"_164":144,"_165":166,"_167":120,"_108":387,"_102":32,"_169":181,"_171":388,"_172":22,"_173":-5,"_174":389,"_100":390},"ae1b12d0-c55f-11f0-a174-42dde27851f2","App.tsx","019a9cd0-c1e3-73bc-99fc-1cd03fd8782e",["D",1763567518186],"import { useState, useEffect } from 'react'\nimport WorkflowVisualizer from './components/WorkflowVisualizer'\nimport { WorkflowData, WorkflowRunData } from './types'\nimport './App.css'\n\nfunction App() {\n const [workflows, setWorkflows] = useState([])\n const [selectedWorkflow, setSelectedWorkflow] = useState(null)\n const [runs, setRuns] = useState([])\n const [selectedRun, setSelectedRun] = useState(null)\n const [autoRefresh, setAutoRefresh] = useState(false)\n\n // Fetch available workflows\n useEffect(() => {\n fetchWorkflows()\n }, [])\n\n // Fetch runs for selected workflow\n useEffect(() => {\n if (selectedWorkflow) {\n fetchRuns(selectedWorkflow.id)\n }\n }, [selectedWorkflow])\n\n // Auto-refresh selected run\n useEffect(() => {\n if (!autoRefresh || !selectedRun) return\n\n const interval = setInterval(() => {\n fetchRunDetails(selectedRun.runId)\n }, 1000)\n\n return () => clearInterval(interval)\n }, [autoRefresh, selectedRun])\n\n const fetchWorkflows = async () => {\n try {\n const response = await fetch('/api/workflows')\n const data = await response.json()\n setWorkflows(data)\n if (data.length > 0 && !selectedWorkflow) {\n setSelectedWorkflow(data[0])\n }\n } catch (error) {\n console.error('Failed to fetch workflows:', error)\n }\n }\n\n const fetchRuns = async (workflowId: string) => {\n try {\n const response = await fetch(`/api/workflows/${workflowId}/runs`)\n const data = await response.json()\n setRuns(data)\n if (data.length > 0) {\n setSelectedRun(data[0])\n }\n } catch (error) {\n console.error('Failed to fetch runs:', error)\n }\n }\n\n const fetchRunDetails = async (runId: string) => {\n try {\n const response = await fetch(`/api/runs/${runId}`)\n const data = await response.json()\n setSelectedRun(data)\n\n // Update in the runs list too\n setRuns(prev => prev.map(run =>\n run.runId === runId ? data : run\n ))\n } catch (error) {\n console.error('Failed to fetch run details:', error)\n }\n }\n\n const createNewRun = async () => {\n if (!selectedWorkflow) return\n\n try {\n const response = await fetch(`/api/workflows/${selectedWorkflow.id}/runs`, {\n method: 'POST',\n headers: { 'Content-Type': 'application/json' },\n body: JSON.stringify({\n inputData: selectedWorkflow.exampleInput || {}\n })\n })\n const newRun = await response.json()\n setRuns(prev => [newRun, ...prev])\n setSelectedRun(newRun)\n setAutoRefresh(true)\n } catch (error) {\n console.error('Failed to create run:', error)\n }\n }\n\n return (\n

Workflows

\n {workflows.map(workflow => (\n setSelectedWorkflow(workflow)}\n >\n

{workflow.id}

\n {workflow.description && (\n

{workflow.description}

\n )}\n

\n ))}\n

\n\n {selectedWorkflow && (\n

Runs

\n \n

\n {runs.map(run => (\n setSelectedRun(run)}\n >\n

\n {run.status}\n \n {new Date(run.createdAt).toLocaleTimeString()}\n \n

{run.runId.slice(0, 8)}...

\n ))}\n

\n )}\n\n {selectedRun && (\n

\n \n setAutoRefresh(e.target.checked)}\n />\n Auto-refresh\n \n

\n )}\n \n\n

\n {selectedWorkflow && (\n \n )}\n

\n \n )\n}\n\nexport default App\n",[],[325,331,385],{"_106":392,"_96":393,"_161":394,"_163":332,"_164":144,"_165":166,"_167":120,"_108":395,"_102":32,"_169":346,"_171":396,"_172":22,"_173":-5,"_174":397,"_100":398},"ae1b1a78-c55f-11f0-a174-42dde27851f2","index.css","019a9cd0-c1e3-73bc-99fc-235424df692e",["D",1763567518186],"* {\n margin: 0;\n padding: 0;\n box-sizing: border-box;\n}\n\nbody {\n font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', 'Roboto', 'Oxygen',\n 'Ubuntu', 'Cantarell', 'Fira Sans', 'Droid Sans', 'Helvetica Neue',\n sans-serif;\n -webkit-font-smoothing: antialiased;\n -moz-osx-font-smoothing: grayscale;\n}\n\n#root {\n width: 100vw;\n height: 100vh;\n}\n",[],[325,331,393],{"_106":400,"_96":401,"_161":402,"_163":332,"_164":144,"_165":166,"_167":120,"_108":403,"_102":32,"_169":181,"_171":404,"_172":22,"_173":-5,"_174":405,"_100":406},"ae1b1bb8-c55f-11f0-a174-42dde27851f2","main.tsx","019a9cd0-c1e3-73bc-99fc-2479cc5ae051",["D",1763567518186],"import React from 'react'\nimport ReactDOM from 'react-dom/client'\nimport App from './App'\nimport './index.css'\n\nReactDOM.createRoot(document.getElementById('root')!).render(\n \n \n ,\n)\n",[],[325,331,401],{"_106":408,"_96":243,"_161":409,"_163":332,"_164":144,"_165":166,"_167":120,"_108":410,"_102":32,"_169":181,"_171":411,"_172":22,"_173":-5,"_174":412,"_100":413},"ae1b1ce4-c55f-11f0-a174-42dde27851f2","019a9cd0-c1e3-73bc-99fc-2845b6ac1b12",["D",1763567518186],"export interface WorkflowStep {\n id: string\n description?: string\n}\n\nexport interface WorkflowData {\n id: string\n description?: string\n steps: WorkflowStep[]\n exampleInput?: Record\n}\n\nexport interface StepResult {\n status: 'success' | 'failed' | 'running'\n output?: unknown\n error?: string\n timestamp: number\n}\n\nexport interface WorkflowRunData {\n runId: string\n workflowId: string\n status: 'running' | 'success' | 'failed'\n executionPath: number[]\n stepResults: Record\n inputData: unknown\n result?: unknown\n error?: string\n createdAt: number\n updatedAt: number\n}\n",[],[325,331,243],[325,331],{"_106":416,"_96":417,"_161":418,"_163":326,"_164":144,"_165":166,"_167":120,"_108":419,"_102":32,"_169":346,"_171":420,"_172":22,"_173":-5,"_174":421,"_100":422},"ae1b1f00-c55f-11f0-a174-42dde27851f2",".gitignore","019a9cd0-c1e3-73bc-99fc-32c92492b966",["D",1763567518186],"# Logs\nlogs\n*.log\nnpm-debug.log*\nyarn-debug.log*\nyarn-error.log*\npnpm-debug.log*\nlerna-debug.log*\n\nnode_modules\ndist\ndist-ssr\n*.local\n\n# Editor directories and files\n.vscode/*\n!.vscode/extensions.json\n.idea\n.DS_Store\n*.suo\n*.ntvs*\n*.njsproj\n*.sln\n*.sw?\n",[],[325,417],{"_106":424,"_96":425,"_161":426,"_163":326,"_164":144,"_165":166,"_167":120,"_108":427,"_102":32,"_169":346,"_171":428,"_172":22,"_173":-5,"_174":429,"_100":430},"ae1b1ff0-c55f-11f0-a174-42dde27851f2","README.md","019a9cd0-c1e3-73bc-99fc-37821c69ecb6",["D",1763567518186],"# Workflow Visualizer\n\nA React-based canvas visualizer for the wrkflw workflow engine. Provides real-time visualization of workflow execution with interactive controls.\n\n## Features\n\n- **Interactive Canvas**: Built with React Flow for smooth pan, zoom, and navigation\n- **Real-time Updates**: Auto-refresh to watch workflow execution live\n- **Step Details**: View step outputs, errors, and execution status\n- **Multiple Workflows**: Switch between different workflows and their runs\n- **Execution History**: Browse past workflow runs and their results\n- **Status Indicators**: Visual feedback for running, success, and failed steps\n\n## Getting Started\n\n### Prerequisites\n\n- Node.js 18+ or Bun\n- The wrkflw backend API server running on port 8000\n\n### Installation\n\n```bash\nnpm install\n# or\nbun install\n```\n\n### Development\n\nStart the development server:\n\n```bash\nnpm run dev\n# or\nbun run dev\n```\n\nThe app will be available at `http://localhost:3000`.\n\n### Building for Production\n\n```bash\nnpm run build\n# or\nbun run build\n```\n\nPreview the production build:\n\n```bash\nnpm run preview\n# or\nbun run preview\n```\n\n## Usage\n\n### 1. Start the Backend API Server\n\nFirst, start the wrkflw backend with the API server:\n\n```bash\n# From the root directory\ndeno run --allow-all examples/api-server-example.ts\n```\n\nThis will:\n- Initialize the workflow engine\n- Register example workflows\n- Start the API server on port 8000\n\n### 2. Start the Frontend\n\n```bash\ncd frontend\nnpm install\nnpm run dev\n```\n\nOpen `http://localhost:3000` in your browser.\n\n### 3. Using the Visualizer\n\n1. **Select a Workflow**: Click on a workflow in the left sidebar\n2. **Create a Run**: Click \"+ New Run\" to execute the workflow\n3. **Watch Live**: Enable \"Auto-refresh\" to see real-time updates\n4. **Inspect Steps**: Click on step nodes to see detailed outputs\n5. **Navigate**: Use mouse to pan, scroll to zoom, minimap for overview\n\n## Architecture\n\n### Components\n\n- **App.tsx**: Main application container, manages workflow and run selection\n- **WorkflowVisualizer.tsx**: Canvas-based workflow renderer using React Flow\n- **StepNode.tsx**: Custom node component for workflow steps\n\n### State Management\n\n- React hooks for local state\n- Fetch API for backend communication\n- Auto-refresh polling for real-time updates\n\n### API Integration\n\nThe frontend communicates with the backend API:\n\n```\nGET /api/workflows - List all workflows\nGET /api/workflows/:id - Get workflow details\nGET /api/workflows/:id/runs - List runs for a workflow\nPOST /api/workflows/:id/runs - Create a new run\nGET /api/runs/:runId - Get run details\n```\n\n## Customization\n\n### Styling\n\nModify the CSS files to customize the appearance:\n\n- `App.css`: Main layout and sidebar styles\n- `WorkflowVisualizer.css`: Canvas and header styles\n- `StepNode.css`: Step node appearance and animations\n\n### Node Layout\n\nAdjust the graph layout in `WorkflowVisualizer.tsx`:\n\n```typescript\nconst nodeWidth = 220\nconst nodeHeight = 100\nconst horizontalGap = 100\nconst verticalGap = 80\n```\n\n### Status Colors\n\nCustomize status colors in `StepNode.tsx`:\n\n```typescript\nconst getStatusColor = () => {\n switch (status) {\n case 'success': return '#4CAF50'\n case 'failed': return '#F44336'\n case 'running': return '#2196F3'\n default: return '#999'\n }\n}\n```\n\n## Technology Stack\n\n- **React 18**: UI framework\n- **TypeScript**: Type safety\n- **React Flow**: Canvas rendering and interactions\n- **Vite**: Build tool and dev server\n- **Zustand**: State management (via React Flow)\n\n## Development Tips\n\n### Hot Module Replacement\n\nVite provides instant HMR. Changes to React components will reflect immediately without losing state.\n\n### Debugging\n\nOpen React DevTools to inspect component state and props. The browser console shows API requests and responses.\n\n### API Proxy\n\nThe dev server proxies `/api/*` requests to `http://localhost:8000`. This avoids CORS issues during development.\n\n## Troubleshooting\n\n### API Connection Issues\n\nIf workflows don't load:\n\n1. Ensure the backend API server is running on port 8000\n2. Check the browser console for CORS or network errors\n3. Verify the proxy configuration in `vite.config.ts`\n\n### Run Not Updating\n\nIf a run appears stuck:\n\n1. Enable auto-refresh\n2. Check the backend console for errors\n3. Manually refresh by clicking the run again\n\n### Build Errors\n\nIf TypeScript errors occur:\n\n```bash\nnpm run build -- --force\n```\n\nOr check for missing dependencies:\n\n```bash\nnpm install\n```\n\n## Contributing\n\nWhen adding new features:\n\n1. Add TypeScript types to `types.ts`\n2. Update components with proper typing\n3. Add CSS for new elements\n4. Test with multiple workflows and run states\n\n## License\n\nSame license as the parent wrkflw project.\n",[],[325,425],{"_106":432,"_96":433,"_161":434,"_163":326,"_164":144,"_165":166,"_167":120,"_108":435,"_102":32,"_169":346,"_171":436,"_172":22,"_173":-5,"_174":437,"_100":438},"ae1b2428-c55f-11f0-a174-42dde27851f2","index.html","019a9cd0-c1e3-73bc-99fc-38a97daaedfd",["D",1763567518186],"\n\n \n \n \n Workflow Visualizer\n \n \n

\n \n \n\n",[],[325,433],{"_106":440,"_96":441,"_161":442,"_163":326,"_164":144,"_165":166,"_167":120,"_108":443,"_102":32,"_169":346,"_171":444,"_172":22,"_173":-5,"_174":445,"_100":446},"ae1b254a-c55f-11f0-a174-42dde27851f2","package.json","019a9cd0-c1e3-73bc-99fc-3e989721b2cb",["D",1763567518186],"{\n \"name\": \"wrkflw-visualizer\",\n \"private\": true,\n \"version\": \"0.1.0\",\n \"type\": \"module\",\n \"scripts\": {\n \"dev\": \"vite\",\n \"build\": \"tsc && vite build\",\n \"preview\": \"vite preview\"\n },\n \"dependencies\": {\n \"react\": \"^18.3.1\",\n \"react-dom\": \"^18.3.1\",\n \"reactflow\": \"^11.11.0\",\n \"zustand\": \"^4.5.0\"\n },\n \"devDependencies\": {\n \"@types/react\": \"^18.3.0\",\n \"@types/react-dom\": \"^18.3.0\",\n \"@vitejs/plugin-react\": \"^4.3.0\",\n \"typescript\": \"^5.6.0\",\n \"vite\": \"^5.4.0\"\n }\n}\n",[],[325,441],{"_106":448,"_96":449,"_161":450,"_163":326,"_164":144,"_165":166,"_167":120,"_108":451,"_102":32,"_169":346,"_171":452,"_172":22,"_173":-5,"_174":453,"_100":454},"ae1b264e-c55f-11f0-a174-42dde27851f2","tsconfig.json","019a9cd0-c1e3-73bc-99fc-416cde8dffdc",["D",1763567518186],"{\n \"compilerOptions\": {\n \"target\": \"ES2020\",\n \"useDefineForClassFields\": true,\n \"lib\": [\"ES2020\", \"DOM\", \"DOM.Iterable\"],\n \"module\": \"ESNext\",\n \"skipLibCheck\": true,\n \"moduleResolution\": \"bundler\",\n \"allowImportingTsExtensions\": true,\n \"resolveJsonModule\": true,\n \"isolatedModules\": true,\n \"noEmit\": true,\n \"jsx\": \"react-jsx\",\n \"strict\": true,\n \"noUnusedLocals\": true,\n \"noUnusedParameters\": true,\n \"noFallthroughCasesInSwitch\": true\n },\n \"include\": [\"src\"],\n \"references\": [{ \"path\": \"./tsconfig.node.json\" }]\n}\n",[],[325,449],{"_106":456,"_96":457,"_161":458,"_163":326,"_164":144,"_165":166,"_167":120,"_108":459,"_102":32,"_169":346,"_171":460,"_172":22,"_173":-5,"_174":461,"_100":462},"ae1b275c-c55f-11f0-a174-42dde27851f2","tsconfig.node.json","019a9cd0-c1e3-73bc-99fc-46ad3cf3e6db",["D",1763567518186],"{\n \"compilerOptions\": {\n \"composite\": true,\n \"skipLibCheck\": true,\n \"module\": \"ESNext\",\n \"moduleResolution\": \"bundler\",\n \"allowSyntheticDefaultImports\": true\n },\n \"include\": [\"vite.config.ts\"]\n}\n",[],[325,457],{"_106":464,"_96":465,"_161":466,"_163":326,"_164":144,"_165":166,"_167":120,"_108":467,"_102":32,"_169":181,"_171":468,"_172":22,"_173":-5,"_174":469,"_100":470},"ae1b2856-c55f-11f0-a174-42dde27851f2","vite.config.ts","019a9cd0-c1e3-73bc-99fc-49b28ddd6618",["D",1763567518186],"import { defineConfig } from 'vite'\nimport react from '@vitejs/plugin-react'\n\nexport default defineConfig({\n plugins: [react()],\n server: {\n port: 3000,\n proxy: {\n '/api': {\n target: 'http://localhost:8000',\n changeOrigin: true,\n },\n },\n },\n})\n",[],[325,465],[325],{"_106":473,"_96":417,"_161":474,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":475,"_102":32,"_169":346,"_171":476,"_172":22,"_173":-5,"_174":477,"_100":478},"ae1b2a4a-c55f-11f0-a174-42dde27851f2","019a9cd0-c1e3-73bc-99fc-517a1548aa05",["D",1763567518186],"/.idea/\n/.vscode/\n/node_modules\n.env\n.env.local\n*.orig\n*.pyc\n*.swp\n\n",[],[417],{"_106":480,"_96":481,"_161":482,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":483,"_102":32,"_169":346,"_171":484,"_172":22,"_173":-5,"_174":485,"_100":486},"ae1b2b58-c55f-11f0-a174-42dde27851f2",".vtignore","019a9cd0-c1e3-73bc-99fc-56e8e4811431",["D",1763567518186],".git\n.vscode\n.cursor\n.DS_Store\nnode_modules\nvendor",[],[481],{"_106":488,"_96":489,"_161":490,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":491,"_102":32,"_169":346,"_171":492,"_172":22,"_173":-5,"_174":493,"_100":494},"ae1b2c66-c55f-11f0-a174-42dde27851f2","AGENTS.md","019a9cd0-c1e3-73bc-99fc-5a4b4af8c025",["D",1763567518186],"You are an advanced assistant specialized in generating Val Town code.\n\n## Core Guidelines\n\n- Ask clarifying questions when requirements are ambiguous\n- Provide complete, functional solutions rather than skeleton implementations\n- Test your logic against edge cases before presenting the final solution\n- Ensure all code follows Val Town's specific platform requirements\n- If a section of code that you're working on is getting too complex, consider\n refactoring it into subcomponents\n\n## Code Standards\n\n- Generate code in TypeScript or TSX\n- Add appropriate TypeScript types and interfaces for all data structures\n- Prefer official SDKs or libraries than writing API calls directly\n- Ask the user to supply API or library documentation if you are at all unsure\n about it\n- **Never bake in secrets into the code** - always use environment variables\n- Include comments explaining complex logic (avoid commenting obvious\n operations)\n- Follow modern ES6+ conventions and functional programming practices if\n possible\n\n## Types of triggers\n\n### 1. HTTP Trigger\n\n- Create web APIs and endpoints\n- Handle HTTP requests and responses\n- Example structure:\n\n```ts\nexport default async function (req: Request) {\n return new Response(\"Hello World\");\n}\n```\n\nFiles that are HTTP triggers have http in their name like `foobar.http.tsx`\n\n### 2. Cron Triggers\n\n- Run on a schedule\n- Use cron expressions for timing\n- Example structure:\n\n```ts\nexport default async function () {\n // Scheduled task code\n}\n```\n\nFiles that are Cron triggers have cron in their name like `foobar.cron.tsx`\n\n### 3. Email Triggers\n\n- Process incoming emails\n- Handle email-based workflows\n- Example structure:\n\n```ts\nexport default async function (email: Email) {\n // Process email\n}\n```\n\nFiles that are Email triggers have email in their name like `foobar.email.tsx`\n\n## Val Town Standard Libraries\n\nVal Town provides several hosted services and utility functions.\n\n### Blob Storage\n\n```ts\nimport { blob } from \"https://esm.town/v/std/blob\";\nawait blob.setJSON(\"myKey\", { hello: \"world\" });\nlet blobDemo = await blob.getJSON(\"myKey\");\nlet appKeys = await blob.list(\"app_\");\nawait blob.delete(\"myKey\");\n```\n\n### SQLite\n\n```ts\nimport { sqlite } from \"https://esm.town/v/stevekrouse/sqlite\";\nconst TABLE_NAME = \"todo_app_users_2\";\n// Create table - do this before usage and change table name when modifying schema\nawait sqlite.execute(`CREATE TABLE IF NOT EXISTS ${TABLE_NAME} (\n id INTEGER PRIMARY KEY AUTOINCREMENT,\n name TEXT NOT NULL\n)`);\n// Query data\nconst result = await sqlite.execute(\n `SELECT * FROM ${TABLE_NAME} WHERE id = ?`,\n [1],\n);\n```\n\nNote: When changing a SQLite table's schema, change the table's name (e.g., add\n_2 or _3) to create a fresh table.\n\n### OpenAI\n\n```ts\nimport { OpenAI } from \"https://esm.town/v/std/openai\";\nconst openai = new OpenAI();\nconst completion = await openai.chat.completions.create({\n messages: [\n { role: \"user\", content: \"Say hello in a creative way\" },\n ],\n model: \"gpt-4o-mini\",\n max_tokens: 30,\n});\n```\n\n### Email\n\n```ts\nimport { email } from \"https://esm.town/v/std/email\";\n// By default emails the owner of the val\nawait email({\n subject: \"Hi\",\n text: \"Hi\",\n html: \"

Hi

\",\n});\n```\n\n## Val Town Utility Functions\n\nVal Town provides several utility functions to help with common project tasks.\n\n### Importing Utilities\n\nAlways import utilities with version pins to avoid breaking changes:\n\n```ts\nimport {\n parseProject,\n readFile,\n serveFile,\n} from \"https://esm.town/v/std/utils@85-main/index.ts\";\n```\n\n### Available Utilities\n\n#### **serveFile** - Serve project files with proper content types\n\nFor example, in Hono:\n\n```ts\n// serve all files in frontend/ and shared/\napp.get(\"/frontend/*\", (c) => serveFile(c.req.path, import.meta.url));\napp.get(\"/shared/*\", (c) => serveFile(c.req.path, import.meta.url));\n```\n\n#### **readFile** - Read files from within the project:\n\n```ts\n// Read a file from the project\nconst fileContent = await readFile(\"/frontend/index.html\", import.meta.url);\n```\n\n#### **listFiles** - List all files in the project\n\n```ts\nconst files = await listFiles(import.meta.url);\n```\n\n#### **parseProject** - Extract information about the current project from import.meta.url\n\nThis is useful for including info for linking back to a val, ie in \"view source\"\nurls:\n\n```ts\nconst projectVal = parseProject(import.meta.url);\nconsole.log(projectVal.username); // Owner of the project\nconsole.log(projectVal.name); // Project name\nconsole.log(projectVal.version); // Version number\nconsole.log(projectVal.branch); // Branch name\nconsole.log(projectVal.links.self.project); // URL to the project page\n```\n\nHowever, it's _extremely importing_ to note that `parseProject` and other\nStandard Library utilities ONLY RUN ON THE SERVER. If you need access to this\ndata on the client, run it in the server and pass it to the client by splicing\nit into the HTML page or by making an API request for it.\n\n## Val Town Platform Specifics\n\n- **Redirects:** Use\n `return new Response(null, { status: 302, headers: { Location: \"/place/to/redirect\" }})`\n instead of `Response.redirect` which is broken\n- **Images:** Avoid external images or base64 images. Use emojis, unicode\n symbols, or icon fonts/libraries instead\n- **AI Image:** To inline generate an AI image use:\n `

`\n- **Storage:** DO NOT use the Deno KV module for storage\n- **Browser APIs:** DO NOT use the `alert()`, `prompt()`, or `confirm()` methods\n- **Weather Data:** Use open-meteo for weather data (doesn't require API keys)\n unless otherwise specified\n- **View Source:** Add a view source link by importing & using\n `import.meta.url.replace(\"ems.sh\", \"val.town)\"` (or passing this data to the\n client) and include `target=\"_top\"` attribute\n- **Error Debugging:** Add\n `` to HTML to capture\n client-side errors\n- **Error Handling:** Only use try...catch when there's a clear local\n resolution; Avoid catches that merely log or return 500s. Let errors bubble up\n with full context\n- **Environment Variables:** Use `Deno.env.get('keyname')` when you need to, but\n generally prefer APIs that don't require keys\n- **Imports:** Use `https://esm.sh` for npm and Deno dependencies to ensure\n compatibility on server and browser\n- **Storage Strategy:** Only use backend storage if explicitly required; prefer\n simple static client-side sites\n- **React Configuration:** When using React libraries, pin versions with\n `?deps=react@18.2.0,react-dom@18.2.0` and start the file with\n `/** @jsxImportSource https://esm.sh/react@18.2.0 */`\n- Ensure all React dependencies and sub-dependencies are pinned to the same\n version\n- **Styling:** Default to using TailwindCSS via\n `` unless otherwise\n specified\n\n## Project Structure and Design Patterns\n\n### Recommended Directory Structure\n\n```\n├── backend/\n│ ├── database/\n│ │ ├── migrations.ts # Schema definitions\n│ │ ├── queries.ts # DB query functions\n│ │ └── README.md\n│ └── routes/ # Route modules\n│ ├── [route].ts\n│ └── static.ts # Static file serving\n│ ├── index.ts # Main entry point\n│ └── README.md\n├── frontend/\n│ ├── components/\n│ │ ├── App.tsx\n│ │ └── [Component].tsx\n│ ├── favicon.svg\n│ ├── index.html # Main HTML template\n│ ├── index.tsx # Frontend JS entry point\n│ ├── README.md\n│ └── style.css\n├── README.md\n└── shared/\n ├── README.md\n └── utils.ts # Shared types and functions\n```\n\n### Backend (Hono) Best Practices\n\n- Hono is the recommended API framework\n- Main entry point should be `backend/index.ts`\n- **Static asset serving:** Use the utility functions to read and serve project\n files:\n ```ts\n import {\n readFile,\n serveFile,\n } from \"https://esm.town/v/std/utils@85-main/index.ts\";\n\n // serve all files in frontend/ and shared/\n app.get(\"/frontend/*\", (c) => serveFile(c.req.path, import.meta.url));\n app.get(\"/shared/*\", (c) => serveFile(c.req.path, import.meta.url));\n\n // For index.html, often you'll want to bootstrap with initial data\n app.get(\"/\", async (c) => {\n let html = await readFile(\"/frontend/index.html\", import.meta.url);\n\n // Inject data to avoid extra round-trips\n const initialData = await fetchInitialData();\n const dataScript = ``;\n\n html = html.replace(\"\", `${dataScript}`);\n return c.html(html);\n });\n ```\n- Create RESTful API routes for CRUD operations\n- Always include this snippet at the top-level Hono app to re-throwing errors to\n see full stack traces:\n ```ts\n // Unwrap Hono errors to see original error details\n app.onError((err, c) => {\n throw err;\n });\n ```\n\n### Database Patterns\n\n- Run migrations on startup or comment out for performance\n- Change table names when modifying schemas rather than altering\n- Export clear query functions with proper TypeScript typing\n\n## Common Gotchas and Solutions\n\n1. **Environment Limitations:**\n - Val Town runs on Deno in a serverless context, not Node.js\n - Code in `shared/` must work in both frontend and backend environments\n - Cannot use `Deno` keyword in shared code\n - Use `https://esm.sh` for imports that work in both environments\n\n2. **SQLite Peculiarities:**\n - Limited support for ALTER TABLE operations\n - Create new tables with updated schemas and copy data when needed\n - Always run table creation before querying\n\n3. **React Configuration:**\n - All React dependencies must be pinned to 18.2.0\n - Always include `@jsxImportSource https://esm.sh/react@18.2.0` at the top of\n React files\n - Rendering issues often come from mismatched React versions\n\n4. **File Handling:**\n - Val Town only supports text files, not binary\n - Use the provided utilities to read files across branches and forks\n - For files in the project, use `readFile` helpers\n\n5. **API Design:**\n - `fetch` handler is the entry point for HTTP vals\n - Run the Hono app with\n `export default app.fetch // This is the entry point for HTTP vals`",[],[489],{"_106":496,"_96":497,"_161":498,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":499,"_102":32,"_169":346,"_171":492,"_172":22,"_173":-5,"_174":500,"_100":501},"ae1b365c-c55f-11f0-a174-42dde27851f2","CLAUDE.md","019a9cd0-c1e3-73bc-99fc-5c7c0a4a1d42",["D",1763567518186],[],[497],{"_106":503,"_96":504,"_161":505,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":506,"_102":32,"_169":346,"_171":507,"_172":22,"_173":-5,"_174":508,"_100":509},"ae1b43ae-c55f-11f0-a174-42dde27851f2","MIGRATION.md","019a9cd0-c1e3-73bc-99fc-63d971e14ad3",["D",1763567518186],"# Database Migration Guide\n\n## Table Naming Normalization\n\nAll tables in the wrkflw library now use the `wrkflw_` prefix for consistency and namespace clarity. This guide explains how to migrate existing data.\n\n## Affected Tables\n\n- `workflow_runs` → `wrkflw_workflow_runs`\n\n## Automatic Migration\n\nThe library includes automatic migration functionality that runs during initialization. When you call `WorkflowStorage.init()`, the migration will:\n\n1. Check if the old `workflow_runs` table exists\n2. Create the new `wrkflw_workflow_runs` table if it doesn't exist\n3. Copy all data from the old table to the new table\n4. Preserve the old table for safety (no data loss)\n\n### How It Works\n\nThe migration is **automatic and safe**:\n\n```typescript\nimport { WorkflowStorage } from \"./backend/storage.ts\";\n\nconst storage = new WorkflowStorage();\nawait storage.init(); // Migration happens automatically here\n```\n\nBy default, the old table is **not deleted** to ensure data safety. Both tables will exist after migration.\n\n## Manual Migration Options\n\n### Option 1: Using the Migration API\n\nIf you want more control over the migration process:\n\n```typescript\nimport { runMigrations, migrateWorkflowRunsTable } from \"./backend/migrations.ts\";\n\n// Migrate with old table preserved (recommended)\nconst result1 = await migrateWorkflowRunsTable(false);\nconsole.log(result1.message);\nconsole.log(`Migrated ${result1.rowCount} rows`);\n\n// Migrate and drop old table (use with caution)\nconst result2 = await migrateWorkflowRunsTable(true);\n```\n\n### Option 2: Using SQL Directly\n\nGenerate a SQL migration script for manual execution:\n\n```typescript\nimport { generateMigrationSQL } from \"./backend/migrations.ts\";\n\n// Generate SQL without dropping old table\nconst sql = generateMigrationSQL(false);\nconsole.log(sql);\n\n// Or generate SQL with old table cleanup\nconst sql = generateMigrationSQL(true);\nconsole.log(sql);\n```\n\nYou can then execute this SQL manually in your SQLite database.\n\n**Note**: The generated SQL script assumes you have an existing `workflow_runs` table to migrate from. If the table doesn't exist (fresh installation), the data migration step (Step 3) will fail, which is expected - you can create just the new table structure without the migration step.\n\n### Example SQL Migration Script\n\n```sql\n-- Create new table with wrkflw_ prefix\nCREATE TABLE IF NOT EXISTS wrkflw_workflow_runs (\n run_id TEXT PRIMARY KEY,\n workflow_id TEXT NOT NULL,\n status TEXT NOT NULL,\n execution_path TEXT,\n step_results TEXT,\n state TEXT,\n input_data TEXT,\n result TEXT,\n error TEXT,\n created_at INTEGER DEFAULT (unixepoch()),\n updated_at INTEGER DEFAULT (unixepoch())\n);\n\n-- Create indexes\nCREATE INDEX IF NOT EXISTS idx_wrkflw_workflow_runs_workflow_id\nON wrkflw_workflow_runs(workflow_id);\n\nCREATE INDEX IF NOT EXISTS idx_wrkflw_workflow_runs_status\nON wrkflw_workflow_runs(status);\n\n-- Copy data from old table\n-- NOTE: This step will fail if 'workflow_runs' table doesn't exist.\n-- For fresh installations, this is expected - skip this step.\nINSERT OR IGNORE INTO wrkflw_workflow_runs (\n run_id, workflow_id, status, execution_path,\n step_results, state, input_data, result, error,\n created_at, updated_at\n)\nSELECT\n run_id, workflow_id, status, execution_path,\n step_results, state, input_data, result, error,\n created_at, updated_at\nFROM workflow_runs;\n\n-- Optional: Drop old table (only after verifying migration succeeded)\n-- DROP TABLE workflow_runs;\n-- DROP INDEX IF EXISTS idx_workflow_runs_workflow_id;\n-- DROP INDEX IF EXISTS idx_workflow_runs_status;\n```\n\n## Migration Safety\n\nThe migration process is designed to be **safe and non-destructive**:\n\n1. **No data loss**: Old table is preserved by default\n2. **Idempotent**: Can be run multiple times safely\n3. **Uses INSERT OR IGNORE**: Won't overwrite existing data in new table\n4. **Atomic operations**: Each step is a complete SQL transaction\n\n## Cleaning Up Old Tables\n\nAfter verifying that your application works correctly with the new table:\n\n1. Check that all data was migrated successfully\n2. Verify your application is using the new table\n3. Optionally, drop the old table manually:\n\n```typescript\nimport { sqlite } from \"https://esm.town/v/std/sqlite\";\n\n// Only do this after thorough verification!\nawait sqlite.execute(\"DROP TABLE IF EXISTS workflow_runs\");\nawait sqlite.execute(\"DROP INDEX IF EXISTS idx_workflow_runs_workflow_id\");\nawait sqlite.execute(\"DROP INDEX IF EXISTS idx_workflow_runs_status\");\n```\n\nOr using the migration API:\n\n```typescript\nimport { migrateWorkflowRunsTable } from \"./backend/migrations.ts\";\n\n// This will drop the old table\nawait migrateWorkflowRunsTable(true);\n```\n\n## Troubleshooting\n\n### Migration doesn't run\n\n- Ensure you're calling `WorkflowStorage.init()` before using storage\n- Check that you have the latest version with migration support\n\n### Data appears missing\n\n- Check if data is in the old table: `SELECT COUNT(*) FROM workflow_runs;`\n- Check if data is in the new table: `SELECT COUNT(*) FROM wrkflw_workflow_runs;`\n- The migration uses `INSERT OR IGNORE`, so existing records won't be duplicated\n\n### Performance concerns\n\n- The migration runs only once during initialization\n- For very large datasets (10,000+ rows), consider running migration during off-peak hours\n- The migration is fast for typical workflow run counts\n\n## Questions?\n\nIf you encounter any issues during migration, please open an issue on the GitHub repository.\n",[],[504],{"_106":511,"_96":512,"_161":513,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":514,"_102":32,"_169":346,"_171":515,"_172":22,"_173":-5,"_174":516,"_100":517},"ae1b4a2a-c55f-11f0-a174-42dde27851f2","PLAN.md","019a9cd0-c1e3-73bc-99fc-6605815f93ec",["D",1763567518186],"# Val Town Workflow Engine - Implementation Plan\n\n## Project Overview\n\nBuild a **TypeScript-first workflow engine** for Val Town inspired by Mastra's architecture, optimized for learning and personal automation use cases.\n\n---\n\n## Design Principles\n\n1. **Strong Typing**: Full TypeScript inference across workflow definitions\n2. **Composable**: Steps and workflows are composable units\n3. **Flexible Triggering**: Workflows as modules callable from any Val Town trigger (HTTP, Cron, Email)\n4. **Simple State Management**: SQLite-backed with ACID guarantees\n5. **Val Town Native**: Embrace platform constraints (no external dependencies)\n\n---\n\n## Architecture Overview\n\n```mermaid\ngraph TD\n A[Workflow Definition] -->|createWorkflow| B[Workflow Builder]\n B -->|.then| C[Step Chain]\n B -->|.commit| D[Executable Workflow]\n \n E[Step Definition] -->|createStep| F[Step Instance]\n F --> C\n \n D -->|.start| G[Execution Engine]\n G --> H[Step Execution]\n H --> I[SQLite State Store]\n \n J[HTTP Trigger] --> D\n K[Cron Trigger] --> D\n L[Email Trigger] --> D\n \n style A fill:#e1f5ff\n style D fill:#fff4e1\n style I fill:#ffe1f5\n```\n\n---\n\n## Phase 1: Core Engine (MVP)\n\n### Components to Build\n\n#### 1. **Step Definition** (`step.ts`)\n\n```typescript\ninterface StepConfig {\n id: TId;\n description?: string;\n inputSchema: z.ZodSchema;\n outputSchema: z.ZodSchema;\n stateSchema?: z.ZodSchema;\n execute: ExecuteFunction;\n}\n\ninterface ExecuteFunction {\n (context: {\n inputData: TInput;\n state?: TState;\n setState?: (state: TState) => void;\n getStepResult: (step: T) => z.infer;\n getInitData: () => any;\n }): Promise | TOutput;\n}\n\nfunction createStep(\n config: StepConfig\n): Step;\n```\n\n**Example Usage:**\n```typescript\nconst fetchUser = createStep({\n id: 'fetch-user',\n inputSchema: z.object({ userId: z.string() }),\n outputSchema: z.object({ \n name: z.string(), \n email: z.string() \n }),\n execute: async ({ inputData }) => {\n const user = await db.getUser(inputData.userId);\n return { name: user.name, email: user.email };\n }\n});\n```\n\n---\n\n#### 2. **Workflow Builder** (`workflow.ts`)\n\n```typescript\ninterface WorkflowConfig {\n id: TId;\n description?: string;\n inputSchema: z.ZodSchema;\n outputSchema: z.ZodSchema;\n stateSchema?: z.ZodSchema;\n}\n\nclass WorkflowBuilder {\n then(\n step: TStep\n ): WorkflowBuilder, TInput, TStep['outputSchema']>;\n \n commit(): Workflow;\n}\n\nfunction createWorkflow(\n config: WorkflowConfig\n): WorkflowBuilder<{}, TInput, TInput>;\n```\n\n**Example Usage:**\n```typescript\nconst emailWorkflow = createWorkflow({\n id: 'email-campaign',\n inputSchema: z.object({ userId: z.string() }),\n outputSchema: z.object({ sent: z.boolean() })\n})\n .then(fetchUser)\n .then(generateEmail)\n .then(sendEmail)\n .commit();\n\n// Fully typed!\ntype Output = z.infer;\n```\n\n---\n\n#### 3. **Execution Engine** (`engine.ts`)\n\n```typescript\ninterface ExecutionContext {\n workflowId: string;\n runId: string;\n executionPath: number[]; // Current position in step array\n stepResults: Record;\n state: Record;\n}\n\ninterface StepResult {\n status: 'success' | 'failed' | 'running';\n output?: T;\n error?: Error;\n timestamp: number;\n}\n\nclass ExecutionEngine {\n async execute(params: {\n workflow: Workflow;\n runId: string;\n inputData: TInput;\n initialState?: any;\n }): Promise {\n // 1. Initialize execution context\n // 2. Iterate through steps sequentially\n // 3. Execute each step with context\n // 4. Persist state after each step\n // 5. Return final output\n }\n \n private async executeStep(\n step: Step,\n context: ExecutionContext,\n inputData: any\n ): Promise;\n}\n```\n\n---\n\n#### 4. **State Persistence** (`storage.ts`)\n\n```typescript\ninterface WorkflowSnapshot {\n runId: string;\n workflowId: string;\n status: 'running' | 'success' | 'failed';\n executionPath: number[];\n stepResults: Record;\n state: Record;\n result?: any;\n error?: string;\n timestamp: number;\n}\n\nclass WorkflowStorage {\n constructor(private sqlite: typeof import('@std/sqlite'));\n\n async init(): Promise {\n await this.sqlite.execute(`\n CREATE TABLE IF NOT EXISTS wrkflw_workflow_runs (\n run_id TEXT PRIMARY KEY,\n workflow_id TEXT NOT NULL,\n status TEXT NOT NULL,\n execution_path TEXT,\n step_results TEXT,\n state TEXT,\n result TEXT,\n error TEXT,\n created_at INTEGER DEFAULT (unixepoch()),\n updated_at INTEGER DEFAULT (unixepoch())\n )\n `);\n }\n \n async saveSnapshot(snapshot: WorkflowSnapshot): Promise;\n async loadSnapshot(runId: string): Promise;\n async listRuns(workflowId?: string): Promise;\n}\n```\n\n---\n\n#### 5. **Run Management** (`run.ts`)\n\n```typescript\nclass WorkflowRun {\n constructor(\n private workflow: Workflow,\n private runId: string,\n private engine: ExecutionEngine,\n private storage: WorkflowStorage\n ) {}\n \n async start(params: {\n inputData: TInput;\n initialState?: any;\n }): Promise {\n return this.engine.execute({\n workflow: this.workflow,\n runId: this.runId,\n inputData: params.inputData,\n initialState: params.initialState\n });\n }\n}\n\n// On Workflow class\nclass Workflow {\n async createRun(runId?: string): Promise> {\n const id = runId || crypto.randomUUID();\n return new WorkflowRun(this, id, this.engine, this.storage);\n }\n}\n```\n\n---\n\n### Directory Structure\n\n```\nwrkflw/\n├── backend/\n│ ├── index.ts # Main entry point / exports\n│ ├── step.ts # Step definition & creation\n│ ├── workflow.ts # Workflow builder & class\n│ ├── engine.ts # Execution engine\n│ ├── storage.ts # SQLite persistence\n│ ├── run.ts # Run management\n│ └── types.ts # Shared TypeScript types\n├── examples/\n│ ├── email-workflow.ts # Example workflow\n│ ├── http-trigger.ts # HTTP trigger example\n│ └── cron-trigger.ts # Cron trigger example\n├── PLAN.md\n├── README.md\n└── deno.json\n```\n\n---\n\n## Implementation Tasks\n\n### Milestone 1: Type System & Builders\n\n- [ ] Define core types (`Step`, `Workflow`, `ExecutionContext`, `StepResult`)\n- [ ] Implement `createStep()` with Zod schema validation\n- [ ] Implement `createWorkflow()` with fluent builder\n- [ ] Add `.then()` method with type inference\n- [ ] Add `.commit()` to finalize workflow\n- [ ] Test type inference chain (compile-time checks)\n\n### Milestone 2: Execution Engine\n\n- [ ] Implement `ExecutionEngine` class\n- [ ] Sequential step execution loop\n- [ ] Build execution context with step results\n- [ ] Implement `getStepResult()` helper\n- [ ] Implement `getInitData()` helper\n- [ ] Error handling and result wrapping\n\n### Milestone 3: State Persistence\n\n- [ ] Create SQLite schema for workflow runs\n- [ ] Implement `WorkflowStorage` class\n- [ ] Add `saveSnapshot()` after each step\n- [ ] Add `loadSnapshot()` for debugging\n- [ ] Add `listRuns()` for observability\n\n### Milestone 4: Run Management\n\n- [ ] Implement `WorkflowRun` class\n- [ ] Add `createRun()` to Workflow\n- [ ] Add `start()` method\n- [ ] Generate/validate run IDs\n- [ ] Connect engine + storage\n\n### Milestone 5: Examples & Documentation\n\n- [ ] Create simple email workflow example\n- [ ] Create HTTP trigger val example\n- [ ] Create Cron trigger val example\n- [ ] Write README with usage examples\n- [ ] Document type inference patterns\n\n---\n\n## Example End-to-End Usage\n\n### 1. Define Workflow\n\n```typescript\n// backend/workflows/email-campaign.ts\nimport { createWorkflow, createStep } from \"../index.ts\";\nimport { z } from \"npm:zod\";\nimport { sqlite } from \"https://esm.town/v/std/sqlite\";\n\nconst fetchUser = createStep({\n id: \"fetch-user\",\n inputSchema: z.object({ userId: z.string() }),\n outputSchema: z.object({ name: z.string(), email: z.string() }),\n execute: async ({ inputData }) => {\n const result = await sqlite.execute({\n sql: \"SELECT name, email FROM users WHERE id = ?\",\n args: [inputData.userId],\n });\n return {\n name: result.rows[0][0] as string,\n email: result.rows[0][1] as string,\n };\n },\n});\n\nconst generateEmail = createStep({\n id: \"generate-email\",\n inputSchema: z.object({ name: z.string(), email: z.string() }),\n outputSchema: z.object({ subject: z.string(), body: z.string() }),\n execute: async ({ inputData }) => {\n return {\n subject: `Hello ${inputData.name}!`,\n body: `Welcome to our service, ${inputData.name}!`,\n };\n },\n});\n\nconst sendEmail = createStep({\n id: \"send-email\",\n inputSchema: z.object({\n email: z.string(),\n subject: z.string(),\n body: z.string(),\n }),\n outputSchema: z.object({ sent: z.boolean(), messageId: z.string() }),\n execute: async ({ inputData, getStepResult }) => {\n // Access previous step results\n const user = getStepResult(fetchUser);\n \n // Send email logic\n const result = await sendEmailAPI({\n to: user.email,\n subject: inputData.subject,\n body: inputData.body,\n });\n \n return { sent: true, messageId: result.id };\n },\n});\n\nexport const emailCampaign = createWorkflow({\n id: \"email-campaign\",\n inputSchema: z.object({ userId: z.string() }),\n outputSchema: z.object({ sent: z.boolean(), messageId: z.string() }),\n})\n .then(fetchUser)\n .then(generateEmail)\n .then(sendEmail)\n .commit();\n```\n\n### 2. HTTP Trigger\n\n```typescript\n// backend/triggers/http.ts\nimport { emailCampaign } from \"../workflows/email-campaign.ts\";\n\nexport default async function(req: Request) {\n const url = new URL(req.url);\n const userId = url.searchParams.get(\"userId\");\n \n if (!userId) {\n return Response.json({ error: \"Missing userId\" }, { status: 400 });\n }\n \n // Create and start a run\n const run = await emailCampaign.createRun();\n const result = await run.start({ inputData: { userId } });\n \n return Response.json({\n success: true,\n runId: run.runId,\n result\n });\n}\n```\n\n### 3. Cron Trigger\n\n```typescript\n// backend/triggers/cron.ts\nimport { emailCampaign } from \"../workflows/email-campaign.ts\";\nimport { sqlite } from \"https://esm.town/v/std/sqlite\";\n\nexport default async function(interval: Interval) {\n // Get users who signed up today\n const users = await sqlite.execute({\n sql: `SELECT user_id FROM users \n WHERE date(created_at) = date('now')`,\n });\n \n // Run workflow for each user\n for (const row of users.rows) {\n const userId = row[0] as string;\n const run = await emailCampaign.createRun();\n \n try {\n await run.start({ inputData: { userId } });\n console.log(`Sent welcome email to ${userId}`);\n } catch (error) {\n console.error(`Failed to send to ${userId}:`, error);\n }\n }\n}\n```\n\n---\n\n## Technical Decisions\n\n### Type Inference Strategy\n\nFollowing Mastra's approach:\n- Use generic type parameters on builders\n- Thread `TPrevOutput` through `.then()` chain\n- Each step's output becomes next step's input type\n- Zod schemas provide runtime validation + type extraction\n\n### State Management (Phase 1)\n\n**Simplified approach for MVP:**\n- SQLite for all workflow state (no blob storage)\n- JSON serialization for step results\n- Snapshot after each step execution\n- Single database transaction per step\n\n### Error Handling (Phase 1)\n\n**Basic error wrapping:**\n- Try/catch around step execution\n- Capture error in `StepResult`\n- Persist failed state to SQLite\n- Throw error to caller (no retry logic yet)\n\n### Execution Model (Phase 1)\n\n**Synchronous execution:**\n- Run executes all steps in single Val Town invocation\n- No suspend/resume (Phase 2)\n- No parallel execution (Phase 2)\n- Sequential only with `.then()`\n\n---\n\n## Future Extensions (Post-MVP)\n\n### Phase 2: Advanced Control Flow\n- `.parallel([step1, step2])` - Concurrent execution\n- `.branch([[condition, stepA], ...])` - Conditional branching\n- `.map({ ... })` - Data transformation between steps\n\n### Phase 3: Durability\n- `.sleep(duration)` - Time-based delays via Cron\n- Suspend/resume for long-running workflows\n- Restart from last checkpoint\n\n### Phase 4: Advanced Features\n- `.foreach(step, { concurrency })` - Array iteration\n- Nested workflows (workflows as steps)\n- Retry logic and exponential backoff\n- Workflow-level state (beyond step results)\n\n### Phase 5: Observability\n- Event streaming for step progress\n- Run history and debugging UI\n- Time-travel debugging\n- Execution visualizations\n\n---\n\n## Success Criteria\n\n**Phase 1 MVP is complete when:**\n1. ✅ Can define strongly-typed steps with Zod schemas\n2. ✅ Can chain steps with `.then()` and type inference works\n3. ✅ Can execute workflows and get typed output\n4. ✅ Step results are accessible via `getStepResult()`\n5. ✅ Workflow state persists to SQLite after each step\n6. ✅ Can trigger workflows from HTTP and Cron vals\n7. ✅ Examples demonstrate personal automation use cases\n\n---\n\n## Open Questions\n\n1. **Validation**: Should we validate schemas at runtime (dev mode) or trust TypeScript?\n2. **Errors**: Should failed steps stop workflow or allow continuation?\n3. **Logging**: Use `console.log` or build custom logger?\n4. **Testing**: Add test examples or just examples?\n\n---\n\n## Next Steps\n\n1. Set up project structure\n2. Implement type system (`types.ts`)\n3. Build `createStep()` function\n4. Build `createWorkflow()` builder\n5. Test type inference manually\n6. Implement execution engine\n7. Add SQLite storage\n8. Create examples\n\n---\n\n**Ready to start building!** 🚀\n",[],[512],{"_106":519,"_96":425,"_161":520,"_163":-5,"_164":144,"_165":166,"_167":22,"_108":521,"_102":32,"_169":346,"_171":522,"_172":22,"_173":-5,"_174":523,"_100":524},"ae1b5718-c55f-11f0-a174-42dde27851f2","019a9cd0-c1e3-73bc-99fc-6abafbb0ead4",["D",1763567518186],"# wrkflw\n\nA **TypeScript-first workflow engine** for Val Town, inspired by [Mastra](https://github.com/mastra-ai/mastra).\n\nBuild strongly-typed, composable workflows that run on Val Town's serverless platform.\n\n## Features\n\n- **Strongly Typed**: Full TypeScript inference across workflow definitions\n- **Composable**: Build workflows from reusable steps\n- **Trigger Agnostic**: Works with HTTP, Cron, or Email Val Town triggers\n- **Durable State**: SQLite-backed persistence with ACID guarantees\n- **Runtime Validation**: Zod schema validation for inputs and outputs\n- **Error Handling**: Structured error tracking and recovery\n- **Visual Workflows**: Generate Mermaid diagrams of workflow structure and execution state\n\n## Quick Start\n\n### 1. Define Steps\n\n```typescript\nimport { createStep } from \"./backend/index.ts\";\nimport { z } from \"npm:zod@^3.23\";\n\nconst fetchUser = createStep({\n id: 'fetch-user',\n inputSchema: z.object({ userId: z.string() }),\n outputSchema: z.object({ name: z.string(), email: z.string() }),\n execute: async ({ inputData }) => {\n const user = await db.getUser(inputData.userId);\n return { name: user.name, email: user.email };\n },\n});\n```\n\n### 2. Build Workflows\n\n```typescript\nimport { createWorkflow } from \"./backend/index.ts\";\n\nconst emailWorkflow = createWorkflow({\n id: 'email-campaign',\n inputSchema: z.object({ userId: z.string() }),\n outputSchema: z.object({ sent: z.boolean() }),\n})\n .then(fetchUser) // Type: { userId: string } -> { name, email }\n .then(generateEmail) // Type: { name, email } -> { subject, body }\n .then(sendEmail) // Type: { subject, body } -> { sent }\n .commit();\n```\n\n### 3. Execute Workflows\n\n```typescript\n// Create a run\nconst run = await emailWorkflow.createRun();\n\n// Execute\nconst result = await run.start({\n inputData: { userId: 'user-123' },\n});\n\nconsole.log(result); // { sent: true }\n```\n\n## Prebuilt Steps\n\nwrkflw includes a collection of ready-to-use steps for common tasks:\n\n### HTTP/API Steps\n\n**`httpGet`** - Make GET requests to APIs\n```typescript\nimport { httpGet, createWorkflow } from \"./backend/index.ts\";\n\nconst workflow = createWorkflow({\n id: 'fetch-api-data',\n inputSchema: z.object({\n url: z.string().url(),\n headers: z.record(z.string()).optional(),\n queryParams: z.record(z.string()).optional(),\n }),\n outputSchema: z.object({\n status: z.number(),\n data: z.unknown(),\n headers: z.record(z.string()),\n }),\n})\n .then(httpGet)\n .commit();\n```\n\n**`httpPost`** - POST JSON data to APIs\n```typescript\nimport { httpPost } from \"./backend/index.ts\";\n\n// Use in workflow with inputData: { url, body, headers? }\n```\n\n### String/Template Steps\n\n**`template`** - String interpolation with variables\n```typescript\nimport { template } from \"./backend/index.ts\";\n\nconst workflow = createWorkflow({\n inputSchema: z.object({\n template: z.string(),\n variables: z.record(z.union([z.string(), z.number(), z.boolean()])),\n }),\n outputSchema: z.object({ result: z.string() }),\n})\n .then(template)\n .commit();\n\n// Input: { template: \"Hello {{name}}!\", variables: { name: \"Alice\" } }\n// Output: { result: \"Hello Alice!\" }\n```\n\n### Data Transformation Steps\n\n**`filterArray`** - Filter array items by condition\n```typescript\nimport { filterArray } from \"./backend/index.ts\";\n\n// Input: {\n// array: [1, 2, 3, 4, 5],\n// filterFn: \"(n) => n % 2 === 0\"\n// }\n// Output: {\n// filtered: [2, 4],\n// originalCount: 5,\n// filteredCount: 2\n// }\n```\n\n**`mapArray`** - Transform array items\n```typescript\nimport { mapArray } from \"./backend/index.ts\";\n\n// Input: {\n// array: [1, 2, 3],\n// mapFn: \"(n) => n * 2\"\n// }\n// Output: { mapped: [2, 4, 6], count: 3 }\n```\n\n**`pickFields`** - Extract specific fields from objects\n```typescript\nimport { pickFields } from \"./backend/index.ts\";\n\n// Input: {\n// object: { id: 1, name: \"Alice\", secret: \"xyz\" },\n// fields: [\"id\", \"name\"]\n// }\n// Output: { result: { id: 1, name: \"Alice\" } }\n```\n\n### Utility Steps\n\n**`delay`** - Wait for a specified duration\n```typescript\nimport { delay } from \"./backend/index.ts\";\n\n// Input: { durationMs: 2000 }\n// Waits 2 seconds, then outputs: { durationMs: 2000, completedAt: \"...\" }\n```\n\n**`logger`** - Structured logging at different levels\n```typescript\nimport { logger } from \"./backend/index.ts\";\n\n// Input: {\n// level: \"info\",\n// message: \"Processing data\",\n// data: { count: 10 }\n// }\n// Logs to console and passes data through\n```\n\n### Complete Example with Prebuilt Steps\n\n```typescript\nimport {\n createWorkflow,\n createStep,\n httpGet,\n filterArray,\n mapArray,\n template\n} from \"./backend/index.ts\";\n\n// Helper step to prepare API request\nconst prepareRequest = createStep({\n id: \"prepare-request\",\n inputSchema: z.object({ userId: z.number() }),\n outputSchema: z.object({\n url: z.string(),\n queryParams: z.record(z.string()).optional(),\n }),\n execute: async ({ inputData }) => ({\n url: \"https://api.example.com/posts\",\n queryParams: { userId: String(inputData.userId) },\n }),\n});\n\n// Build workflow using prebuilt steps\nconst workflow = createWorkflow({\n id: 'process-user-posts',\n inputSchema: z.object({ userId: z.number() }),\n outputSchema: z.object({ titles: z.array(z.string()) }),\n})\n .then(prepareRequest) // Convert input to API request\n .then(httpGet) // Fetch from API (prebuilt)\n // Add more steps as needed\n .commit();\n```\n\nSee `examples/prebuilt-steps-simple.ts` for more examples.\n\n## Installation\n\n### For Val Town\n\n1. Create a new val or project in Val Town\n2. Copy the `backend/` directory into your val\n3. Import and use:\n\n```typescript\nimport { createStep, createWorkflow } from \"./backend/index.ts\";\n```\n\n### For Local Development\n\n```bash\ngit clone \ncd wrkflw\ndeno run --allow-all examples/simple-workflow.ts\n```\n\n## Examples\n\n### HTTP Trigger\n\nCreate a new HTTP val in Val Town:\n\n```typescript\nimport { emailWorkflow } from \"./workflows/email-campaign.ts\";\n\nexport default async function(req: Request) {\n const url = new URL(req.url);\n const userId = url.searchParams.get(\"userId\");\n \n if (!userId) {\n return Response.json({ error: \"Missing userId\" }, { status: 400 });\n }\n \n const run = await emailWorkflow.createRun();\n const result = await run.start({ inputData: { userId } });\n \n return Response.json({ success: true, result });\n}\n```\n\n### Cron Trigger\n\nCreate a new Cron val in Val Town:\n\n```typescript\nimport { welcomeWorkflow } from \"./workflows/welcome.ts\";\n\nexport default async function(interval: Interval) {\n // Get users who signed up in the last hour\n const newUsers = await getRecentUsers();\n \n for (const user of newUsers) {\n const run = await welcomeWorkflow.createRun();\n await run.start({ inputData: { userId: user.id } });\n console.log(`Sent welcome email to ${user.id}`);\n }\n}\n```\n\n### Email Trigger\n\nCreate a new Email val in Val Town:\n\n```typescript\nimport { supportWorkflow } from \"./workflows/support.ts\";\n\nexport default async function(email: Email) {\n const run = await supportWorkflow.createRun();\n \n const result = await run.start({\n inputData: {\n from: email.from,\n subject: email.subject,\n body: email.text,\n },\n });\n \n console.log(`Processed support email: ${result.ticketId}`);\n}\n```\n\n## API Reference\n\n### `createStep(config)`\n\nCreate a typed workflow step.\n\n```typescript\ncreateStep({\n id: 'step-id',\n description: 'Optional description',\n inputSchema: z.object({ /* input type */ }),\n outputSchema: z.object({ /* output type */ }),\n execute: async ({ inputData, getStepResult, getInitData }) => {\n // Your logic here\n return { /* matches outputSchema */ };\n },\n});\n```\n\n**Execute Context:**\n- `inputData` - Validated input for this step\n- `getStepResult(step)` - Get output from a previous step\n- `getInitData()` - Get the workflow's initial input\n- `state` - Workflow-level state (if defined)\n- `setState(newState)` - Update workflow state\n- `runId` - Current run ID\n- `workflowId` - Current workflow ID\n\n### `createWorkflow(config)`\n\nCreate a typed workflow builder.\n\n```typescript\ncreateWorkflow({\n id: 'workflow-id',\n description: 'Optional description',\n inputSchema: z.object({ /* input type */ }),\n outputSchema: z.object({ /* output type */ }),\n stateSchema: z.object({ /* optional state */ }),\n})\n .then(step1)\n .then(step2)\n .commit();\n```\n\n**Builder Methods:**\n- `.then(step)` - Add a sequential step\n- `.commit()` - Finalize the workflow\n\n### `workflow.createRun(runId?)`\n\nCreate a new workflow run instance.\n\n```typescript\nconst run = await workflow.createRun(); // Auto-generated ID\n// or\nconst run = await workflow.createRun('custom-run-id');\n```\n\n### `run.start(params)`\n\nExecute the workflow.\n\n```typescript\nconst result = await run.start({\n inputData: { /* matches workflow.inputSchema */ },\n initialState: { /* optional, matches workflow.stateSchema */ },\n});\n```\n\n### `run.getSnapshot()`\n\nGet the current state snapshot.\n\n```typescript\nconst snapshot = await run.getSnapshot();\nconsole.log({\n status: snapshot.status, // 'running' | 'success' | 'failed'\n stepResults: snapshot.stepResults, // Results from each step\n executionPath: snapshot.executionPath, // Steps executed\n});\n```\n\n## Type Inference\n\nThe workflow builder automatically infers types through the chain:\n\n```typescript\nconst step1 = createStep({\n inputSchema: z.object({ a: z.string() }),\n outputSchema: z.object({ b: z.number() }),\n execute: async ({ inputData }) => ({ b: 42 }),\n});\n\nconst step2 = createStep({\n inputSchema: z.object({ b: z.number() }), // Must match step1's output\n outputSchema: z.object({ c: z.boolean() }),\n execute: async ({ inputData }) => ({ c: true }),\n});\n\nconst workflow = createWorkflow({\n inputSchema: z.object({ a: z.string() }),\n outputSchema: z.object({ c: z.boolean() }),\n})\n .then(step1) // Accepts { a: string }\n .then(step2) // Accepts { b: number } from step1\n .commit();\n\n// TypeScript knows the output is { c: boolean }\n```\n\nIf step types don't match, TypeScript will show a compile error:\n\n```typescript\nconst incompatibleStep = createStep({\n inputSchema: z.object({ x: z.string() }), // Error: doesn't match step1 output\n outputSchema: z.object({ y: z.string() }),\n execute: async ({ inputData }) => ({ y: \"value\" }),\n});\n\nworkflow.then(step1).then(incompatibleStep); // TypeScript error\n```\n\n## Error Handling\n\nErrors are automatically captured and persisted:\n\n```typescript\ntry {\n const result = await run.start({ inputData });\n} catch (error) {\n // Workflow failed - snapshot saved with error\n const snapshot = await run.getSnapshot();\n console.log(snapshot.status); // 'failed'\n console.log(snapshot.error); // Error message\n}\n```\n\n## State Management\n\nDefine workflow-level state that persists across steps:\n\n```typescript\nconst workflow = createWorkflow({\n id: 'stateful-workflow',\n inputSchema: z.object({ start: z.number() }),\n outputSchema: z.object({ total: z.number() }),\n stateSchema: z.object({ counter: z.number() }),\n});\n\nconst incrementStep = createStep({\n id: 'increment',\n inputSchema: z.object({ start: z.number() }),\n outputSchema: z.object({ value: z.number() }),\n execute: async ({ inputData, state, setState }) => {\n const newCounter = (state?.counter || 0) + inputData.start;\n setState({ counter: newCounter });\n return { value: newCounter };\n },\n});\n```\n\n## Storage\n\nAll workflow runs are persisted to Val Town's SQLite database:\n\n```typescript\nimport { WorkflowStorage } from \"./backend/index.ts\";\n\nconst storage = new WorkflowStorage();\nawait storage.init();\n\n// List all runs\nconst runs = await storage.listRuns();\n\n// List runs for specific workflow\nconst workflowRuns = await storage.listRuns('my-workflow-id');\n\n// Get runs by status\nconst failedRuns = await storage.getRunsByStatus('failed');\n```\n\n## Workflow Visualization\n\nwrkflw includes built-in visualization capabilities to help you understand and debug your workflows. You can generate visual diagrams in multiple formats (currently Mermaid, with more formats planned).\n\n### Visualize Workflow Structure\n\nGenerate a diagram showing the static structure of your workflow:\n\n```typescript\nconst workflow = createWorkflow({\n id: 'data-processing',\n inputSchema: z.object({ url: z.string() }),\n outputSchema: z.object({ saved: z.boolean() }),\n})\n .then(fetchData)\n .then(processData)\n .then(saveResults)\n .commit();\n\n// Generate Mermaid diagram\nconst diagram = workflow.visualize(\"mermaid\");\nconsole.log(diagram);\n```\n\nOutput:\n```mermaid\ngraph TD\n Start([data-processing])\n fetch_data[fetch-data
Fetch data from API]\n Start --> fetch_data\n process_data[process-data
Process and transform data]\n fetch_data --> process_data\n save_results[save-results
Save to database]\n process_data --> save_results\n End([End])\n save_results --> End\n```\n\n### Visualize Execution State\n\nGenerate a diagram showing the current state of a workflow run:\n\n```typescript\nconst run = await workflow.createRun();\nawait run.start({ inputData: { url: \"https://api.example.com/data\" } });\n\n// Visualize execution state\nconst executionDiagram = await run.visualize(\"mermaid\", {\n highlightCurrentStep: true,\n showStatus: true,\n});\n\nconsole.log(executionDiagram);\n```\n\nThe execution visualization includes:\n- ✓ Checkmarks for completed steps\n- ✗ X marks for failed steps\n- ● Dots for currently running steps\n- Color-coded step states (success, failed, running, pending)\n- Error messages for failed steps\n\n### Visualization Options\n\nBoth workflow and execution visualizations support various options:\n\n```typescript\n// Workflow structure options\nworkflow.visualize(\"mermaid\", {\n includeDescriptions: true, // Show step descriptions (default: true)\n includeSchemas: false, // Show schema info (not yet implemented)\n});\n\n// Execution state options\nawait run.visualize(\"mermaid\", {\n includeDescriptions: true, // Show step descriptions (default: true)\n highlightCurrentStep: true, // Highlight the current/last step (default: true)\n showStatus: true, // Show status icons (default: true)\n showResults: false, // Show step results (default: false)\n});\n```\n\n### Rendering Diagrams\n\nMermaid diagrams can be rendered in multiple ways:\n\n1. **GitHub/GitLab**: Paste into markdown files (rendered automatically)\n2. **Mermaid Live Editor**: Copy to [mermaid.live](https://mermaid.live)\n3. **VS Code**: Use the Mermaid Preview extension\n4. **Documentation sites**: Most support Mermaid natively\n\n### Using Visualization Functions Directly\n\nYou can also use the visualization functions directly without calling methods on workflow/run instances:\n\n```typescript\nimport { visualizeWorkflow, visualizeExecution } from \"./backend/index.ts\";\n\n// Visualize workflow structure\nconst diagram = visualizeWorkflow(workflow, \"mermaid\", {\n includeDescriptions: true,\n});\n\n// Visualize execution with snapshot\nconst snapshot = await run.getSnapshot();\nif (snapshot) {\n const executionDiagram = visualizeExecution(\n workflow,\n snapshot,\n \"mermaid\",\n { showStatus: true }\n );\n}\n```\n\n### Future Visualization Formats\n\nThe visualization API is designed to be extensible. Planned formats include:\n\n- **JSON**: Graph data for custom visualization libraries (D3, Cytoscape)\n- **ASCII**: Text-based diagrams for CLI/terminal output\n- **DOT**: Graphviz format for advanced layout algorithms\n\nSee `examples/workflow-visualization.ts` for a complete example.\n\n## Canvas Visualizer (React App)\n\nwrkflw includes a powerful React-based canvas visualizer that provides real-time, interactive workflow visualization. Unlike the text-based Mermaid diagrams, the canvas visualizer offers a dynamic, web-based UI for monitoring and debugging workflows.\n\n### Features\n\n- **Interactive Canvas**: Pan, zoom, and navigate workflow diagrams with smooth animations\n- **Real-time Updates**: Watch workflow execution live with auto-refresh\n- **Step Details**: Click on nodes to view outputs, errors, and execution status\n- **Execution History**: Browse past workflow runs and their results\n- **Multiple Workflows**: Switch between different workflows seamlessly\n- **Status Indicators**: Visual feedback for running, success, and failed steps\n\n### Quick Start\n\n1. **Start the API Server**:\n```bash\n# From the root directory\ndeno run --allow-all examples/api-server-example.ts\n```\n\n2. **Start the Frontend**:\n```bash\ncd frontend\nnpm install\nnpm run dev\n```\n\n3. **Open the Visualizer**:\nVisit `http://localhost:3000` in your browser\n\n### Usage\n\n```typescript\nimport { createApiServer, WorkflowStorage } from \"./backend/index.ts\";\n\n// Initialize storage and API server\nconst storage = new WorkflowStorage();\nawait storage.init();\nconst apiServer = createApiServer(storage);\n\n// Register your workflows\napiServer.registerWorkflow(dataProcessingWorkflow, {\n url: \"https://api.example.com/data\" // Example input\n});\n\n// Start the server\nawait apiServer.serve(8000);\n```\n\nThe canvas visualizer will automatically:\n- Display all registered workflows in the sidebar\n- Show workflow structure with connected nodes\n- Update in real-time as workflows execute\n- Highlight running steps with animations\n- Show success/failure states with color coding\n- Display step outputs and error messages\n\n### API Endpoints\n\nThe API server exposes the following endpoints for the visualizer:\n\n```\nGET /api/workflows - List all registered workflows\nGET /api/workflows/:id - Get workflow details\nGET /api/workflows/:id/runs - List runs for a workflow\nPOST /api/workflows/:id/runs - Create and start a new run\nGET /api/runs/:runId - Get detailed run status\n```\n\n### Architecture\n\n```\n┌──────────────────┐ HTTP ┌──────────────────┐\n│ React Frontend │ ◄─────────► │ Deno API Server │\n│ (Port 3000) │ /api/* │ (Port 8000) │\n└──────────────────┘ └──────────────────┘\n │ │\n │ React Flow │ Workflow Engine\n │ Canvas Rendering │ SQLite Storage\n ▼ ▼\n Visualizer UI Execution State\n```\n\nSee `frontend/README.md` for detailed documentation and customization options.\n\n## Project Structure\n\n```\nwrkflw/\n├── backend/\n│ ├── index.ts # Main exports\n│ ├── types.ts # TypeScript types\n│ ├── step.ts # Step creation\n│ ├── workflow.ts # Workflow builder\n│ ├── engine.ts # Execution engine\n│ ├── storage.ts # SQLite persistence\n│ ├── run.ts # Run management\n│ ├── visualize.ts # Workflow visualization\n│ ├── api-server.ts # API server for canvas visualizer\n│ └── prebuilt-steps.ts # Ready-to-use steps\n├── frontend/\n│ ├── src/\n│ │ ├── components/\n│ │ │ ├── WorkflowVisualizer.tsx # Main canvas component\n│ │ │ ├── StepNode.tsx # Custom step node\n│ │ │ ├── WorkflowVisualizer.css\n│ │ │ └── StepNode.css\n│ │ ├── App.tsx # Main app component\n│ │ ├── types.ts # Frontend types\n│ │ └── main.tsx # Entry point\n│ ├── package.json\n│ ├── vite.config.ts\n│ └── README.md\n├── examples/\n│ ├── simple-workflow.ts\n│ ├── http-trigger.ts\n│ ├── cron-trigger.ts\n│ ├── prebuilt-steps-simple.ts\n│ ├── workflow-visualization.ts\n│ └── api-server-example.ts # Canvas visualizer demo\n├── PLAN.md\n└── README.md\n```\n\n## Complete Example\n\nHere's a full example of a workflow that fetches data, processes it, and sends a notification:\n\n```typescript\nimport { createWorkflow, createStep } from \"./backend/index.ts\";\nimport { z } from \"npm:zod@^3.23\";\n\n// Step 1: Fetch data from an API\nconst fetchData = createStep({\n id: 'fetch-data',\n inputSchema: z.object({ url: z.string() }),\n outputSchema: z.object({ data: z.array(z.any()) }),\n execute: async ({ inputData }) => {\n const response = await fetch(inputData.url);\n const data = await response.json();\n return { data };\n },\n});\n\n// Step 2: Process the data\nconst processData = createStep({\n id: 'process-data',\n inputSchema: z.object({ data: z.array(z.any()) }),\n outputSchema: z.object({ \n count: z.number(), \n summary: z.string() \n }),\n execute: async ({ inputData }) => {\n return {\n count: inputData.data.length,\n summary: `Processed ${inputData.data.length} items`,\n };\n },\n});\n\n// Step 3: Send notification\nconst sendNotification = createStep({\n id: 'send-notification',\n inputSchema: z.object({ count: z.number(), summary: z.string() }),\n outputSchema: z.object({ sent: z.boolean() }),\n execute: async ({ inputData, getStepResult }) => {\n // Access original data from first step\n const originalData = getStepResult(fetchData);\n \n console.log(`Sending notification: ${inputData.summary}`);\n // Send to Slack, Discord, etc.\n \n return { sent: true };\n },\n});\n\n// Build the workflow\nexport const dataProcessingWorkflow = createWorkflow({\n id: 'data-processing',\n inputSchema: z.object({ url: z.string() }),\n outputSchema: z.object({ sent: z.boolean() }),\n})\n .then(fetchData)\n .then(processData)\n .then(sendNotification)\n .commit();\n\n// Use in an HTTP val\nexport default async function(req: Request) {\n const { url } = await req.json();\n \n const run = await dataProcessingWorkflow.createRun();\n const result = await run.start({ inputData: { url } });\n \n return Response.json(result);\n}\n```\n\n## Architecture\n\n```\n┌─────────────────────────────────────────────────────────┐\n│ Val Town Trigger │\n│ (HTTP / Cron / Email val) │\n└─────────────────┬───────────────────────────────────────┘\n │\n ▼\n┌─────────────────────────────────────────────────────────┐\n│ Workflow Instance │\n│ - createRun() creates a new execution │\n│ - start() begins execution │\n└─────────────────┬───────────────────────────────────────┘\n │\n ▼\n┌─────────────────────────────────────────────────────────┐\n│ Execution Engine │\n│ - Validates inputs with Zod schemas │\n│ - Executes steps sequentially │\n│ - Captures errors and results │\n└─────────────────┬───────────────────────────────────────┘\n │\n ▼\n┌─────────────────────────────────────────────────────────┐\n│ Step Execution Context │\n│ - inputData: validated input │\n│ - getStepResult(): access previous steps │\n│ - getInitData(): access workflow input │\n│ - state/setState: workflow-level state │\n└─────────────────┬───────────────────────────────────────┘\n │\n ▼\n┌─────────────────────────────────────────────────────────┐\n│ SQLite Storage │\n│ - Saves snapshot after each step │\n│ - Tracks execution path and results │\n│ - Enables debugging and recovery │\n└─────────────────────────────────────────────────────────┘\n```\n\n## Roadmap\n\n**Phase 1 (Complete):** Core engine with sequential execution \n**Phase 2:** Advanced control flow (parallel, branching, loops) \n**Phase 3:** Durability (suspend/resume, sleep) \n**Phase 4:** Enhanced features (foreach, nested workflows, retries) \n**Phase 5:** Observability (streaming, debugging UI)\n\n## Contributing\n\nThis is an experimental project for learning and personal automation. Contributions, ideas, and feedback are welcome.\n\n## Inspiration\n\nThis project is heavily inspired by [Mastra](https://github.com/mastra-ai/mastra), adapted for Val Town's serverless environment and optimized for personal automation use cases.\n\n## License\n\nMIT\n",[],[425],{"_106":526,"_96":527,"_161":528,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":529,"_102":32,"_169":346,"_171":530,"_172":22,"_173":-5,"_174":531,"_100":532},"ae1b6c08-c55f-11f0-a174-42dde27851f2","biome.json","019a9cd0-c1e3-73bc-99fc-6e9e61fc5e39",["D",1763567518186],"{\n\t\"$schema\": \"https://biomejs.dev/schemas/2.3.5/schema.json\",\n\t\"vcs\": { \"enabled\": true, \"clientKind\": \"git\", \"useIgnoreFile\": true },\n\t\"files\": { \"ignoreUnknown\": false },\n\t\"formatter\": { \"enabled\": true, \"indentStyle\": \"tab\" },\n\t\"linter\": { \"enabled\": true, \"rules\": { \"recommended\": true } },\n\t\"javascript\": { \"formatter\": { \"quoteStyle\": \"double\" } },\n\t\"assist\": {\n\t\t\"enabled\": true,\n\t\t\"actions\": { \"source\": { \"organizeImports\": \"on\" } }\n\t}\n}\n",[],[527],{"_106":534,"_96":535,"_161":536,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":537,"_102":32,"_169":346,"_171":538,"_172":22,"_173":-5,"_174":539,"_100":540},"ae1b6d98-c55f-11f0-a174-42dde27851f2","deno.json","019a9cd0-c1e3-73bc-99fc-7349b1fae9f0",["D",1763567518186],"{\n\t\"$schema\": \"https://raw.githubusercontent.com/denoland/deno/348900b8b79f4a434cab4c74b3bc8d4d2fa8ee74/cli/schemas/config-file.v1.json\",\n\t\"compilerOptions\": {\n\t\t\"lib\": [\n\t\t\t\"dom\",\n\t\t\t\"dom.iterable\",\n\t\t\t\"dom.asynciterable\",\n\t\t\t\"deno.ns\",\n\t\t\t\"deno.unstable\"\n\t\t],\n\t\t\"noImplicitAny\": false,\n\t\t\"strict\": false,\n\t\t\"types\": [\"https://www.val.town/types/valtown.d.ts\"]\n\t},\n\t\"experimental\": {\n\t\t\"unstable-node-globals\": true,\n\t\t\"unstable-sloppy-imports\": true,\n\t\t\"unstable-temporal\": true,\n\t\t\"unstable-worker-options\": true\n\t},\n\t\"imports\": {\n\t\t\"@biomejs/biome\": \"npm:@biomejs/biome@^2.3.5\"\n\t},\n\t\"lint\": {\n\t\t\"files\": {\n\t\t\t\"include\": [\"deno:/https/esm.town/**/*\"]\n\t\t},\n\t\t\"rules\": {\n\t\t\t\"exclude\": [\"no-explicit-any\", \"no-import-prefix\"]\n\t\t}\n\t},\n\t\"lock\": false,\n\t\"nodeModulesDir\": \"auto\"\n}\n",[],[535],{"_106":542,"_96":543,"_161":544,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":545,"_102":32,"_169":181,"_171":546,"_172":22,"_173":-5,"_174":547,"_100":548},"ae1b6eec-c55f-11f0-a174-42dde27851f2","test_migration.ts","019a9cd0-c1e3-73bc-99fc-75bca85604eb",["D",1763567518186],"/**\n * Migration test script\n *\n * This script demonstrates how the migration works.\n * Note: This is for documentation purposes. In Val Town, you would run this\n * directly in your environment.\n */\n\nimport { generateMigrationSQL } from \"./backend/migrations.ts\";\n\nconsole.log(\"=== wrkflw Table Migration Test ===\\n\");\n\n// Test 1: Generate migration SQL\nconsole.log(\"1. Generated Migration SQL (without dropping old table):\");\nconsole.log(\"---\");\nconst sql = generateMigrationSQL(false);\nconsole.log(sql);\nconsole.log(\"\\n\");\n\n// Test 2: Show what would happen during automatic migration\nconsole.log(\"2. Automatic Migration Process:\");\nconsole.log(\"---\");\nconsole.log(\"When you call WorkflowStorage.init(), the following happens:\");\nconsole.log(\" a) Check if 'workflow_runs' table exists\");\nconsole.log(\" b) Create 'wrkflw_workflow_runs' table if needed\");\nconsole.log(\" c) Copy all data from old table to new table\");\nconsole.log(\" d) Create indexes on new table\");\nconsole.log(\" e) Old table is preserved for safety\");\nconsole.log(\"\\n\");\n\n// Test 3: Manual migration example\nconsole.log(\"3. Manual Migration Example:\");\nconsole.log(\"---\");\nconsole.log(\"import { runMigrations } from './backend/migrations.ts';\");\nconsole.log(\"\");\nconsole.log(\"// Run migration (keeps old table)\");\nconsole.log(\"const results = await runMigrations();\");\nconsole.log(\"console.log(results[0].message);\");\nconsole.log(\"console.log(`Migrated ${results[0].rowCount} rows`);\");\nconsole.log(\"\\n\");\n\n// Test 4: Table naming verification\nconsole.log(\"4. Table Naming Scheme:\");\nconsole.log(\"---\");\nconsole.log(\"Old table name: workflow_runs\");\nconsole.log(\"New table name: wrkflw_workflow_runs\");\nconsole.log(\"Old index names:\");\nconsole.log(\" - idx_workflow_runs_workflow_id\");\nconsole.log(\" - idx_workflow_runs_status\");\nconsole.log(\"New index names:\");\nconsole.log(\" - idx_wrkflw_workflow_runs_workflow_id\");\nconsole.log(\" - idx_wrkflw_workflow_runs_status\");\nconsole.log(\"\\n\");\n\nconsole.log(\"=== All table names now use wrkflw_ prefix ===\");\n",[],[543],{"_106":550,"_96":551,"_161":552,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":553,"_102":32,"_169":346,"_171":554,"_172":22,"_173":-5,"_174":555,"_100":556},"ae1b7162-c55f-11f0-a174-42dde27851f2","workflow-engines-research-report.md","019a9cd0-c1e4-73a8-a983-dfbc57b1e66f",["D",1763567518186],"# Code-First Workflow Engines: Architectural Patterns and Design Decisions\n\n**Research Report** \n*November 2025*\n\n---\n\n## Executive Summary\n\nThis report analyzes the architectural patterns and design decisions across modern code-first workflow engines. Based on research of major platforms including Temporal, Airflow, Prefect, Dagster, and others, we identify seven core architectural patterns and key trade-offs that define this space.\n\n**Key Finding:** Despite superficial differences, all code-first workflow engines converge on similar foundational patterns—queue-based task distribution, state machine cores, and separation of orchestration from execution—while diverging significantly in their approach to developer experience, durability guarantees, and domain specialization.\n\n---\n\n## Table of Contents\n\n1. [Introduction](#1-introduction)\n2. [Core Architectural Patterns](#2-core-architectural-patterns)\n3. [Shared Foundations](#3-shared-foundations)\n4. [Key Design Trade-offs](#4-key-design-trade-offs)\n5. [Evolution and Trends](#5-evolution-and-trends)\n6. [Recommendations](#6-recommendations)\n7. [References](#7-references)\n\n---\n\n## 1. Introduction\n\n### 1.1 What are Code-First Workflow Engines?\n\nCode-first workflow engines allow developers to define complex, multi-step processes using general-purpose programming languages rather than visual designers or XML configurations. These engines handle orchestration, state management, failure recovery, and coordination of distributed tasks.\n\n### 1.2 Research Scope\n\nThis analysis covers:\n- **Durable Execution Engines**: Temporal, Cadence, Restate\n- **Data Orchestrators**: Airflow, Prefect, Dagster\n- **General-Purpose Engines**: Windmill, n8n, Tork\n- **Platform-Specific**: Azure Durable Functions, AWS Step Functions\n\n### 1.3 Why This Matters\n\nWorkflow engines are critical infrastructure for:\n- Distributed transaction coordination (e.g., payment processing, order fulfillment)\n- Data pipeline orchestration (ETL, ML training)\n- Long-running processes (multi-day workflows, human-in-the-loop)\n- Microservice coordination and saga pattern implementation\n\n---\n\n## 2. Core Architectural Patterns\n\n### 2.1 State Persistence & Durability Models\n\n#### Event Sourcing + State Machines\n\nWorkflow engines fundamentally operate as state machines that store workflow states and track execution history. The underlying implementation varies significantly:\n\n**Durable Execution Approach (Temporal/Cadence)**\n\nDurable execution engines like Temporal automatically preserve the full state of workflows across failures by persisting every step. This enables workflows to be recovered, replayed, or paused at any arbitrary point. The key innovation is that developers can write code that appears synchronous (including sleeping for 30 days) while the engine handles all persistence and recovery automatically.\n\n**Event-Driven Approach (Infinitic, custom engines)**\n\nEvent-driven engines maintain workflow history and trigger tasks based on events, with the workflow engine maintaining state while workers remain stateless. This pattern separates concerns: the engine handles coordination while workers handle execution.\n\n#### Stateless vs. Stateful Engines\n\n**Stateless Engines** (WorkflowEngine .NET, many custom implementations):\n- Store process states in external persistent storage (SQL, NoSQL)\n- Automatically save and load processes from storage\n- Enable horizontal scaling without state synchronization concerns\n- Simpler worker implementation but require reliable storage\n\n**Stateful Engines** (Temporal with history service):\n- Maintain complete execution history in-memory with durable backing\n- Can replay workflows from history to reconstruct state\n- More complex coordination but richer debugging capabilities\n\n---\n\n### 2.2 Task Distribution Architecture\n\n#### The Universal Queue-Based Worker Pattern\n\nEvery practical workflow engine uses queues to dispatch tasks to workers, avoiding direct task calls to handle flow control, availability, and slowness issues. This is perhaps the most universal pattern across all workflow engines.\n\n**Core Components:**\n\n1. **Coordinator/Orchestrator**\n - Manages workflow lifecycle\n - Tracks job state and failures\n - Routes tasks to appropriate workers\n - Handles retries and timeout logic\n\n2. **Workers**\n - Stateless processes that poll task queues\n - Execute tasks and return results\n - Can be scaled independently of coordinator\n - No state synchronization required between workers\n\n3. **Task Queues**\n - Message brokers (RabbitMQ, Kafka, cloud-native queues)\n - Decouple coordination from execution\n - Provide natural backpressure when workers are busy\n - Enable automatic retry when workers crash\n\n4. **Matching Service** (in sophisticated systems like Temporal)\n - Routes workflow and activity tasks to available workers\n - Acts as task queue manager for the system\n - Handles load balancing and partition management\n\n#### Task Queue Partitioning\n\nTask queues are partitioned for horizontal scaling, allowing multiple nodes to independently handle task delivery and avoid bottlenecks. A single task queue might receive tasks from thousands of workflows and be polled by hundreds of workers. Partitioning prevents hotspots and allows linear scaling.\n\n**Temporal's Approach:**\n- 10,000+ shards where each shard stores both workflow state and a queue\n- Enables transactional updates across state and queue\n- Partitions distribute load across multiple matching service nodes\n\n#### Worker Architecture Details\n\nWorkers typically implement:\n- **Pollers**: Internal threads that long-poll the cluster for new tasks\n- **Thread Pools**: Execute activity tasks with configurable concurrency\n- **Slot-Based Concurrency**: Limit simultaneous task execution\n- **Heartbeating**: Keep coordinator informed of task progress\n\n---\n\n### 2.3 Transactional Consistency\n\n#### The Critical Challenge\n\nWorkflow engines must transactionally update state, task queues, and timers together to avoid race conditions where state and queues become inconsistent. Consider these failure scenarios:\n\n1. **State updates succeed, queue write fails**: System believes task is outstanding but task was never queued\n2. **Queue write succeeds, state update is slow**: Task gets delivered and processed before state reflects it was queued\n3. **Timer fires, but state is inconsistent**: Workflow may execute duplicate operations\n\nWithout transactional guarantees, these edge cases proliferate.\n\n#### Solutions\n\n**Transactional Outbox Pattern (Temporal)**\n\nTemporal uses a partitioned architecture where each shard storing workflow state also stores a queue, enabling transactional commits followed by transfer to the queueing subsystem. The outbox pattern ensures that:\n- State changes and queue writes happen atomically within a shard\n- Transfer to external queues can retry safely\n- Deduplication handles any resulting duplicates\n\n**Single Database Approach (simpler systems)**\n\nMany workflow engines use a single database or even a single process to simplify transactional requirements. This works but doesn't scale:\n- Limited throughput (single writer)\n- Limited partition tolerance\n- Database becomes bottleneck\n- Suitable for small to medium deployments\n\n**Saga Pattern for Cross-Service Transactions**\n\nFor workflows spanning multiple services, engines implement saga patterns to maintain eventual consistency without distributed transactions.\n\n---\n\n### 2.4 Workflow Definition Paradigms\n\n#### Code-First vs. Config-First\n\nThe fundamental choice in workflow definition approach shapes the entire developer experience:\n\n**Code-First Approach**\n\nWorkflows defined in general-purpose programming languages (Python, Go, Java, TypeScript) that are executed by the engine.\n\n*Advantages:*\n- Full programming language power (loops, conditionals, functions)\n- Type safety and IDE support\n- Easier unit testing and debugging\n- Version control friendly\n- Can leverage existing libraries and frameworks\n\n*Disadvantages:*\n- Airflow workflows require redeployment when they change since they're written in Python\n- Requires programming knowledge\n- Can't be easily edited by non-technical users\n- Potential for overcomplication\n\n**Examples**: Temporal, Prefect, Dagster, Airflow\n\n**Config-First Approach**\n\nWorkflows written in YAML/JSON don't require engine redeployment when changed.\n\n*Advantages:*\n- Keeping rules as data instead of code means no recompilation and allows runtime changes\n- Non-technical users can understand and edit workflows\n- Clear separation between workflow logic and implementation\n- Easier to generate workflows programmatically\n\n*Disadvantages:*\n- Limited expressiveness (no or limited control flow)\n- Version control and diff tracking more challenging\n- YAML complexity can become unwieldy\n- Limited type safety\n\n**Examples**: AWS Step Functions (JSON), many traditional BPM engines, Kubernetes workflows\n\n#### The Hybrid Revolution\n\nModern systems increasingly adopt hybrid approaches:\n\n**Dagster Components**\n\nDagster Components allow mixing declarative YAML DSLs with imperative Python code for common patterns. Teams can:\n- Use YAML for standardized, repeated patterns (e.g., data extraction)\n- Fall back to Python for complex custom logic\n- Create organization-specific DSLs\n- Abstract away implementation details while maintaining flexibility\n\n**Windmill's Approach**\n\nWindmill lets engineers write scripts in multiple languages (Python, TypeScript, Go) and compose them into workflows via visual DAG editor. This provides:\n- Script development in familiar languages\n- Visual composition of workflows\n- Auto-generated UIs and APIs\n- Best of both worlds: code flexibility with visual orchestration\n\n---\n\n### 2.5 Orchestration vs. Choreography\n\nDistributed workflows can be coordinated through two fundamental patterns:\n\n#### Orchestration Pattern\n\nA central orchestrator tells participants what local transactions to execute. Temporal follows the orchestrator variant of the Saga pattern where a centralized coordinator tracks workflow progress and dispatches commands.\n\n**Characteristics:**\n- Single service/component coordinates entire workflow\n- Explicit workflow definition visible in one place\n- Clear causality and execution order\n- Easier debugging and monitoring\n\n**Advantages:**\n- Centralized visibility and control\n- Single source of truth for workflow state\n- Easier to understand end-to-end flow\n- Better for complex workflows with many decision points\n\n**Disadvantages:**\n- Single point of failure (requires HA setup)\n- Orchestrator can become bottleneck\n- Tight coupling to orchestrator\n- Orchestrator must know about all participants\n\n**Best For:**\n- Complex workflows with many steps\n- Workflows requiring centralized decision logic\n- When observability is critical\n- Financial transactions, order processing\n\n#### Choreography Pattern\n\nEach local transaction publishes domain events that trigger local transactions in other services. Services react to each other's operations without a central conductor, avoiding single point of failure.\n\n**Characteristics:**\n- Decentralized coordination\n- Services respond to events autonomously\n- No central coordinator required\n- Implicit workflow through event chains\n\n**Advantages:**\n- No single point of failure\n- Loose coupling between services\n- Natural event-driven architecture fit\n- Services can evolve independently\n\n**Disadvantages:**\n- Harder to track overall workflow state\n- Implicit dependencies difficult to visualize\n- Debugging spans multiple services\n- Risk of cyclic dependencies\n\n**Best For:**\n- Event-driven architectures\n- Loosely coupled microservices\n- When services should be autonomous\n- Simpler workflows with clear event flows\n\n#### Hybrid Patterns\n\nMany real-world systems combine both:\n- Orchestration for critical paths requiring visibility\n- Choreography for loosely coupled background processes\n- Orchestration within bounded contexts, choreography across them\n\n---\n\n### 2.6 Data Orchestration-Specific Patterns\n\nData orchestration engines have evolved domain-specific patterns:\n\n#### Asset-Centric vs. Task-Centric\n\n**Asset-Centric Model (Dagster)**\n\nDagster treats data assets (tables, models, reports) as first-class citizens with dependencies, lineage, and state management central to orchestration. The focus shifts from \"what tasks to run\" to \"what data should exist.\"\n\n*Key Concepts:*\n- **Software-Defined Assets**: Tables, ML models defined as code\n- **Asset Materialization**: Creating or updating an asset\n- **Asset Lineage**: Automatic dependency tracking\n- **Asset Metadata**: Quality metrics, ownership, documentation\n- **Freshness Policies**: Declarative data SLAs\n\n*Benefits:*\n- Natural fit for data platform thinking\n- Built-in data cataloging\n- Asset-level observability\n- Incremental materialization\n- Clear ownership boundaries\n\n**Task-Centric Model (Airflow, Prefect)**\n\nTraditional DAG-based approach where tasks and their dependencies are primary abstractions. Prefect's task-based model is imperative - developers define exact sequence of steps rather than describing desired end states.\n\n*Key Concepts:*\n- **Tasks**: Individual units of work\n- **DAGs**: Directed acyclic graphs of task dependencies\n- **Operators**: Reusable task templates\n- **XComs**: Cross-task communication\n- **Task Groups**: Logical grouping of related tasks\n\n*Benefits:*\n- Intuitive for ETL thinking\n- Rich operator ecosystem\n- Fine-grained control over execution\n- Familiar to most data engineers\n\n#### Scheduler Architecture Differences\n\n**Airflow:**\n- Centralized scheduler with metadata database\n- Distributed workers (Celery, Kubernetes, LocalExecutor)\n- DAGs parsed continuously from Python files\n- Shared metadata store across components\n\n**Prefect:**\n- Separates orchestration (Cloud/Server) from execution\n- Agents poll for work and execute in any environment\n- Scheduler doesn't need network ingress to workers\n- Hybrid and edge-friendly architecture\n\n**Dagster:**\n- Separates daemon (schedulers/sensors) from user code\n- User code packaged as gRPC servers\n- Loaded dynamically into web UI (Dagit)\n- Isolation of dependency trees reduces scheduler load\n\n---\n\n### 2.7 Failure Handling & Compensation\n\n#### The Saga Pattern for Distributed Transactions\n\nSagas enable orchestrating multi-step workflows across services, with each step providing compensating actions for rollback when failures occur. This is critical in microservices where traditional ACID transactions don't span services.\n\n**Saga Characteristics:**\n\nSagas are coordinating objects implemented as state machines that listen for events and instruct other parts of the system. The key distinction between saga variants:\n\n- **Pure Sagas**: No internal state; decisions based entirely on incoming messages\n- **Process Managers**: Maintain state; act as state machines making decisions based on state and events\n\n**Implementation Pattern:**\n\n1. **Forward Operations**: Each step in workflow performs business operation\n2. **Compensating Actions**: Each step defines how to undo its operation\n3. **Coordination**: Orchestrator or choreography coordinates execution\n4. **Rollback**: On failure, execute compensating actions in reverse\n\n**Example: Order Processing**\n\n```\nNormal Flow:\n1. Reserve Inventory → Compensate: Release Inventory\n2. Charge Payment → Compensate: Refund Payment \n3. Ship Order → Compensate: Cancel Shipment\n\nFailure Scenario:\n1. Reserve Inventory ✓\n2. Charge Payment ✓\n3. Ship Order ✗ (fails)\n→ Execute: Refund Payment, Release Inventory\n```\n\n#### Built-In Retry & Durability\n\nModern workflow engines provide sophisticated retry mechanisms:\n\n**Temporal Activities:**\n- Built-in support for timeouts and retries\n- Configurable retry policies (exponential backoff, max attempts)\n- Automatic recovery with resume from last checkpoint\n- Activities can run for days with automatic heartbeating\n\n**Benefits of Durable Execution:**\n- Simpler codebase with fewer bugs\n- Comprehensive test coverage through replay capabilities\n- Can simulate failures and test compensation logic\n- Time travel debugging\n\n---\n\n### 2.8 Scaling Dimensions\n\n#### Horizontal Scalability Strategies\n\nModern workflow engines must scale along multiple dimensions:\n\n**1. Sharding for Parallelism**\n\nSharding enables executing millions of tasks by distributing workflow state across many partitions. Temporal uses 10,000+ shards where each shard stores both workflow state and a queue for transactional updates.\n\n**2. Worker Pool Scaling**\n\nWorkers scale independently:\n- Add workers to increase task throughput\n- Remove workers to reduce costs\n- No state coordination needed\n- Auto-scaling based on queue depth\n\n**3. Task Queue Separation**\n\nMultiple task queues for different workloads allow isolation of CPU-intensive vs. I/O-bound tasks with independent autoscaling. For example:\n- GPU-intensive ML training on dedicated workers\n- I/O-bound API calls on different workers\n- Prevents resource contention\n- Independent scaling policies per workload type\n\n**4. Database Scaling**\n\nDifferent approaches to scaling the persistence layer:\n- **Sharding**: Partition state across multiple databases\n- **Replication**: Read replicas for query workloads\n- **Caching**: In-memory caches for hot workflows\n- **Time-series optimization**: Archival of old execution data\n\n#### Worker Architecture for Scale\n\nWorkers implement sophisticated patterns:\n\n**Pollers**\n- Internal threads that long-poll the cluster for new tasks\n- Configurable poller count controls task pickup speed\n- Long-polling reduces network overhead vs. short polling\n- Pollers don't execute tasks, just retrieve them\n\n**Execution Threads**\n- Separate thread pool for actual task execution\n- Configurable concurrency limits per worker\n- Slot-based concurrency prevents overload\n- Graceful degradation under pressure\n\n**Heartbeating**\n- Workers periodically report task progress\n- Coordinator can detect worker failures\n- Enables task timeout and reassignment\n- Critical for long-running tasks\n\n---\n\n## 3. Shared Foundations\n\nDespite significant architectural differences, code-first workflow engines converge on several fundamental patterns:\n\n### 3.1 Queue-Based Task Distribution\n\n**Universal adoption** of message queues for task dispatch:\n- Decouples coordination from execution\n- Provides natural backpressure\n- Enables retry and failure recovery\n- Facilitates horizontal scaling\n\nNo successful workflow engine attempts direct synchronous task invocation at scale.\n\n### 3.2 State Machine Core\n\nAll workflow engines model execution as state transitions:\n- Workflows define valid states and transitions\n- Events trigger state changes\n- State changes may trigger actions (task dispatch)\n- Current state determines valid next actions\n\nEven engines with imperative code interfaces (Temporal) internally maintain state machines.\n\n### 3.3 Retry and Timeout Mechanisms\n\nBuilt-in fault tolerance is non-negotiable:\n- Configurable retry policies\n- Exponential backoff\n- Max retry limits\n- Timeout detection\n- Automatic task reassignment on failure\n\nThese shouldn't be the application's responsibility.\n\n### 3.4 Event-Driven Triggers\n\nMoving beyond pure scheduling to reactive execution:\n- Scheduled triggers (cron-like)\n- Event triggers (message arrives, file uploaded)\n- API triggers (webhook, HTTP request)\n- Manual triggers (human intervention)\n- Sensor triggers (external system state change)\n\nModern workflows react to the world, not just the clock.\n\n### 3.5 Observability Focus\n\nRich UIs for monitoring, debugging, and understanding execution state:\n- Real-time workflow status\n- Execution history and audit trails\n- Performance metrics and bottleneck detection\n- Error tracking and alerting\n- Dependency visualization\n\nDurable execution ensures every step of code execution can be tracked and viewed, enabling quick diagnosis of issues.\n\n### 3.6 Separation of Concerns\n\nCoordination logic separate from business logic:\n- Orchestration engine handles: scheduling, retries, state, queuing\n- Application code handles: business logic, data transformation\n- Clean interfaces between layers\n- Business logic doesn't deal with infrastructure concerns\n\nThis separation is critical for testability and maintainability.\n\n---\n\n## 4. Key Design Trade-offs\n\n### 4.1 Developer Experience vs. Operational Complexity\n\n**The Trade-off:**\n\nAirflow has significant operational overhead (scheduler, workers, metadata DB, message queue) but provides a vast ecosystem of operators and integrations. Prefect emphasizes simplicity with a \"negative engineering\" philosophy—assuming developers know how to code and removing unnecessary abstractions. Dagster takes a first-principles approach with the full development lifecycle in mind, from development to deployment to monitoring.\n\n**Implications:**\n\n- **Airflow**: Best for teams with DevOps resources, need for battle-tested stability\n- **Prefect**: Best for agile teams wanting rapid iteration\n- **Dagster**: Best for data platform teams wanting end-to-end lifecycle management\n\nEarly workflow systems like AWS Simple Workflow Service (SWF) struggled with adoption despite being conceptually advanced due to challenging developer experience. The lesson: power without usability leads to low adoption.\n\n### 4.2 Flexibility vs. Guardrails\n\n**The Spectrum:**\n\n- **Full Code Flexibility** (Temporal): Any code in workflow, full language power\n - Pro: Can express anything\n - Con: Can shoot yourself in foot, hard to enforce standards\n\n- **Constrained Frameworks** (Airflow with TaskFlow API): Structured patterns with some flexibility\n - Pro: Best practices built-in\n - Con: Sometimes need to work around framework\n\n- **Declarative DSLs** (YAML workflows): Limited to defined constructs\n - Pro: Prevents entire classes of errors\n - Con: May not express all needs\n\nModern platforms aim to provide flexibility with visibility and guardrails enterprises need to move fast without breaking things.\n\n### 4.3 Monolithic vs. Distributed\n\n**Historical Context:**\n\nTraditional workflow engines were often designed to run as single process and not distributed, limiting scalability. This was acceptable when workflows were departmental tools, not production infrastructure.\n\n**Modern Requirements:**\n\n- Multi-region deployment\n- Fault tolerance across availability zones\n- Elastic scaling\n- Multi-tenancy\n\nModern engines embrace distributed architecture from the start, but this adds complexity.\n\n### 4.4 Real-Time vs. Batch\n\n**Historical Focus:**\n\nAirflow historically focused on scheduled batch jobs (nightly ETL, daily reports). This made sense when data was batch-oriented.\n\n**Modern Reality:**\n\nPrefect and Dagster offer superior event-native design for real-time pipelines. Airflow 3.0 (April 2025) improved event-driven capabilities but still carries batch-oriented legacy.\n\n**Trade-off:**\n\n- Batch-oriented systems optimize for throughput and resource efficiency\n- Real-time systems optimize for latency and responsiveness\n- Hard to excel at both simultaneously\n\n### 4.5 Generalization vs. Specialization\n\n**General-Purpose Engines** (Temporal, Prefect):\n- Can orchestrate anything\n- No domain assumptions\n- Broadly applicable\n\n**Domain-Specific Engines** (Dagster for data):\n- Optimized for specific use cases\n- Domain-specific features (asset lineage, data quality)\n- Steeper learning curve for other domains\n\nThe trend is toward general engines with domain-specific extensions.\n\n---\n\n## 5. Evolution and Trends\n\n### 5.1 Historical Evolution\n\n**Phase 1: Traditional BPM (2000s)**\n- BPMN/BPEL based\n- XML configuration\n- Heavy enterprise focus\n- Visual designers\n- Examples: jBPM, Activiti, Camunda\n\n**Phase 2: Code-First Data (2010s)**\n- Python-based DAGs\n- Data engineering focus\n- Scheduled batch jobs\n- Example: Airflow (2014)\n\n**Phase 3: Modern Durable Execution (2015-2020)**\n- Workflow-as-code\n- Built-in resilience\n- Language-native SDKs\n- Examples: Cadence (2016), Temporal (2019)\n\n**Phase 4: Asset-Centric & Declarative (2020+)**\n- Data as first-class citizen\n- Hybrid code/config approaches\n- Developer experience focus\n- Examples: Dagster Components (2025), modern Prefect\n\n### 5.2 Current Trends\n\n**1. Convergence on Event-Driven**\n\nAll engines moving toward event-native architectures:\n- Airflow 3.0 added event-driven scheduling\n- Prefect built event-driven from start\n- Temporal supports signals and queries for external events\n\n**2. AI/ML Workload Support**\n\nSpecialized features for AI/ML:\n- Long-running training jobs\n- GPU resource management\n- Model versioning and lineage\n- Experiment tracking integration\n\n**3. Hybrid Cloud & Edge**\n\nWorkflows must run anywhere:\n- Multi-cloud support\n- Edge deployment (Prefect's agent model)\n- Air-gapped environments\n- Kubernetes-native\n\n**4. Developer Experience Revolution**\n\nFocus on DX improvements:\n- Local development modes\n- Fast feedback loops\n- Testing frameworks\n- Time-travel debugging\n- Branch deployments (Dagster)\n\n**5. Platform Consolidation**\n\nEngines absorbing adjacent concerns:\n- Data cataloging (Dagster)\n- Data quality checks\n- Cost management\n- Observability\n- Reducing tool sprawl\n\n### 5.3 Future Directions\n\n**Predicted Evolutions:**\n\n1. **AI-Assisted Workflow Development**\n - LLM-generated workflows from natural language\n - Automatic optimization suggestions\n - Intelligent error recovery\n\n2. **Multi-Model Orchestration**\n - Seamless mix of code, config, visual\n - DSLs for common patterns\n - Full code for edge cases\n\n3. **Deeper Cloud Integration**\n - Native serverless execution\n - Zero-operations deployment\n - Automatic scaling without config\n\n4. **Cross-Organization Workflows**\n - Workflow federation\n - Inter-company orchestration\n - Privacy-preserving coordination\n\n---\n\n## 6. Recommendations\n\n### 6.1 Choosing a Workflow Engine\n\n**For Data/Analytics Teams:**\n\n- **Start with Dagster** if:\n - Building a modern data platform\n - Need strong data lineage and cataloging\n - Have strong Python skills\n - Want asset-centric thinking\n\n- **Choose Airflow** if:\n - Already invested in Airflow ecosystem\n - Need 2000+ community operators\n - Have DevOps resources for operation\n - Batch-oriented workflows\n\n- **Consider Prefect** if:\n - Want rapid development\n - Need hybrid/edge deployment\n - Prefer minimal operational overhead\n - Dynamic, event-driven workflows\n\n**For Distributed Systems/Microservices:**\n\n- **Choose Temporal** if:\n - Need rock-solid reliability guarantees\n - Implementing saga patterns\n - Long-running processes (days/weeks)\n - Multi-step transactions across services\n - Critical business processes (payments, orders)\n\n**For General Automation:**\n\n- **Choose Windmill** if:\n - Need multi-language support\n - Want low-code components with code flexibility\n - Building internal tools\n - Small to medium team\n\n- **Choose n8n** if:\n - Need extensive API integrations\n - Low-code with code fallback\n - Business process automation\n - Non-technical users involved\n\n### 6.2 Architectural Guidelines\n\n**When Building Custom Workflows:**\n\n1. **Always use queues for task distribution**\n - Don't do synchronous RPC between coordinator and workers\n - Queues provide natural backpressure and retry\n\n2. **Ensure transactional consistency**\n - Use outbox pattern or single-database approach\n - Never update state and queues without transactions\n - Edge cases will bite you\n\n3. **Make workers stateless**\n - All state in coordinator/database\n - Enables trivial horizontal scaling\n - Simplifies failure recovery\n\n4. **Implement comprehensive observability**\n - Log all state transitions\n - Provide execution history\n - Enable time-travel debugging\n - Visualize dependencies\n\n5. **Support local development**\n - Workflows should run on developer laptop\n - Fast feedback loops\n - Testability is critical\n\n6. **Design for failure**\n - Assume anything can fail anytime\n - Implement compensating actions\n - Make operations idempotent\n - Test failure scenarios\n\n### 6.3 Migration Strategies\n\n**From Homegrown to Managed Engine:**\n\n1. **Start with new workflows** - Don't migrate everything\n2. **Run in parallel** - Prove stability before switching\n3. **Choose based on team skills** - Don't fight your team's strengths\n4. **Consider operational burden** - Factor in ongoing costs\n5. **Evaluate vendor lock-in** - Prefer open-source or standard APIs\n\n**Incremental Migration Path:**\n\nMany engines (especially Dagster) support observing existing systems:\n- Wrap existing Airflow DAGs\n- Gradually migrate workflows\n- Maintain visibility across both systems\n- Reduce risk of big-bang migration\n\n---\n\n## 7. References\n\n### Primary Sources\n\n**Temporal/Durable Execution:**\n- Temporal Engineering Blog: \"Designing a Workflow Engine from First Principles\"\n- Temporal Documentation: \"How Temporal Works\"\n- \"Durable Execution in Distributed Systems\" by Temporal\n\n**Data Orchestration:**\n- \"Orchestration Showdown: Dagster vs Prefect vs Airflow\" (ZenML, November 2025)\n- \"Dagster vs Airflow: Comparing Top Data Orchestration Tools\" (DataCamp, 2024)\n- \"Airflow vs Prefect vs Dagster\" (Galaxy, 2025)\n\n**Patterns & Architecture:**\n- \"Saga and Process Manager\" (Event-Driven.io)\n- Microservices.io: \"Pattern: Saga\"\n- \"Events, Sagas and Workflows: Managing Long-Running Processes\"\n\n**Community Resources:**\n- awesome-workflow-engines (GitHub)\n- SE Radio: \"Maxim Fateev on Durable Execution with Temporal\"\n- Various Stack Overflow discussions on workflow patterns\n\n### Key Papers & Talks\n\n- Hector Garcia-Molina & Kenneth Salem (1987): Original Saga pattern paper\n- Systems @ Scale 2021: Workflow engine design principles\n- Various conference talks on Temporal, Airflow, Dagster evolution\n\n---\n\n## Appendix A: Comparison Matrix\n\n| Feature | Temporal | Airflow | Prefect | Dagster |\n|---------|----------|---------|---------|---------|\n| **Primary Use Case** | Distributed transactions | Data pipelines | General workflows | Data platforms |\n| **Definition Style** | Code-first (Python, Go, Java, TS) | Code-first (Python DAGs) | Code-first (Python) | Asset-centric (Python) |\n| **State Model** | Durable execution, full replay | Metadata DB, task state | Event-driven, state streams | Asset materialization state |\n| **Scheduling** | Event + cron | Primarily cron | Event-native | Asset-aware, event-driven |\n| **Deployment** | Self-hosted or cloud | Self-hosted (complex) | Cloud or self-hosted | Self-hosted or cloud |\n| **Scalability** | 10,000+ shards | Horizontal via executors | Agent-based elastic | gRPC user code isolation |\n| **Best For** | Mission-critical transactions | Established ETL pipelines | Rapid development | Modern data platforms |\n| **Learning Curve** | Moderate | Steep | Gentle | Moderate |\n| **Operational Overhead** | Moderate | High | Low | Moderate |\n| **Community Size** | Growing | Very large | Growing | Growing rapidly |\n\n---\n\n## Appendix B: Glossary\n\n**Activity**: A single unit of work in a workflow, typically a function or service call.\n\n**Asset**: In data orchestration, a data object like a table or model that has dependencies and lineage.\n\n**Choreography**: Coordination pattern where services react to events without central orchestrator.\n\n**Compensating Action**: Undo operation for a completed workflow step, used in saga rollback.\n\n**DAG (Directed Acyclic Graph)**: Structure representing workflow steps and their dependencies.\n\n**Durable Execution**: Programming model where code execution state persists automatically across failures.\n\n**Orchestration**: Coordination pattern where central service directs other services.\n\n**Saga**: Long-running transaction pattern with compensating actions for rollback.\n\n**Shard**: Partition of workflow state for horizontal scaling.\n\n**Task Queue**: Message queue holding work items for workers to process.\n\n**Worker**: Stateless process that executes workflow tasks.\n\n**Workflow**: Multi-step process with defined coordination and error handling.\n\n---\n\n## Appendix C: Code Examples\n\n### Example 1: Temporal Workflow (Python)\n\n```python\nfrom datetime import timedelta\nfrom temporalio import workflow, activity\n\n@activity.defn\nasync def send_email(recipient: str) -> None:\n # Send email logic\n print(f\"Email sent to {recipient}\")\n\n@workflow.defn\nclass SubscriptionWorkflow:\n @workflow.run\n async def run(self, user_id: str) -> str:\n # Day 1: Welcome email\n await workflow.execute_activity(\n send_email,\n user_id,\n start_to_close_timeout=timedelta(minutes=5)\n )\n \n # Wait 7 days\n await workflow.sleep(timedelta(days=7))\n \n # Day 8: Follow-up email\n await workflow.execute_activity(\n send_email,\n user_id,\n start_to_close_timeout=timedelta(minutes=5)\n )\n \n return f\"Campaign complete for {user_id}\"\n```\n\n### Example 2: Airflow DAG (Python)\n\n```python\nfrom airflow import DAG\nfrom airflow.operators.python import PythonOperator\nfrom datetime import datetime, timedelta\n\ndef extract_data():\n # Extract logic\n return \"data\"\n\ndef transform_data(ti):\n data = ti.xcom_pull(task_ids='extract')\n # Transform logic\n return f\"transformed_{data}\"\n\ndef load_data(ti):\n data = ti.xcom_pull(task_ids='transform')\n # Load logic\n print(f\"Loading {data}\")\n\nwith DAG(\n 'etl_pipeline',\n schedule_interval=timedelta(days=1),\n start_date=datetime(2025, 1, 1),\n catchup=False\n) as dag:\n \n extract = PythonOperator(\n task_id='extract',\n python_callable=extract_data\n )\n \n transform = PythonOperator(\n task_id='transform',\n python_callable=transform_data\n )\n \n load = PythonOperator(\n task_id='load',\n python_callable=load_data\n )\n \n extract >> transform >> load\n```\n\n### Example 3: Dagster Assets (Python)\n\n```python\nfrom dagster import asset, AssetExecutionContext\n\n@asset\ndef raw_customers(context: AssetExecutionContext):\n \"\"\"Extract raw customer data\"\"\"\n # Fetch from API\n return fetch_customers()\n\n@asset(deps=[raw_customers])\ndef cleaned_customers(context: AssetExecutionContext):\n \"\"\"Clean and validate customer data\"\"\"\n # Load raw data\n raw = load_asset(\"raw_customers\")\n # Clean data\n return clean_data(raw)\n\n@asset(deps=[cleaned_customers])\ndef customer_metrics(context: AssetExecutionContext):\n \"\"\"Calculate customer metrics\"\"\"\n cleaned = load_asset(\"cleaned_customers\")\n return calculate_metrics(cleaned)\n```\n\n### Example 4: Prefect Flow (Python)\n\n```python\nfrom prefect import flow, task\nfrom datetime import timedelta\n\n@task(retries=3, retry_delay_seconds=60)\ndef fetch_data(url: str):\n # Fetch logic with automatic retries\n return fetch_from_api(url)\n\n@task\ndef process_data(data):\n # Processing logic\n return processed_data\n\n@flow(log_prints=True)\ndef etl_flow(source_url: str):\n raw_data = fetch_data(source_url)\n processed = process_data(raw_data)\n return processed\n\n# Run flow\nif __name__ == \"__main__\":\n etl_flow(\"https://api.example.com/data\")\n```\n\n---\n\n## Document Information\n\n**Report Version**: 1.0 \n**Publication Date**: November 2025 \n**Author**: Research Analysis \n**Status**: Final\n\n**Change Log**:\n- v1.0 (Nov 2025): Initial comprehensive report\n\n**Contact**: For questions or feedback about this report, please refer to the research methodology and sources cited.\n\n---\n\n*End of Report*\n",[],[551],"files",[158,176,185,193,201,209,217,225,233,241,249,257,266,272,281,290,298,306,314,323,329,335,341,350,358,366,375,383,391,399,407,415,423,431,439,447,455,463,472,479,487,495,502,510,518,525,533,541,549],"counts",{"_561":32,"_562":124,"_563":166,"_564":565},"pulls","branches","forks","envVars",{"_566":32,"_567":32},"count","emptyCount","contents",[],{"_106":291,"_96":292,"_161":293,"_163":269,"_164":144,"_165":166,"_167":120,"_108":571,"_102":32,"_169":277,"_171":295,"_172":22,"_173":-5,"_100":572},["D",1763567518186],[268,292],"upstreamProject","upstreamBranch",{"_106":147,"_108":576,"_577":578,"_96":44,"_145":107,"_102":579,"_146":-5,"_148":-5,"_580":581,"_110":-5,"_155":22,"_112":113,"_154":95,"_16":125,"_153":97},["D",1763236734129],"updatedAt",["D",1765047056289],80,"lockfileKey","1765047290945-esm.town_v_nbbaier_wrkflw@80-main","emptyEnvVars","isNew","flags",[],"routes/_app.x.$handle.$name.branch.$branch.version.$version.code.$",{"_94":95,"_96":97,"_98":99,"_102":103,"_100":101,"_104":588,"_156":593,"_557":741,"_346":742,"_568":744,"_745":746,"_749":-5,"_750":32,"_751":103,"_752":753,"_564":-5},{"_106":107,"_96":97,"_108":589,"_110":-5,"_111":22,"_112":113,"_114":73,"_115":-5,"_14":116,"_117":118,"_119":120,"_121":120,"_122":-5,"_123":124,"_16":125,"_126":127,"_128":127,"_129":130,"_131":130,"_132":130,"_133":127,"_134":127,"_23":590,"_138":591,"_141":592,"_155":22},["D",1763236734129],{"_94":95,"_136":137},{"_94":95,"_140":137,"_14":116},{"_102":143,"_96":99,"_106":144,"_145":107,"_146":147,"_148":149,"_150":113,"_151":107,"_152":125,"_153":97,"_154":95},[594,630,651,708,711,714,717,720,723,726,729,732,735,738],{"_106":159,"_96":160,"_161":162,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":168,"_102":32,"_169":170,"_171":-5,"_172":22,"_173":-5,"_174":595,"_100":629},[596,599,602,605,608,611,614,617,620,623,626],{"_106":177,"_96":178,"_161":179,"_163":162,"_164":144,"_165":166,"_167":120,"_108":180,"_102":32,"_169":181,"_171":182,"_172":22,"_173":-5,"_174":597,"_100":598},[],[160,178],{"_106":186,"_96":187,"_161":188,"_163":162,"_164":144,"_165":166,"_167":120,"_108":189,"_102":32,"_169":181,"_171":190,"_172":22,"_173":-5,"_174":600,"_100":601},[],[160,187],{"_106":194,"_96":195,"_161":196,"_163":162,"_164":144,"_165":166,"_167":120,"_108":197,"_102":32,"_169":181,"_171":198,"_172":22,"_173":-5,"_174":603,"_100":604},[],[160,195],{"_106":202,"_96":203,"_161":204,"_163":162,"_164":144,"_165":166,"_167":120,"_108":205,"_102":32,"_169":181,"_171":206,"_172":22,"_173":-5,"_174":606,"_100":607},[],[160,203],{"_106":210,"_96":211,"_161":212,"_163":162,"_164":144,"_165":166,"_167":120,"_108":213,"_102":32,"_169":181,"_171":214,"_172":22,"_173":-5,"_174":609,"_100":610},[],[160,211],{"_106":218,"_96":219,"_161":220,"_163":162,"_164":144,"_165":166,"_167":120,"_108":221,"_102":32,"_169":181,"_171":222,"_172":22,"_173":-5,"_174":612,"_100":613},[],[160,219],{"_106":226,"_96":227,"_161":228,"_163":162,"_164":144,"_165":166,"_167":120,"_108":229,"_102":32,"_169":181,"_171":230,"_172":22,"_173":-5,"_174":615,"_100":616},[],[160,227],{"_106":234,"_96":235,"_161":236,"_163":162,"_164":144,"_165":166,"_167":120,"_108":237,"_102":32,"_169":181,"_171":238,"_172":22,"_173":-5,"_174":618,"_100":619},[],[160,235],{"_106":242,"_96":243,"_161":244,"_163":162,"_164":144,"_165":166,"_167":120,"_108":245,"_102":32,"_169":181,"_171":246,"_172":22,"_173":-5,"_174":621,"_100":622},[],[160,243],{"_106":250,"_96":251,"_161":252,"_163":162,"_164":144,"_165":166,"_167":120,"_108":253,"_102":32,"_169":181,"_171":254,"_172":22,"_173":-5,"_174":624,"_100":625},[],[160,251],{"_106":258,"_96":259,"_161":260,"_163":162,"_164":144,"_165":166,"_167":120,"_108":261,"_102":32,"_169":181,"_171":262,"_172":22,"_173":-5,"_174":627,"_100":628},[],[160,259],[160],{"_106":267,"_96":268,"_161":269,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":270,"_102":32,"_169":170,"_171":-5,"_172":22,"_173":-5,"_174":631,"_100":650},[632,635,638,641,644,647],{"_106":273,"_96":274,"_161":275,"_163":269,"_164":144,"_165":103,"_167":22,"_108":276,"_102":166,"_169":277,"_171":278,"_172":22,"_173":-5,"_174":633,"_100":634},[],[268,274],{"_106":282,"_96":283,"_161":284,"_163":269,"_164":144,"_165":166,"_167":120,"_108":285,"_102":32,"_169":286,"_171":287,"_172":22,"_173":-5,"_174":636,"_100":637},[],[268,283],{"_106":291,"_96":292,"_161":293,"_163":269,"_164":144,"_165":166,"_167":120,"_108":294,"_102":32,"_169":277,"_171":295,"_172":22,"_173":-5,"_174":639,"_100":640},[],[268,292],{"_106":299,"_96":300,"_161":301,"_163":269,"_164":144,"_165":166,"_167":120,"_108":302,"_102":32,"_169":181,"_171":303,"_172":22,"_173":-5,"_174":642,"_100":643},[],[268,300],{"_106":307,"_96":308,"_161":309,"_163":269,"_164":144,"_165":166,"_167":120,"_108":310,"_102":32,"_169":181,"_171":311,"_172":22,"_173":-5,"_174":645,"_100":646},[],[268,308],{"_106":315,"_96":316,"_161":317,"_163":269,"_164":144,"_165":166,"_167":120,"_108":318,"_102":32,"_169":181,"_171":319,"_172":22,"_173":-5,"_174":648,"_100":649},[],[268,316],[268],{"_106":324,"_96":325,"_161":326,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":327,"_102":32,"_169":170,"_171":-5,"_172":22,"_173":-5,"_174":652,"_100":707},[653,686,689,692,695,698,701,704],{"_106":330,"_96":331,"_161":332,"_163":326,"_164":144,"_165":166,"_167":120,"_108":333,"_102":32,"_169":170,"_171":-5,"_172":22,"_173":-5,"_174":654,"_100":685},[655,670,673,676,679,682],{"_106":336,"_96":337,"_161":338,"_163":332,"_164":144,"_165":166,"_167":120,"_108":339,"_102":32,"_169":170,"_171":-5,"_172":22,"_173":-5,"_174":656,"_100":669},[657,660,663,666],{"_106":342,"_96":343,"_161":344,"_163":338,"_164":144,"_165":166,"_167":120,"_108":345,"_102":32,"_169":346,"_171":347,"_172":22,"_173":-5,"_174":658,"_100":659},[],[325,331,337,343],{"_106":351,"_96":352,"_161":353,"_163":338,"_164":144,"_165":166,"_167":120,"_108":354,"_102":32,"_169":181,"_171":355,"_172":22,"_173":-5,"_174":661,"_100":662},[],[325,331,337,352],{"_106":359,"_96":360,"_161":361,"_163":338,"_164":144,"_165":166,"_167":120,"_108":362,"_102":32,"_169":346,"_171":363,"_172":22,"_173":-5,"_174":664,"_100":665},[],[325,331,337,360],{"_106":367,"_96":368,"_161":369,"_163":338,"_164":144,"_165":166,"_167":120,"_108":370,"_102":32,"_169":181,"_171":371,"_172":22,"_173":-5,"_174":667,"_100":668},[],[325,331,337,368],[325,331,337],{"_106":376,"_96":377,"_161":378,"_163":332,"_164":144,"_165":166,"_167":120,"_108":379,"_102":32,"_169":346,"_171":380,"_172":22,"_173":-5,"_174":671,"_100":672},[],[325,331,377],{"_106":384,"_96":385,"_161":386,"_163":332,"_164":144,"_165":166,"_167":120,"_108":387,"_102":32,"_169":181,"_171":388,"_172":22,"_173":-5,"_174":674,"_100":675},[],[325,331,385],{"_106":392,"_96":393,"_161":394,"_163":332,"_164":144,"_165":166,"_167":120,"_108":395,"_102":32,"_169":346,"_171":396,"_172":22,"_173":-5,"_174":677,"_100":678},[],[325,331,393],{"_106":400,"_96":401,"_161":402,"_163":332,"_164":144,"_165":166,"_167":120,"_108":403,"_102":32,"_169":181,"_171":404,"_172":22,"_173":-5,"_174":680,"_100":681},[],[325,331,401],{"_106":408,"_96":243,"_161":409,"_163":332,"_164":144,"_165":166,"_167":120,"_108":410,"_102":32,"_169":181,"_171":411,"_172":22,"_173":-5,"_174":683,"_100":684},[],[325,331,243],[325,331],{"_106":416,"_96":417,"_161":418,"_163":326,"_164":144,"_165":166,"_167":120,"_108":419,"_102":32,"_169":346,"_171":420,"_172":22,"_173":-5,"_174":687,"_100":688},[],[325,417],{"_106":424,"_96":425,"_161":426,"_163":326,"_164":144,"_165":166,"_167":120,"_108":427,"_102":32,"_169":346,"_171":428,"_172":22,"_173":-5,"_174":690,"_100":691},[],[325,425],{"_106":432,"_96":433,"_161":434,"_163":326,"_164":144,"_165":166,"_167":120,"_108":435,"_102":32,"_169":346,"_171":436,"_172":22,"_173":-5,"_174":693,"_100":694},[],[325,433],{"_106":440,"_96":441,"_161":442,"_163":326,"_164":144,"_165":166,"_167":120,"_108":443,"_102":32,"_169":346,"_171":444,"_172":22,"_173":-5,"_174":696,"_100":697},[],[325,441],{"_106":448,"_96":449,"_161":450,"_163":326,"_164":144,"_165":166,"_167":120,"_108":451,"_102":32,"_169":346,"_171":452,"_172":22,"_173":-5,"_174":699,"_100":700},[],[325,449],{"_106":456,"_96":457,"_161":458,"_163":326,"_164":144,"_165":166,"_167":120,"_108":459,"_102":32,"_169":346,"_171":460,"_172":22,"_173":-5,"_174":702,"_100":703},[],[325,457],{"_106":464,"_96":465,"_161":466,"_163":326,"_164":144,"_165":166,"_167":120,"_108":467,"_102":32,"_169":181,"_171":468,"_172":22,"_173":-5,"_174":705,"_100":706},[],[325,465],[325],{"_106":473,"_96":417,"_161":474,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":475,"_102":32,"_169":346,"_171":476,"_172":22,"_173":-5,"_174":709,"_100":710},[],[417],{"_106":480,"_96":481,"_161":482,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":483,"_102":32,"_169":346,"_171":484,"_172":22,"_173":-5,"_174":712,"_100":713},[],[481],{"_106":488,"_96":489,"_161":490,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":491,"_102":32,"_169":346,"_171":492,"_172":22,"_173":-5,"_174":715,"_100":716},[],[489],{"_106":496,"_96":497,"_161":498,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":499,"_102":32,"_169":346,"_171":492,"_172":22,"_173":-5,"_174":718,"_100":719},[],[497],{"_106":503,"_96":504,"_161":505,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":506,"_102":32,"_169":346,"_171":507,"_172":22,"_173":-5,"_174":721,"_100":722},[],[504],{"_106":511,"_96":512,"_161":513,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":514,"_102":32,"_169":346,"_171":515,"_172":22,"_173":-5,"_174":724,"_100":725},[],[512],{"_106":519,"_96":425,"_161":520,"_163":-5,"_164":144,"_165":166,"_167":22,"_108":521,"_102":32,"_169":346,"_171":522,"_172":22,"_173":-5,"_174":727,"_100":728},[],[425],{"_106":526,"_96":527,"_161":528,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":529,"_102":32,"_169":346,"_171":530,"_172":22,"_173":-5,"_174":730,"_100":731},[],[527],{"_106":534,"_96":535,"_161":536,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":537,"_102":32,"_169":346,"_171":538,"_172":22,"_173":-5,"_174":733,"_100":734},[],[535],{"_106":542,"_96":543,"_161":544,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":545,"_102":32,"_169":181,"_171":546,"_172":22,"_173":-5,"_174":736,"_100":737},[],[543],{"_106":550,"_96":551,"_161":552,"_163":-5,"_164":144,"_165":166,"_167":120,"_108":553,"_102":32,"_169":346,"_171":554,"_172":22,"_173":-5,"_174":739,"_100":740},[],[551],[594,596,599,602,605,608,611,614,617,620,623,626,630,632,635,638,641,644,647,651,653,655,657,660,663,666,670,673,676,679,682,686,689,692,695,698,701,704,708,711,714,717,720,723,726,729,732,735,738],{"_106":291,"_96":292,"_161":293,"_163":269,"_164":144,"_165":166,"_167":120,"_108":571,"_102":32,"_169":277,"_171":295,"_172":22,"_173":-5,"_100":743},[268,292],[],"upstream",{"_106":147,"_108":747,"_577":748,"_96":44,"_145":107,"_102":579,"_146":-5,"_148":-5,"_580":581,"_110":-5,"_155":22,"_112":113,"_154":95,"_16":125,"_153":97},["D",1763236734129],["D",1765047056289],"pull","ahead","behind","templates",[],"actionData","errors"]