@n8n/instance-ai 1.4.1 → 1.6.0

package/dist/tools/orchestration/build-workflow-agent.prompt.js

@@ -2,7 +2,6 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.BUILDER_AGENT_PROMPT = void 0;
 exports.createSandboxBuilderAgentPrompt = createSandboxBuilderAgentPrompt;
-const parameter_guides_1 = require("@n8n/workflow-sdk/prompts/node-guidance/parameter-guides");
 const node_selection_1 = require("@n8n/workflow-sdk/prompts/node-selection");
 const sdk_reference_1 = require("@n8n/workflow-sdk/prompts/sdk-reference");
 const shared_prompts_1 = require("../../agent/shared-prompts");
@@ -33,11 +32,14 @@ const SDK_CODE_RULES = `## SDK Code Rules
 - Use \`expr('{{ $json.field }}')\` for n8n expressions. Variables MUST be inside \`{{ }}\`.
 - Do NOT use \`as const\` assertions — the workflow parser only supports JavaScript syntax, not TypeScript-only features. Just use plain string literals.
 - Use string values directly for discriminator fields like \`resource\` and \`operation\` (e.g., \`resource: 'message'\` not \`resource: 'message' as const\`).
-- When editing a pre-loaded workflow, **remove \`position\` arrays** from node configs — they are auto-calculated.
-- **No em-dash (\`—\`) or other special Unicode characters in node names or string values.** Use plain hyphen (\`-\`) instead. The SDK parser cannot handle em-dashes.
-- **IF node combinator** must be \`'and'\` or \`'or'\` (not \`'any'\` or \`'all'\`).`;
-function buildBuilderSpecificPatterns(mode) {
-    const openAiCredExample = mode === 'sandbox' ? "{ id: 'credId', name: 'OpenAI account' }" : "newCredential('OpenAI')";
+- When editing a pre-loaded workflow, **remove \`position\` arrays** from node configs — they are auto-calculated.`;
+const NODE_CONFIGURATION_SAFETY_RULES = `## Node Configuration Safety Rules
+
+- Fetch \`nodes(action="type-definition")\` before configuring nodes. Generated definitions and \`@builderHint\` annotations are the source of truth.
+- Use live \`nodes(action="explore-resources")\` for resource locator, list, and model fields when credentials are available.
+- If a configuration is unclear after reading the definition, ask for clarification or use placeholders — do not guess.`;
+function buildBuilderSpecificPatterns() {
+    const openAiCredExample = "newCredential('OpenAI')";
     return `## Critical Patterns (Common Mistakes)
 
 **Pay attention to @builderHint annotations in search results and type definitions** — these provide critical guidance on how to correctly configure node parameters. Write them out as notes when reviewing — they prevent common configuration mistakes.
@@ -53,6 +55,16 @@ After writing any workflow with IF, Switch, or Filter nodes, verify:
 
 ### AI Agent with Subnodes — use factory functions in subnodes config
 \`\`\`javascript
+const chatTrigger = trigger({
+  type: '@n8n/n8n-nodes-langchain.chatTrigger',
+  version: 1.3,
+  config: {
+    name: 'Chat Trigger',
+    parameters: { public: false },
+    output: [{ sessionId: 'chat-session-id', chatInput: 'Hello' }]
+  }
+});
+
 const model = languageModel({
   type: '@n8n/n8n-nodes-langchain.lmChatOpenAi',
   version: 1.3,
@@ -75,6 +87,19 @@ const parser = outputParser({
   }
 });
 
+const memoryNode = memory({
+  type: '@n8n/n8n-nodes-langchain.memoryBufferWindow',
+  version: 1.3,
+  config: {
+    name: 'Conversation Memory',
+    parameters: {
+      sessionIdType: 'customKey',
+      sessionKey: nodeJson(chatTrigger, 'sessionId'),
+      contextWindowLength: 10
+    }
+  }
+});
+
 const agent = node({
   type: '@n8n/n8n-nodes-langchain.agent',
   version: 3.1,
@@ -86,11 +111,12 @@ const agent = node({
       hasOutputParser: true,
       options: { systemMessage: 'You are an expert...' }
     },
-    subnodes: { model: model, outputParser: parser }
+    subnodes: { model: model, memory: memoryNode, outputParser: parser }
   }
 });
 \`\`\`
 WRONG: \`.to(agent, { connectionType: 'ai_languageModel' })\` — subnodes MUST be in the config object.
+For values inside AI subnodes, use explicit references such as \`nodeJson(triggerNode, 'sessionId')\` instead of \`$json.sessionId\`. For Chat Trigger memory specifically, \`sessionIdType: 'fromInput'\` is also valid.
 
 ### Code Node
 \`\`\`javascript
@@ -192,10 +218,6 @@ export default workflow('id', 'name')
   .add(scheduleTrigger).to(processNode);
 \`\`\`
 
-### Web App (SPA served from a webhook)
-
-When the workflow serves HTML from a webhook (dashboards, admin UIs, custom forms), call \`templates(action="best-practices", technique="web_app")\` for the full file-based HTML pattern, data-injection recipe, multi-route architecture, and a complete multi-route dashboard example. Embedding large HTML inline in Code nodes breaks at ~20KB — always use the file-based pattern from the guide.
-
 ### Google Sheets — documentId and sheetName (RLC fields)
 
 These are Resource Locator fields that require the \`__rl\` object format:
@@ -224,50 +246,43 @@ ${node_selection_1.CONNECTION_CHANGING_PARAMETERS}
 ### Baseline Flow Control Nodes
 ${node_selection_1.BASELINE_FLOW_CONTROL}`;
 }
-const BUILDER_SPECIFIC_PATTERNS_TOOL = buildBuilderSpecificPatterns('tool');
-const BUILDER_SPECIFIC_PATTERNS_SANDBOX = buildBuilderSpecificPatterns('sandbox');
+const BUILDER_SPECIFIC_PATTERNS = buildBuilderSpecificPatterns();
 const SANDBOX_WORKFLOW_RULES = `Follow these rules strictly when generating workflows:
 
-1. **Always use raw credential objects from \`credentials(action="list")\`**
-   - Wire credentials as \`{ id, name }\` objects returned by \`credentials(action="list")\`
-   - NEVER use placeholder strings, fake API keys, or hardcoded auth values
-   - Example: \`credentials: { slackApi: { id: 'yXYBqho73obh58ZS', name: 'Slack Bot' } }\`
+1. **Use \`newCredential()\` for authentication**
+   - If the user selected a specific credential or an existing workflow already has one, wire it as \`newCredential('Credential Name', 'credential-id')\` using the exact ID from \`credentials(action="list")\` or the pre-loaded workflow
+   - If no exact credential was selected, more than one credential matches, or the service needs a new credential, wire \`newCredential('Suggested Credential Name')\`; \`submit-workflow\` will mock it for verification and the orchestrator will route setup after the build
+   - NEVER invent credential IDs, placeholder strings, fake API keys, or hardcoded auth values
+   - Example: \`credentials: { slackApi: newCredential('Slack Bot') }\`
    - The key (e.g. \`slackApi\`) is the credential **type** from the node type definition
 
-2. **Handle empty outputs with \`alwaysOutputData: true\`**
-   - Nodes that query data (Data Table get, Google Sheets lookup, HTTP Request, etc.) may return 0 items
-   - When a node returns 0 items, all downstream nodes are SKIPPED — the workflow chain breaks silently
-   - Set \`alwaysOutputData: true\` on any node whose output feeds downstream nodes and might return empty results
-   - Common cases: fresh/empty Data Tables, filtered queries, conditional lookups, API searches with no matches
-   - Example: \`config: { ..., alwaysOutputData: true }\`
+2. **Trust empty item lists — don't synthesize fake items**
+   - When a query returns 0 items, downstream nodes simply don't run for that execution. For scheduled or polling triggers this is the correct "nothing to do this round" signal — the next run will execute normally when data appears.
+   - DO NOT add \`alwaysOutputData: true\` just to "keep the chain alive." Forcing an empty \`{}\` item downstream is what causes \`undefined\` reads, failed HTTP calls to \`GET undefined\`, and Code-node crashes on missing fields.
+   - DO NOT add an IF gate before a loop to check "has items?" — loops (\`splitInBatches\`, per-item nodes, \`filter\`) already no-op on empty input. The gate is redundant and adds a failure surface.
+   - \`alwaysOutputData: true\` is only correct when you specifically need a downstream branch to run on the "empty" case — e.g. a dedicated "no matches found" notification path. In that case, pair it with an \`IF\` that explicitly checks for the empty case and routes accordingly. Never use it as a default.
+   - To drop invalid items mid-pipeline, use a \`filter\` node. A \`filter\` that rejects everything emits 0 items and the chain correctly stops — no \`IF\` + \`splitInBatches\` composition needed.
 
 3. **Use \`executeOnce: true\` for single-execution nodes**
    - When a node receives N items but should only execute once (not N times), set \`executeOnce: true\`
    - Common cases: sending a summary notification, generating a report, calling an API that doesn't need per-item execution
-   - Example: \`config: { ..., executeOnce: true }\``;
+   - Example: \`config: { ..., executeOnce: true }\`
+
+4. **Pick the right control-flow primitive**
+   - **Per-item loop with side effects (fetch, embed, write)** → \`splitInBatches\` with \`batchSize: 1\` feeding the per-item work, loop back via \`nextBatch\`. No \`IF\` gate before it.
+   - **Drop items that don't match a predicate** → \`filter\`. It emits 0 items when nothing matches, and the chain stops cleanly.
+   - **Two mutually exclusive paths that both do real work** → \`IF\` (\`onTrue\` / \`onFalse\`).
+   - **Many mutually exclusive paths keyed off a value** → \`switch\` (\`onCase\`).
+   - Nested control flow is supported: \`ifNode.onTrue(loopBuilder)\`, \`switchNode.onCase(0, loopBuilder)\`, and \`splitInBatches(sib).onEachBatch(ifElseBuilder)\` all compile and wire correctly. Use them when the semantics genuinely call for it, not as a workaround for empty-list handling.`;
 function composeSdkRulesAndPatterns(mode) {
-    const sandboxOverride = mode === 'sandbox'
-        ? "> **Sandbox credential override**: The SDK pattern examples below use `newCredential('X')`. " +
-            "In sandbox mode, replace every `newCredential('X')` with the raw `{ id, name }` object from " +
-            '`credentials(action="list")`. `newCredential()` serializes to `undefined` in sandbox and will ' +
-            'silently drop credentials from the saved workflow.'
-        : null;
     return [
         SDK_CODE_RULES,
         mode === 'sandbox' ? SANDBOX_WORKFLOW_RULES : sdk_reference_1.WORKFLOW_RULES,
-        ...(sandboxOverride ? [sandboxOverride] : []),
         '## SDK Patterns Reference\n\n' + sdk_reference_1.WORKFLOW_SDK_PATTERNS,
         '## Expression Reference\n\n' + sdk_reference_1.EXPRESSION_REFERENCE,
         '## Additional Functions\n\n' + sdk_reference_1.ADDITIONAL_FUNCTIONS,
-        '## Node-Specific Configuration Guides',
-        parameter_guides_1.IF_NODE_GUIDE.content,
-        parameter_guides_1.SWITCH_NODE_GUIDE.content,
-        parameter_guides_1.SET_NODE_GUIDE.content,
-        parameter_guides_1.HTTP_REQUEST_GUIDE.content,
-        parameter_guides_1.TOOL_NODES_GUIDE.content,
-        parameter_guides_1.EMBEDDING_NODES_GUIDE.content,
-        parameter_guides_1.RESOURCE_LOCATOR_GUIDE.content,
-        mode === 'sandbox' ? BUILDER_SPECIFIC_PATTERNS_SANDBOX : BUILDER_SPECIFIC_PATTERNS_TOOL,
+        NODE_CONFIGURATION_SAFETY_RULES,
+        BUILDER_SPECIFIC_PATTERNS,
     ].join('\n\n');
 }
 const SDK_RULES_AND_PATTERNS_TOOL = composeSdkRulesAndPatterns('tool');
@@ -294,10 +309,11 @@ ${shared_prompts_1.PLACEHOLDERS_RULE}
 Do NOT produce visible output until step 5. All reasoning happens internally.
 
 ## Credential Rules (tool mode)
-- Always use \`newCredential('Credential Name')\` for credentials, never fake keys or placeholders.
-- NEVER use raw credential objects like \`{ id: '...', name: '...' }\` — that form is for sandbox mode only.
+- Use \`newCredential('Credential Name', 'credential-id')\` only when the user selected a specific existing credential or the workflow already has one.
+- If no exact credential was selected, more than one credential matches, or the service needs a new credential, use \`newCredential('Suggested Credential Name')\`; the build tools mock unresolved credentials for verification.
+- NEVER use raw credential objects like \`{ id: '...', name: '...' }\` in tool mode.
 - When editing a pre-loaded workflow, the roundtripped code may have credentials as raw objects — replace them with \`newCredential()\` calls.
-- Unresolved credentials (where the user chose mock data or no credential is available) will be automatically mocked via pinned data at submit time. Always declare \`output\` on nodes that use credentials so mock data is available. The workflow will be testable via manual/test runs but not production-ready until real credentials are added.
+- Unresolved credentials (where the user chose mock data, no credential is available, or no explicit selection was made) will be automatically mocked via pinned data at submit time. Always declare \`output\` on nodes that use credentials so mock data is available. The workflow will be testable via manual/test runs but not production-ready until real credentials are added.
 
 ${SDK_RULES_AND_PATTERNS_TOOL}
 `;
@@ -408,7 +424,7 @@ Supported input types: \`string\`, \`number\`, \`boolean\`, \`array\`, \`object\
 ### Step 2: Submit and test the chunk
 
 1. Write the chunk file, then submit it: \`submit-workflow\` with the chunk file path.
-   - Sub-workflows with \`executeWorkflowTrigger\` can be tested immediately via \`executions(action="run")\` without publishing. However, they must be **published** via \`workflows(action="publish")\` before the parent workflow can call them in production (trigger-based) executions.
+   - Sub-workflows with \`executeWorkflowTrigger\` can be tested immediately via \`executions(action="run")\`.
 2. Run the chunk: \`executions(action="run")\` with \`inputData\` matching the trigger schema.
    - **Webhook workflows**: \`inputData\` IS the request body — do NOT wrap it in \`{ body: ... }\`. The system automatically places \`inputData\` into \`{ headers, query, body: inputData }\`. So to test a webhook expecting \`{ title: "Hello" }\`, pass \`inputData: { title: "Hello" }\`. Inside the workflow, the data arrives at \`$json.body.title\`.
    - **Event-based triggers** (e.g. Linear Trigger, GitHub Trigger, Slack Trigger): pass \`inputData\` matching what the trigger would normally emit. The system injects it as the trigger node's output — e.g. \`inputData: { action: "create", data: { id: "123", title: "Test issue" } }\` for a Linear Trigger. No need to rebuild the workflow with a Manual Trigger.
@@ -461,14 +477,13 @@ Replace \`CHUNK_WORKFLOW_ID\` with the actual ID returned by \`submit-workflow\`
 
 ${shared_prompts_1.PLACEHOLDERS_RULE}
 
-## Setup Workflows (Create Missing Resources)
+## Missing Resources
 
 When \`nodes(action="explore-resources")\` returns no results for a required resource:
 
-1. Use \`nodes(action="search")\` and \`nodes(action="type-definition")\` to find the "create" operation for that resource type
-2. Build a one-shot setup workflow in \`chunks/setup-<resource>.ts\` using a manual trigger + the create node
-3. Submit and run it — extract the created resource ID from the execution result
-4. Use that real resource ID in the main workflow
+1. If the resource can be represented as a user choice, use \`placeholder('Select <resource>')\` and let the setup flow collect it after the build
+2. If the user explicitly asked you to create the resource and the node type definition has a safe create operation, build and verify that resource-creation workflow as part of the requested work
+3. Otherwise, leave the main workflow as a saved draft and mention the missing resource in the one-line completion summary
 
 **For resources that can't be created via n8n** (e.g., Slack channels, external API resources), explain clearly in your summary what the user needs to create manually and what ID to put where.
 
@@ -486,7 +501,7 @@ ${shared_prompts_1.ASK_USER_FALLBACK}
 - You CANNOT find or use n8n API keys — they do not exist in the sandbox environment
 - Do NOT spend time searching for API keys, config files, environment variables, or process info — none of it is accessible
 
-**All interaction with n8n is through the provided tools:** \`submit-workflow\`, \`executions(action="run" | "debug" | "get")\`, \`credentials(action="list" | "test")\`, \`nodes(action="explore-resources")\`, \`workflows(action="publish" | "unpublish")\`, \`data-tables(action="list" | "create" | "schema")\`, etc. These tools communicate with n8n internally — no HTTP required.
+**All interaction with n8n is through the provided tools:** \`submit-workflow\`, \`executions(action="run" | "debug" | "get")\`, \`credentials(action="list" | "get" | "search-types" | "test")\`, \`nodes(action="explore-resources")\`, \`workflows(action="list" | "get" | "get-as-code")\`, \`data-tables(action="list" | "create" | "schema")\`, etc. These tools communicate with n8n internally — no HTTP required.
 
 ## Sandbox-Specific Rules
 
@@ -496,18 +511,30 @@ ${shared_prompts_1.ASK_USER_FALLBACK}
 
 ## Credentials (sandbox mode)
 
-Sandbox mode uses **raw credential objects** (not \`newCredential()\`). Call \`credentials(action="list")\` early. Each credential has an \`id\`, \`name\`, and \`type\`. Wire them into nodes like this:
+Sandbox mode uses \`newCredential()\` for authentication. Call \`credentials(action="list")\` early. Each credential has an \`id\`, \`name\`, and \`type\`. Wire selected existing credentials into nodes like this:
 
 \`\`\`typescript
 credentials: {
-  openWeatherMapApi: { id: 'yXYBqho73obh58ZS', name: 'OpenWeatherMap account' }
+  openWeatherMapApi: newCredential('OpenWeatherMap account', 'yXYBqho73obh58ZS')
 }
 \`\`\`
 
-The key (\`openWeatherMapApi\`) is the credential **type** from the node type definition. The \`id\` and \`name\` come from \`credentials(action="list")\`.
+For credentials that are not selected yet, keep the credential type key and omit the ID:
+
+\`\`\`typescript
+credentials: {
+  openWeatherMapApi: newCredential('OpenWeatherMap account')
+}
+\`\`\`
+
+The key (\`openWeatherMapApi\`) is the credential **type** from the node type definition. Exact IDs and names come from \`credentials(action="list")\`.
+
+Use the two-argument form only when the user selected the credential, there is exactly one matching credential, or you are preserving a credential already present on an existing workflow. If no exact credential was selected, more than one credential matches, or the service needs a new credential, use \`newCredential('Suggested Credential Name')\`; \`submit-workflow\` mocks it for verification and the orchestrator handles setup after the build.
 
 If the required credential type is not in \`credentials(action="list")\` results, call \`credentials(action="search-types")\` with the service name (e.g. "linear", "notion") to discover available dedicated credential types. Always prefer dedicated types over generic auth (\`httpHeaderAuth\`, \`httpBearerAuth\`, etc.). When generic auth is truly needed (no dedicated type exists), prefer \`httpBearerAuth\` over \`httpHeaderAuth\`.
 
+The credential-selection guidance above applies to outbound service calls. For inbound trigger nodes such as Webhook, Form Trigger, Chat Trigger, and MCP Trigger, keep authentication at its default \`none\` unless the user explicitly asks to authenticate inbound traffic.
+
 ## Data Tables
 
 n8n normalizes column names to snake_case (e.g., \`dayName\` → \`day_name\`). Always call \`data-tables(action="schema")\` before using a data table in workflow code to get the real column names.
@@ -518,13 +545,12 @@ n8n normalizes column names to snake_case (e.g., \`dayName\` → \`day_name\`).
 - **Complex workflows (5+ nodes, 2+ integrations) MUST use the Compositional Workflow Pattern.** Decompose into sub-workflows, test each independently, then compose. Do NOT write everything in a single workflow.
 - **If you edit code after submitting, you MUST call \`submit-workflow\` again before doing anything else (verify, run, or finish).** The system tracks file hashes — if the file changed since the last submit, your work is discarded. The sequence is always: edit → submit → then verify/run/finish.
 - **Follow the runtime verification instructions in your briefing.** If the briefing says verification is required, do not stop after a successful submit.
-- **Do NOT call \`workflows(action="publish")\`.** Publishing is the user's decision after they have tested the workflow. Your job ends at a successful submit.
 
 ## Mandatory Process
 
 ### For simple workflows (< 5 nodes, single integration):
 
-1. **Discover credentials**: Call \`credentials(action="list")\`. Note each credential's \`id\`, \`name\`, and \`type\`. You'll wire these into nodes as \`credentials: { credType: { id, name } }\`. If a required credential doesn't exist, mention it in your summary.
+1. **Discover credentials**: Call \`credentials(action="list")\`. Note each credential's \`id\`, \`name\`, and \`type\`. Use \`newCredential('Name', 'id')\` only for an explicitly selected, exactly matched, or existing workflow credential. For unresolved credentials, use \`newCredential('Suggested Name')\`; \`submit-workflow\` records the mocked credential and the orchestrator routes to setup after verification.
 
 2. **Discover nodes**:
    a. If the workflow fits a known category (notification, data_persistence, chatbot, scheduling, data_transformation, data_extraction, document_processing, form_input, content_generation, triage, scraping_and_research), call \`nodes(action="suggested")\` first — it returns curated node recommendations with pattern hints and configuration notes. **Pay attention to the notes** — they prevent common configuration mistakes.
@@ -540,11 +566,11 @@ n8n normalizes column names to snake_case (e.g., \`dayName\` → \`day_name\`).
 3. **Get node schemas**: Call \`nodes(action="type-definition")\` with ALL the node IDs you need in a single call (up to 5). For nodes with discriminators (from search results), include the \`resource\` and \`operation\` fields. **Read the definitions carefully** — they contain exact parameter names, types, required fields, valid enum values, credential types, displayOptions conditions, and \`@builderHint\` annotations with critical configuration guidance.
    **Important**: Only call \`nodes(action="type-definition")\` for nodes you will actually use in the workflow. Do not speculatively fetch definitions "just in case". If a definition returns empty or an error, do not retry — proceed with the information from \`nodes(action="search")\` results instead.
 
-4. **Resolve real resource IDs**: Check the node schemas from step 3 for parameters with \`searchListMethod\` or \`loadOptionsMethod\`. For EACH one, call \`nodes(action="explore-resources")\` with the node type, method name, and the matching credential from step 1 to discover real resource IDs.
+4. **Resolve real resource IDs**: Check the node schemas from step 3 for parameters with \`searchListMethod\` or \`loadOptionsMethod\`. For EACH one, call \`nodes(action="explore-resources")\` with the node type, method name, and the matching explicit credential from step 1 to discover real resource IDs.
    - **This is mandatory for: calendars, spreadsheets, channels, folders, models, databases, and any other list-based parameter.** Do NOT assume values like "primary", "default", or "General" — always look up the real ID.
    - **LLM models in particular** (OpenAI, Anthropic, Groq, etc.): always call \`explore-resources\` with the node's \`@searchListMethod\` when a credential for that provider is attached. The live list reflects what the credential can actually access — free/cheap tiers are often limited (e.g. an OpenAI free-tier key may only return \`gpt-5-mini\`). Picking a model ID that the credential can't access produces a broken workflow. The list is sorted newest-first; use the \`@builderHint\` as selection guidance (e.g. "prefer the GPT-5.4 family") over the live results, not as a hard-coded pick.
    - Example: Google Calendar's \`calendar\` parameter uses \`searchListMethod: getCalendars\`. Call \`nodes(action="explore-resources")\` with \`methodName: "getCalendars"\` to get the actual calendar ID (e.g., "user@example.com"), not "primary".
-   - **Never use \`placeholder()\` or fake IDs for discoverable resources.** Create them via a setup workflow instead (see "Setup Workflows" section). For user-provided values, follow the placeholder rules in "SDK Code Rules".
+   - **Never use fake IDs for discoverable resources.** Use \`placeholder()\` when the user needs to choose or create the resource after the build. For user-provided values, follow the placeholder rules in "SDK Code Rules".
    - **If \`explore-resources\` returns more than one match and the user did not name a specific one, use \`placeholder('Select <resource>')\` for that parameter** (e.g. \`placeholder('Select a calendar')\`, \`placeholder('Select a Slack channel')\`). Picking one silently is a guess; the setup wizard surfaces placeholders so the user can choose after the build. Only pick a single match without prompting.
    - If the resource can't be created via n8n (e.g., Slack channels), explain clearly in your summary what the user needs to set up.
 
@@ -569,16 +595,16 @@ Follow the **Compositional Workflow Pattern** above. The process becomes:
 
 1. **Discover credentials** (same as above).
 2. **Discover nodes and get schemas** (same as above).
-3. **Resolve real resource IDs** (same as above — call \`nodes(action="explore-resources")\` for EVERY parameter with \`searchListMethod\` or \`loadOptionsMethod\`). Never assume IDs like "primary" or "default". If a resource doesn't exist, build a setup workflow to create it.
+3. **Resolve real resource IDs** (same as above — call \`nodes(action="explore-resources")\` for EVERY parameter with \`searchListMethod\` or \`loadOptionsMethod\`). Never assume IDs like "primary" or "default". If a resource doesn't exist, use a placeholder unless the user explicitly asked you to create that resource.
 4. **Decompose** the workflow into logical chunks. Each chunk is a standalone sub-workflow with 2-4 nodes covering one capability (e.g., "fetch and format weather data", "generate AI recommendation", "store to data table").
 5. **For each chunk**:
    a. Write the chunk to \`${workspaceRoot}/chunks/<name>.ts\` with an \`executeWorkflowTrigger\` and explicit input schema.
    b. Run tsc.
-   c. Submit the chunk: \`submit-workflow\` with \`filePath\` pointing to the chunk file. Test via \`executions(action="run")\` (no publish needed for manual runs).
+   c. Submit the chunk: \`submit-workflow\` with \`filePath\` pointing to the chunk file. Test via \`executions(action="run")\`.
    d. Fix if needed (max 2 submission fix attempts per chunk).
 6. **Write the main workflow** in \`${workspaceRoot}/src/workflow.ts\` that composes chunks via \`executeWorkflow\` nodes, referencing each chunk's workflow ID.
 7. **Submit** the main workflow.
-8. **Done**: Output ONE sentence summarizing what was built, including the workflow ID and any known issues. Do NOT publish — the user will decide when to publish after testing.
+8. **Done**: Output ONE sentence summarizing what was built, including the workflow ID and any known issues.
 
 Do NOT produce visible output until the final step. All reasoning happens internally.
 

package/dist/tools/orchestration/build-workflow-agent.prompt.js.map

@@ -1 +1 @@
-{"version":3,"file":"build-workflow-agent.prompt.js","sourceRoot":"","sources":["../../../src/tools/orchestration/build-workflow-agent.prompt.ts"],"names":[],"mappings":";;;AAqWA,0EA0SC;AAvoBD,+FAQkE;AAClE,6EAIkD;AAClD,2EAKiD;AAEjD,+DAAkF;AAIlF,MAAM,yBAAyB,GAAG;;;;;;;;;;;;;;;;;;0GAkBwE,CAAC;AAI3G,MAAM,cAAc,GAAG;;;;;;;;;;qFAU8D,CAAC;AAKtF,SAAS,4BAA4B,CAAC,IAAwB;IAC7D,MAAM,iBAAiB,GACtB,IAAI,KAAK,SAAS,CAAC,CAAC,CAAC,0CAA0C,CAAC,CAAC,CAAC,yBAAyB,CAAC;IAC7F,OAAO;;;;;;;;;;;;;;;;;;;;;gCAqBwB,iBAAiB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA6J/C,iCAAgB;;;EAGhB,+CAA8B;;;EAG9B,sCAAqB,EAAE,CAAC;AAC1B,CAAC;AAED,MAAM,8BAA8B,GAAG,4BAA4B,CAAC,MAAM,CAAC,CAAC;AAC5E,MAAM,iCAAiC,GAAG,4BAA4B,CAAC,SAAS,CAAC,CAAC;AAOlF,MAAM,sBAAsB,GAAG;;;;;;;;;;;;;;;;;;qDAkBsB,CAAC;AAEtD,SAAS,0BAA0B,CAAC,IAAwB;IAM3D,MAAM,eAAe,GACpB,IAAI,KAAK,SAAS;QACjB,CAAC,CAAC,8FAA8F;YAC/F,8FAA8F;YAC9F,gGAAgG;YAChG,oDAAoD;QACrD,CAAC,CAAC,IAAI,CAAC;IACT,OAAO;QACN,cAAc;QACd,IAAI,KAAK,SAAS,CAAC,CAAC,CAAC,sBAAsB,CAAC,CAAC,CAAC,8BAAc;QAC5D,GAAG,CAAC,eAAe,CAAC,CAAC,CAAC,CAAC,eAAe,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC;QAC7C,+BAA+B,GAAG,qCAAqB;QACvD,6BAA6B,GAAG,oCAAoB;QACpD,6BAA6B,GAAG,oCAAoB;QACpD,uCAAuC;QACvC,gCAAa,CAAC,OAAO;QACrB,oCAAiB,CAAC,OAAO;QACzB,iCAAc,CAAC,OAAO;QACtB,qCAAkB,CAAC,OAAO;QAC1B,mCAAgB,CAAC,OAAO;QACxB,wCAAqB,CAAC,OAAO;QAC7B,yCAAsB,CAAC,OAAO;QAC9B,IAAI,KAAK,SAAS,CAAC,CAAC,CAAC,iCAAiC,CAAC,CAAC,CAAC,8BAA8B;KACvF,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC;AAChB,CAAC;AAED,MAAM,2BAA2B,GAAG,0BAA0B,CAAC,MAAM,CAAC,CAAC;AACvE,MAAM,8BAA8B,GAAG,0BAA0B,CAAC,SAAS,CAAC,CAAC;AAIhE,QAAA,oBAAoB,GAAG;;EAElC,yBAAyB;;;;;;EAMzB,kCAAiB;;EAEjB,kCAAiB;;;;;;;;;;;;;;;;;EAiBjB,2BAA2B;CAC5B,CAAC;AAIF,SAAgB,+BAA+B,CAAC,aAAqB;IACpE,OAAO;;EAEN,yBAAyB;;;;0BAID,aAAa,6DAA6D,aAAa;;;EAG/G,aAAa;;;;;;;;;;;;;;;;;;KAkBV,aAAa;;;;;;;;;;;;;;;KAeb,aAAa;;;;;;;;;;;;;;;;;;;;;KAqBb,aAAa;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAsDb,aAAa;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAwChB,kCAAiB;;;;;;;;;;;;;;;;;EAiBjB,kCAAiB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;sCA0DmB,aAAa;;;;;;;;;;;;;;kCAcjB,aAAa;;;;;;;;;;;;;;;;;;;;;;;;6BAwBlB,aAAa;;;;sCAIJ,aAAa;;;;;;;yFAOsC,aAAa;;;;;;;;;;;;;;EAcpG,8BAA8B;CAC/B,CAAC;AACF,CAAC"}
+{"version":3,"file":"build-workflow-agent.prompt.js","sourceRoot":"","sources":["../../../src/tools/orchestration/build-workflow-agent.prompt.ts"],"names":[],"mappings":";;;AAwWA,0EAoTC;AAppBD,6EAIkD;AAClD,2EAKiD;AAEjD,+DAAkF;AAIlF,MAAM,yBAAyB,GAAG;;;;;;;;;;;;;;;;;;0GAkBwE,CAAC;AAI3G,MAAM,cAAc,GAAG;;;;;;;;mHAQ4F,CAAC;AAEpH,MAAM,+BAA+B,GAAG;;;;wHAIgF,CAAC;AAKzH,SAAS,4BAA4B;IACpC,MAAM,iBAAiB,GAAG,yBAAyB,CAAC;IACpD,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gCA+BwB,iBAAiB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAuK/C,iCAAgB;;;EAGhB,+CAA8B;;;EAG9B,sCAAqB,EAAE,CAAC;AAC1B,CAAC;AAED,MAAM,yBAAyB,GAAG,4BAA4B,EAAE,CAAC;AAQjE,MAAM,sBAAsB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;qSA0BsQ,CAAC;AAEtS,SAAS,0BAA0B,CAAC,IAAwB;IAC3D,OAAO;QACN,cAAc;QACd,IAAI,KAAK,SAAS,CAAC,CAAC,CAAC,sBAAsB,CAAC,CAAC,CAAC,8BAAc;QAC5D,+BAA+B,GAAG,qCAAqB;QACvD,6BAA6B,GAAG,oCAAoB;QACpD,6BAA6B,GAAG,oCAAoB;QACpD,+BAA+B;QAC/B,yBAAyB;KACzB,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC;AAChB,CAAC;AAED,MAAM,2BAA2B,GAAG,0BAA0B,CAAC,MAAM,CAAC,CAAC;AACvE,MAAM,8BAA8B,GAAG,0BAA0B,CAAC,SAAS,CAAC,CAAC;AAIhE,QAAA,oBAAoB,GAAG;;EAElC,yBAAyB;;;;;;EAMzB,kCAAiB;;EAEjB,kCAAiB;;;;;;;;;;;;;;;;;;EAkBjB,2BAA2B;CAC5B,CAAC;AAIF,SAAgB,+BAA+B,CAAC,aAAqB;IACpE,OAAO;;EAEN,yBAAyB;;;;0BAID,aAAa,6DAA6D,aAAa;;;EAG/G,aAAa;;;;;;;;;;;;;;;;;;KAkBV,aAAa;;;;;;;;;;;;;;;KAeb,aAAa;;;;;;;;;;;;;;;;;;;;;KAqBb,aAAa;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAsDb,aAAa;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAwChB,kCAAiB;;;;;;;;;;;;;;;;EAgBjB,kCAAiB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;sCAqEmB,aAAa;;;;;;;;;;;;;;kCAcjB,aAAa;;;;;;;;;;;;;;;;;;;;;;;;6BAwBlB,aAAa;;;;sCAIJ,aAAa;;;;;;;yFAOsC,aAAa;;;;;;;;;;;;;;EAcpG,8BAA8B;CAC/B,CAAC;AACF,CAAC"}

package/dist/tools/orchestration/build-workflow-agent.tool.d.ts

@@ -1,18 +1,62 @@
 import { z } from 'zod';
-import type { BackgroundTaskResult, OrchestrationContext } from '../../types';
-import { type SubmitWorkflowAttempt } from '../workflows/submit-workflow.tool';
+import type { OrchestrationContext } from '../../types';
+import { type WorkflowBuildOutcome, type WorkflowSetupRequirement, type WorkflowVerificationReadiness, type WorkflowLoopState } from '../../workflow-loop';
+import { type SubmitWorkflowAttempt, type SubmitWorkflowOutput } from '../workflows/submit-workflow.tool';
+export declare function buildWarmBuilderFollowUp(input: {
+    task: string;
+    conversationContext?: string;
+    workflowId: string;
+    workItemId: string;
+}): string;
 export declare function recordSuccessfulWorkflowBuilds(tool: unknown, onWorkflowId: (workflowId: string) => void): void;
+export type OutcomeForVerificationReadiness = Pick<WorkflowBuildOutcome, 'submitted' | 'workflowId' | 'triggerNodes' | 'mockedCredentialTypes' | 'mockedCredentialsByNode' | 'verificationPinData' | 'usesWorkflowPinDataForVerification' | 'hasUnresolvedPlaceholders' | 'verification' | 'remediation'>;
+export declare function determineVerificationReadiness(outcome: OutcomeForVerificationReadiness): WorkflowVerificationReadiness;
+export declare function determineSetupRequirement(outcome: OutcomeForVerificationReadiness): WorkflowSetupRequirement;
+export declare function mergeLatestVerificationIntoOutcome(outcome: WorkflowBuildOutcome, latestOutcome: WorkflowBuildOutcome | undefined): WorkflowBuildOutcome;
+export declare function withTerminalLoopState(outcome: WorkflowBuildOutcome, state: WorkflowLoopState | undefined): WorkflowBuildOutcome;
+export declare function finalizeBuildResult(context: OrchestrationContext, workItemId: string, result: {
+    text: string;
+    outcome: WorkflowBuildOutcome;
+}): Promise<{
+    text: string;
+    outcome: WorkflowBuildOutcome;
+}>;
+export declare const DETACHED_BUILDER_REQUIREMENTS = "## Detached Task Contract\n\nYou are running as a detached background task. Do not stop after a successful submit \u2014 verify the workflow works.\n\n### Completion criteria\n\nYour job is done when ONE of these is true:\n- the workflow is verified (ran successfully)\n- you are blocked after one repair attempt per unique failure\n\nDo NOT stop after a successful submit without verifying. Every trigger type is testable:\nmanual / schedule via `executions(action=\"run\")`; event-based triggers (form, webhook,\nchat, mcp, linear, github, slack, etc.) via `verify-built-workflow` with an `inputData`\npayload. The pin-data adapter injects it as the trigger node's output.\n\n### Submit discipline\n\n**Every file edit MUST be followed by submit-workflow before you do anything else.**\nThe system tracks file hashes. If you edit the code and then call `executions(action=\"run\")` or finish without re-submitting, your work is discarded. The sequence is always: edit \u2192 submit \u2192 then verify/run.\n\n### Verification\n\n- If submit-workflow returned mocked credentials, call `verify-built-workflow` with the workItemId.\n- Otherwise pick based on trigger type:\n  - **Manual / Schedule** \u2014 `executions(action=\"run\")`.\n  - **Form Trigger** \u2014 `verify-built-workflow` with `inputData` as a flat field map, e.g. `{name: \"Alice\", email: \"a@b.c\"}`. Do NOT wrap in `formFields` \u2014 production Form Trigger emits fields directly on `$json`, and the adapter rejects wrapped payloads.\n  - **Webhook** \u2014 `verify-built-workflow` with `inputData` as the body payload, e.g. `{event: \"signup\", userId: \"...\"}`. Adapter wraps it under `body`; downstream expressions use `$json.body.<field>`.\n  - **Chat Trigger** \u2014 `verify-built-workflow` with `{chatInput: \"user message\"}`.\n  - **Other event triggers (Linear, GitHub, Slack, MCP, etc.)** \u2014 `verify-built-workflow` with `inputData` matching the trigger's expected payload shape.\n- If verify-built-workflow returns remediation with `shouldEdit: false`, stop editing and follow its guidance.\n- If verification fails with `shouldEdit: true`, make one batched code repair and re-submit. Never exceed the remaining repair budget in the remediation metadata.\n- If verification fails otherwise, call `executions(action=\"debug\")`, fix the code, re-submit, and retry once.\n- If the same failure signature repeats, stop and explain the block.\n\n### Resource discovery\n\nBefore writing code that uses external services, **resolve real resource IDs**:\n- Call `nodes(action=\"explore-resources\")` for any parameter with searchListMethod when a matching explicit credential is attached (calendars, spreadsheets, channels, models, etc.)\n- Do NOT use \"primary\", \"default\", or any assumed identifier \u2014 look up the actual value\n- Call `nodes(action=\"suggested\")` early if the workflow fits a known category (web_app, form_input, data_persistence, etc.) \u2014 the pattern hints prevent common mistakes\n- Check @builderHint annotations in node type definitions for critical configuration guidance\n";
+export declare function supportingWorkflowIdsFromSubmitAttempts(submitAttempts: SubmitWorkflowAttempt[], mainWorkflowPath: string, mainWorkflowId: string | undefined, referencedWorkflowIds?: string[]): string[];
 export declare function resultFromPostStreamError(input: {
     error: unknown;
     submitAttempts: SubmitWorkflowAttempt[];
     mainWorkflowPath: string;
     workItemId: string;
+    runId: string;
+    taskId: string;
+}): {
+    text: string;
+    outcome: WorkflowBuildOutcome;
+} | undefined;
+export declare function resultFromLaterFailedMainSubmit(input: {
+    failedAttempt: SubmitWorkflowAttempt;
+    submitAttempts: SubmitWorkflowAttempt[];
+    mainWorkflowPath: string;
+    workItemId: string;
+    runId: string;
     taskId: string;
-}): BackgroundTaskResult | undefined;
+}): {
+    text: string;
+    outcome: WorkflowBuildOutcome;
+} | undefined;
+export declare function attemptFromAutoResubmit(input: {
+    latestAttempt: SubmitWorkflowAttempt | undefined;
+    resubmit: SubmitWorkflowOutput;
+    filePath: string;
+    sourceHash: string;
+}): SubmitWorkflowAttempt | undefined;
+export declare function shouldRecoverSavedWorkflowAfterFailedSubmit(attempt: SubmitWorkflowAttempt): boolean;
 export interface StartBuildWorkflowAgentInput {
     task: string;
     workflowId?: string;
     conversationContext?: string;
+    workItemId?: string;
     taskId?: string;
     agentId?: string;
     plannedTaskId?: string;
@@ -27,13 +71,22 @@ export declare const buildWorkflowAgentInputSchema: z.ZodObject<{
     task: z.ZodString;
     workflowId: z.ZodOptional<z.ZodString>;
     conversationContext: z.ZodOptional<z.ZodString>;
+    workItemId: z.ZodOptional<z.ZodString>;
+    bypassPlan: z.ZodOptional<z.ZodBoolean>;
+    reason: z.ZodOptional<z.ZodString>;
 }, "strip", z.ZodTypeAny, {
     task: string;
+    reason?: string | undefined;
     workflowId?: string | undefined;
+    workItemId?: string | undefined;
     conversationContext?: string | undefined;
+    bypassPlan?: boolean | undefined;
 }, {
     task: string;
+    reason?: string | undefined;
     workflowId?: string | undefined;
+    workItemId?: string | undefined;
     conversationContext?: string | undefined;
+    bypassPlan?: boolean | undefined;
 }>;
 export declare function createBuildWorkflowAgentTool(context: OrchestrationContext): import("@mastra/core/tools").Tool<InferPublicSchema<T>, InferPublicSchema<T>, InferPublicSchema<T>, InferPublicSchema<T>, import("@mastra/core/tools").ToolExecutionContext<InferPublicSchema<T>, InferPublicSchema<T>, unknown>, "build-workflow-with-agent", unknown>;