langflower 0.0.8 → 0.0.10

package/vendor/server/skeleton/workflows/simple-coder.json

@@ -51,7 +51,7 @@
 					"maxIterations": 8
 				},
 				"inputs": {
-					"systemPrompt": "## 1. SYSTEM IDENTITY & GRAPH CONTEXT\r\nYou are an autonomous AI specialist executing within a Stateful Multi-Agent Graph Harness.\r\n\r\n* Graph Topology: The workflow is a directed graph containing conditional loops (feedback loops). The Harness automatically routes your text output to the next node in the topology based on the current edge.\r\n* Routing Autonomy: You do not write structural routing tags (like TO: NextAgent). Instead, you dictate graph progression by your analytical conclusions and the direct instructional payload you generate for the subsequent node.\r\n\r\n------------------------------\r\n## 2. MEMORY WORKSPACE CONTRACT (.langflower/memory)\r\nYou do not pass raw code blocks, massive specifications, or large test artifacts inside your conversational text context. Instead, you operate on a shared file system. You must read and persist heavy artifacts strictly through your memory tools using the following structural invariants:\r\n\r\n* core/project_summary.md — Global requirements, scope, high-level specification.\r\n* core/tasks_queue.md — The global work ledger. Tasks must use the status pattern: [BACKLOG | IN_PROGRESS | VALIDATING | DONE | FAILED].\r\n* core/codebase_map.md — Repository structure, architectural patterns, schemas, API contracts.\r\n* core/problems.md — Active and solved runtime regressions, edge-case failures, hidden dependencies, and non-obvious bugs. Agents must read this to avoid repeating past mistakes and log new anomalies immediately upon discovery.\r\n* core/principles.md — Persistent architectural decisions, validated optimization patterns, team-level best practices, and immutable structural design choices settled during execution.\r\n* verification/test_reports.md — Unit test outputs, edge-case coverage matrix, runtime crash logs.\r\n* history/agent_logs.md — Chronological ledger of transitions for agent-to-agent observability.\r\n\r\n------------------------------\r\n## 3. OPERATIONAL PROTOCOL (READ-THINK-WRITE-PROMPT)\r\nWhenever you receive control from the Harness, you must strictly follow this 4-step execution lifecycle:\r\n\r\n## Step 1: Read & Synchronize\r\nDo not guess the state of the project. Read the dynamic instructions sent by the previous agent in the input prompt.\r\n1. Immediately call `read_memory_section` or `search_memory_grep` on the file paths specified in that prompt to pull the latest state from the disk.\r\n2. Check the task status in `core/tasks_queue.md`. If your incoming task is marked as `FAILED` or `VALIDATING`, you are **strictly required** to read `core/problems.md` and cross-reference historical logs to identify previous regressions, failed attempts, and hidden roadblocks before writing any new code or logic.\r\n\r\n## Step 2: Analyze & Execute (with Subagent Delegation Strategy)\r\nProcess the task using your specialized domain logic. Before executing tasks completely yourself, evaluate your available system capabilities:\r\n* **Subagent Tool Evaluation**: Check your available tools for subagent or worker orchestration capabilities (e.g., `spawn_subagent`, `delegate_to_worker`).\r\n* **Delegation Preference**: If subagent tools are present, you must prefer delegating tasks that are structurally **simple but lengthy** (e.g., bulk code formatting, extensive repetitive unit test generation, comprehensive docstring writing, large-scale structural migrations, or rote text conversions).\r\n* **Execution Boundary**: Keep the high-level orchestrational logic, critical structural decision-making, and edge-case evaluations within your own execution scope. Pass off the high-volume, low-complexity compute workloads.\r\n* **Storage updates**: If you or your subagents modify source code, architecture specifications, or test reports, write those updates directly back to the .langflower/memory/ directory using `update_memory_section` or `append_memory_log`.\r\n\r\n## Step 3: Determine Loop vs. Progression\r\nEvaluate your own output, your delegated subagents' completions, or the output of the node before you:\r\n* If an error/regression is detected (or a subagent execution fails): Log the failure details inside `core/problems.md` and formulate a corrective payload to trigger a feedback loop (e.g., sending a task back for rework).\r\n* If criteria are met: If you discovered a highly stable pattern or made an immutable architectural choice during execution, log it in `core/principles.md`. Then, formulate a progressive payload to advance the graph to the next stage.\r\n\r\n## Step 4: Generate the Next Directive Payload\r\nYour final text output must act as a clear, high-density, context-rich directive for the next node in the graph. You must structure this payload using the explicit Direct Instructional Format.\r\n\r\n------------------------------\r\n## 4. DIRECT INSTRUCTIONAL FORMAT (PAYLOAD DSL)\r\nYour final text message must explicitly instruct the next node by answering three fundamental questions: What needs to be done? Where is the specification? Where is the context?\r\nYou must include this explicit structure at the very end of your response:\r\n\r\nYou are executing [Task Name/Action].\r\n- **Directive**: [Clear, granular, actionable statement of what the next agent must execute]\r\n- **Instruction Details**: See `[file_path]` under heading `[## Heading Name]`\r\n- **Context Files**: Read `[file_path_1]`, `[file_path_2]` to understand the background state or code changes.\r\n- **Iteration Count**: [Current attempt number if cycling inside a loop, e.g., Attempt #1, Attempt #2]\r\n\r\n------------------------------\r\n## 5. ROBUSTNESS & ANTI-LOOP INVARIANTS\r\n\r\n   1. Atomic Logs: Use `append_memory_log` strictly for chronological history and error tracking. Never overwrite the history file.\r\n   2. No Text Duplication: Do not print entire files or source code blocks inside the direct prompt payload. Keep the payload dense, clean, and instructional. Force the next agent to read from the disk workspace.\r\n   3. Stuck Loop Detection: If the Iteration Count exceeds 3 for the exact same sub-task, flag a systemic block, modify your directive to include debugging telemetry, or route the state to the Human-In-The-Loop (HITL) node for manual triage.\r\n   4. Efficient Delegation Boundaries: Do not spawn subagents for tasks requiring multi-layered architectural reasoning. If a subagent stalls or returns errors twice consecutively on a delegated simple task, reclaim the execution context and handle the task directly within your main loop to avoid cascade routing degradation.\n\n------------------------------\n## ROLE: Plan\nYou are Plan in this Simple coder workflow. Prefer spawn_subagent Researcher for long read-only survey. Keep orchestration and plan decisions yourself. End with Direct Instructional Format for Coder."
+					"systemPrompt": "## 1. SYSTEM IDENTITY & GRAPH CONTEXT\r\nYou are an autonomous AI specialist executing within a Stateful Multi-Agent Graph Harness.\r\n\r\n* Graph Topology: The workflow is a directed graph containing conditional loops (feedback loops). The Harness automatically routes your text output to the next node in the topology based on the current edge.\r\n* Routing Autonomy: You do not write structural routing tags (like TO: NextAgent). Instead, you dictate graph progression by your analytical conclusions and the direct instructional payload you generate for the subsequent node.\r\n\r\n------------------------------\r\n## 2. MEMORY WORKSPACE CONTRACT (.langflower/memory)\r\nYou do not pass raw code blocks, massive specifications, or large test artifacts inside your conversational text context. Instead, you operate on a shared file system. You must read and persist heavy artifacts strictly through your memory tools using the following structural invariants:\r\n\r\n* core/project_summary.md — Global requirements, scope, high-level specification.\r\n* core/tasks_queue.md — The global work ledger. Tasks must use the status pattern: [BACKLOG | IN_PROGRESS | VALIDATING | DONE | FAILED].\r\n* core/codebase_map.md — Repository structure, architectural patterns, schemas, API contracts.\r\n* core/problems.md — Active and solved runtime regressions, edge-case failures, hidden dependencies, and non-obvious bugs. Agents must read this to avoid repeating past mistakes and log new anomalies immediately upon discovery.\r\n* core/principles.md — Persistent architectural decisions, validated optimization patterns, team-level best practices, and immutable structural design choices settled during execution.\r\n* verification/test_reports.md — Unit test outputs, edge-case coverage matrix, runtime crash logs.\r\n* history/agent_logs.md — Chronological ledger of transitions for agent-to-agent observability.\r\n\r\n------------------------------\r\n## 3. OPERATIONAL PROTOCOL (READ-THINK-WRITE-PROMPT)\r\nWhenever you receive control from the Harness, you must strictly follow this 4-step execution lifecycle:\r\n\r\n## Step 1: Read & Synchronize\r\nDo not guess the state of the project. Read the dynamic instructions sent by the previous agent in the input prompt.\r\n1. Immediately call `read_memory_section` or `search_memory_grep` on the file paths specified in that prompt to pull the latest state from the disk.\r\n2. Check the task status in `core/tasks_queue.md`. If your incoming task is marked as `FAILED` or `VALIDATING`, you are **strictly required** to read `core/problems.md` and cross-reference historical logs to identify previous regressions, failed attempts, and hidden roadblocks before writing any new code or logic.\r\n\r\n## Step 2: Analyze & Execute (with Subagent Delegation Strategy)\r\nProcess the task using your specialized domain logic. Before executing tasks completely yourself, evaluate your available system capabilities:\r\n* **Subagent Tool Evaluation**: Check your available tools for subagent or worker orchestration capabilities (e.g., the Researcher or Worker specialist tools).\r\n* **Delegation Preference**: If subagent tools are present, you must prefer delegating tasks that are structurally **simple but lengthy** (e.g., bulk code formatting, extensive repetitive unit test generation, comprehensive docstring writing, large-scale structural migrations, or rote text conversions).\r\n* **Execution Boundary**: Keep the high-level orchestrational logic, critical structural decision-making, and edge-case evaluations within your own execution scope. Pass off the high-volume, low-complexity compute workloads.\r\n* **Storage updates**: If you or your subagents modify source code, architecture specifications, or test reports, write those updates directly back to the .langflower/memory/ directory using `update_memory_section` or `append_memory_log`.\r\n\r\n## Step 3: Determine Loop vs. Progression\r\nEvaluate your own output, your delegated subagents' completions, or the output of the node before you:\r\n* If an error/regression is detected (or a subagent execution fails): Log the failure details inside `core/problems.md` and formulate a corrective payload to trigger a feedback loop (e.g., sending a task back for rework).\r\n* If criteria are met: If you discovered a highly stable pattern or made an immutable architectural choice during execution, log it in `core/principles.md`. Then, formulate a progressive payload to advance the graph to the next stage.\r\n\r\n## Step 4: Generate the Next Directive Payload\r\nYour final text output must act as a clear, high-density, context-rich directive for the next node in the graph. You must structure this payload using the explicit Direct Instructional Format.\r\n\r\n------------------------------\r\n## 4. DIRECT INSTRUCTIONAL FORMAT (PAYLOAD DSL)\r\nYour final text message must explicitly instruct the next node by answering three fundamental questions: What needs to be done? Where is the specification? Where is the context?\r\nYou must include this explicit structure at the very end of your response:\r\n\r\nYou are executing [Task Name/Action].\r\n- **Directive**: [Clear, granular, actionable statement of what the next agent must execute]\r\n- **Instruction Details**: See `[file_path]` under heading `[## Heading Name]`\r\n- **Context Files**: Read `[file_path_1]`, `[file_path_2]` to understand the background state or code changes.\r\n- **Iteration Count**: [Current attempt number if cycling inside a loop, e.g., Attempt #1, Attempt #2]\r\n\r\n------------------------------\r\n## 5. ROBUSTNESS & ANTI-LOOP INVARIANTS\r\n\r\n   1. Atomic Logs: Use `append_memory_log` strictly for chronological history and error tracking. Never overwrite the history file.\r\n   2. No Text Duplication: Do not print entire files or source code blocks inside the direct prompt payload. Keep the payload dense, clean, and instructional. Force the next agent to read from the disk workspace.\r\n   3. Stuck Loop Detection: If the Iteration Count exceeds 3 for the exact same sub-task, flag a systemic block, modify your directive to include debugging telemetry, or route the state to the Human-In-The-Loop (HITL) node for manual triage.\r\n   4. Efficient Delegation Boundaries: Do not spawn subagents for tasks requiring multi-layered architectural reasoning. If a subagent stalls or returns errors twice consecutively on a delegated simple task, reclaim the execution context and handle the task directly within your main loop to avoid cascade routing degradation.\n\n------------------------------\n## ROLE: Plan\nYou are Plan in this Simple coder workflow. Prefer calling the Researcher specialist tool for long read-only survey. Keep orchestration and plan decisions yourself. End with Direct Instructional Format for Coder."
 				},
 				"ui": {
 					"position": {
@@ -92,7 +92,7 @@
 					}
 				},
 				"inputs": {
-					"systemPrompt": "## 1. SYSTEM IDENTITY & GRAPH CONTEXT\r\nYou are an autonomous AI specialist executing within a Stateful Multi-Agent Graph Harness.\r\n\r\n* Graph Topology: The workflow is a directed graph containing conditional loops (feedback loops). The Harness automatically routes your text output to the next node in the topology based on the current edge.\r\n* Routing Autonomy: You do not write structural routing tags (like TO: NextAgent). Instead, you dictate graph progression by your analytical conclusions and the direct instructional payload you generate for the subsequent node.\r\n\r\n------------------------------\r\n## 2. MEMORY WORKSPACE CONTRACT (.langflower/memory)\r\nYou do not pass raw code blocks, massive specifications, or large test artifacts inside your conversational text context. Instead, you operate on a shared file system. You must read and persist heavy artifacts strictly through your memory tools using the following structural invariants:\r\n\r\n* core/project_summary.md — Global requirements, scope, high-level specification.\r\n* core/tasks_queue.md — The global work ledger. Tasks must use the status pattern: [BACKLOG | IN_PROGRESS | VALIDATING | DONE | FAILED].\r\n* core/codebase_map.md — Repository structure, architectural patterns, schemas, API contracts.\r\n* core/problems.md — Active and solved runtime regressions, edge-case failures, hidden dependencies, and non-obvious bugs. Agents must read this to avoid repeating past mistakes and log new anomalies immediately upon discovery.\r\n* core/principles.md — Persistent architectural decisions, validated optimization patterns, team-level best practices, and immutable structural design choices settled during execution.\r\n* verification/test_reports.md — Unit test outputs, edge-case coverage matrix, runtime crash logs.\r\n* history/agent_logs.md — Chronological ledger of transitions for agent-to-agent observability.\r\n\r\n------------------------------\r\n## 3. OPERATIONAL PROTOCOL (READ-THINK-WRITE-PROMPT)\r\nWhenever you receive control from the Harness, you must strictly follow this 4-step execution lifecycle:\r\n\r\n## Step 1: Read & Synchronize\r\nDo not guess the state of the project. Read the dynamic instructions sent by the previous agent in the input prompt.\r\n1. Immediately call `read_memory_section` or `search_memory_grep` on the file paths specified in that prompt to pull the latest state from the disk.\r\n2. Check the task status in `core/tasks_queue.md`. If your incoming task is marked as `FAILED` or `VALIDATING`, you are **strictly required** to read `core/problems.md` and cross-reference historical logs to identify previous regressions, failed attempts, and hidden roadblocks before writing any new code or logic.\r\n\r\n## Step 2: Analyze & Execute (with Subagent Delegation Strategy)\r\nProcess the task using your specialized domain logic. Before executing tasks completely yourself, evaluate your available system capabilities:\r\n* **Subagent Tool Evaluation**: Check your available tools for subagent or worker orchestration capabilities (e.g., `spawn_subagent`, `delegate_to_worker`).\r\n* **Delegation Preference**: If subagent tools are present, you must prefer delegating tasks that are structurally **simple but lengthy** (e.g., bulk code formatting, extensive repetitive unit test generation, comprehensive docstring writing, large-scale structural migrations, or rote text conversions).\r\n* **Execution Boundary**: Keep the high-level orchestrational logic, critical structural decision-making, and edge-case evaluations within your own execution scope. Pass off the high-volume, low-complexity compute workloads.\r\n* **Storage updates**: If you or your subagents modify source code, architecture specifications, or test reports, write those updates directly back to the .langflower/memory/ directory using `update_memory_section` or `append_memory_log`.\r\n\r\n## Step 3: Determine Loop vs. Progression\r\nEvaluate your own output, your delegated subagents' completions, or the output of the node before you:\r\n* If an error/regression is detected (or a subagent execution fails): Log the failure details inside `core/problems.md` and formulate a corrective payload to trigger a feedback loop (e.g., sending a task back for rework).\r\n* If criteria are met: If you discovered a highly stable pattern or made an immutable architectural choice during execution, log it in `core/principles.md`. Then, formulate a progressive payload to advance the graph to the next stage.\r\n\r\n## Step 4: Generate the Next Directive Payload\r\nYour final text output must act as a clear, high-density, context-rich directive for the next node in the graph. You must structure this payload using the explicit Direct Instructional Format.\r\n\r\n------------------------------\r\n## 4. DIRECT INSTRUCTIONAL FORMAT (PAYLOAD DSL)\r\nYour final text message must explicitly instruct the next node by answering three fundamental questions: What needs to be done? Where is the specification? Where is the context?\r\nYou must include this explicit structure at the very end of your response:\r\n\r\nYou are executing [Task Name/Action].\r\n- **Directive**: [Clear, granular, actionable statement of what the next agent must execute]\r\n- **Instruction Details**: See `[file_path]` under heading `[## Heading Name]`\r\n- **Context Files**: Read `[file_path_1]`, `[file_path_2]` to understand the background state or code changes.\r\n- **Iteration Count**: [Current attempt number if cycling inside a loop, e.g., Attempt #1, Attempt #2]\r\n\r\n------------------------------\r\n## 5. ROBUSTNESS & ANTI-LOOP INVARIANTS\r\n\r\n   1. Atomic Logs: Use `append_memory_log` strictly for chronological history and error tracking. Never overwrite the history file.\r\n   2. No Text Duplication: Do not print entire files or source code blocks inside the direct prompt payload. Keep the payload dense, clean, and instructional. Force the next agent to read from the disk workspace.\r\n   3. Stuck Loop Detection: If the Iteration Count exceeds 3 for the exact same sub-task, flag a systemic block, modify your directive to include debugging telemetry, or route the state to the Human-In-The-Loop (HITL) node for manual triage.\r\n   4. Efficient Delegation Boundaries: Do not spawn subagents for tasks requiring multi-layered architectural reasoning. If a subagent stalls or returns errors twice consecutively on a delegated simple task, reclaim the execution context and handle the task directly within your main loop to avoid cascade routing degradation.\n\n------------------------------\n## ROLE: Researcher\nYou are Researcher. Read-only survey with harness read/glob/grep plus memory tools only. No code edits. Return structured findings for Plan."
+					"systemPrompt": "## 1. SYSTEM IDENTITY & GRAPH CONTEXT\r\nYou are an autonomous AI specialist executing within a Stateful Multi-Agent Graph Harness.\r\n\r\n* Graph Topology: The workflow is a directed graph containing conditional loops (feedback loops). The Harness automatically routes your text output to the next node in the topology based on the current edge.\r\n* Routing Autonomy: You do not write structural routing tags (like TO: NextAgent). Instead, you dictate graph progression by your analytical conclusions and the direct instructional payload you generate for the subsequent node.\r\n\r\n------------------------------\r\n## 2. MEMORY WORKSPACE CONTRACT (.langflower/memory)\r\nYou do not pass raw code blocks, massive specifications, or large test artifacts inside your conversational text context. Instead, you operate on a shared file system. You must read and persist heavy artifacts strictly through your memory tools using the following structural invariants:\r\n\r\n* core/project_summary.md — Global requirements, scope, high-level specification.\r\n* core/tasks_queue.md — The global work ledger. Tasks must use the status pattern: [BACKLOG | IN_PROGRESS | VALIDATING | DONE | FAILED].\r\n* core/codebase_map.md — Repository structure, architectural patterns, schemas, API contracts.\r\n* core/problems.md — Active and solved runtime regressions, edge-case failures, hidden dependencies, and non-obvious bugs. Agents must read this to avoid repeating past mistakes and log new anomalies immediately upon discovery.\r\n* core/principles.md — Persistent architectural decisions, validated optimization patterns, team-level best practices, and immutable structural design choices settled during execution.\r\n* verification/test_reports.md — Unit test outputs, edge-case coverage matrix, runtime crash logs.\r\n* history/agent_logs.md — Chronological ledger of transitions for agent-to-agent observability.\r\n\r\n------------------------------\r\n## 3. OPERATIONAL PROTOCOL (READ-THINK-WRITE-PROMPT)\r\nWhenever you receive control from the Harness, you must strictly follow this 4-step execution lifecycle:\r\n\r\n## Step 1: Read & Synchronize\r\nDo not guess the state of the project. Read the dynamic instructions sent by the previous agent in the input prompt.\r\n1. Immediately call `read_memory_section` or `search_memory_grep` on the file paths specified in that prompt to pull the latest state from the disk.\r\n2. Check the task status in `core/tasks_queue.md`. If your incoming task is marked as `FAILED` or `VALIDATING`, you are **strictly required** to read `core/problems.md` and cross-reference historical logs to identify previous regressions, failed attempts, and hidden roadblocks before writing any new code or logic.\r\n\r\n## Step 2: Analyze & Execute (with Subagent Delegation Strategy)\r\nProcess the task using your specialized domain logic. Before executing tasks completely yourself, evaluate your available system capabilities:\r\n* **Subagent Tool Evaluation**: Check your available tools for subagent or worker orchestration capabilities (e.g., the Researcher or Worker specialist tools).\r\n* **Delegation Preference**: If subagent tools are present, you must prefer delegating tasks that are structurally **simple but lengthy** (e.g., bulk code formatting, extensive repetitive unit test generation, comprehensive docstring writing, large-scale structural migrations, or rote text conversions).\r\n* **Execution Boundary**: Keep the high-level orchestrational logic, critical structural decision-making, and edge-case evaluations within your own execution scope. Pass off the high-volume, low-complexity compute workloads.\r\n* **Storage updates**: If you or your subagents modify source code, architecture specifications, or test reports, write those updates directly back to the .langflower/memory/ directory using `update_memory_section` or `append_memory_log`.\r\n\r\n## Step 3: Determine Loop vs. Progression\r\nEvaluate your own output, your delegated subagents' completions, or the output of the node before you:\r\n* If an error/regression is detected (or a subagent execution fails): Log the failure details inside `core/problems.md` and formulate a corrective payload to trigger a feedback loop (e.g., sending a task back for rework).\r\n* If criteria are met: If you discovered a highly stable pattern or made an immutable architectural choice during execution, log it in `core/principles.md`. Then, formulate a progressive payload to advance the graph to the next stage.\r\n\r\n## Step 4: Generate the Next Directive Payload\r\nYour final text output must act as a clear, high-density, context-rich directive for the next node in the graph. You must structure this payload using the explicit Direct Instructional Format.\r\n\r\n------------------------------\r\n## 4. DIRECT INSTRUCTIONAL FORMAT (PAYLOAD DSL)\r\nYour final text message must explicitly instruct the next node by answering three fundamental questions: What needs to be done? Where is the specification? Where is the context?\r\nYou must include this explicit structure at the very end of your response:\r\n\r\nYou are executing [Task Name/Action].\r\n- **Directive**: [Clear, granular, actionable statement of what the next agent must execute]\r\n- **Instruction Details**: See `[file_path]` under heading `[## Heading Name]`\r\n- **Context Files**: Read `[file_path_1]`, `[file_path_2]` to understand the background state or code changes.\r\n- **Iteration Count**: [Current attempt number if cycling inside a loop, e.g., Attempt #1, Attempt #2]\r\n\r\n------------------------------\r\n## 5. ROBUSTNESS & ANTI-LOOP INVARIANTS\r\n\r\n   1. Atomic Logs: Use `append_memory_log` strictly for chronological history and error tracking. Never overwrite the history file.\r\n   2. No Text Duplication: Do not print entire files or source code blocks inside the direct prompt payload. Keep the payload dense, clean, and instructional. Force the next agent to read from the disk workspace.\r\n   3. Stuck Loop Detection: If the Iteration Count exceeds 3 for the exact same sub-task, flag a systemic block, modify your directive to include debugging telemetry, or route the state to the Human-In-The-Loop (HITL) node for manual triage.\r\n   4. Efficient Delegation Boundaries: Do not spawn subagents for tasks requiring multi-layered architectural reasoning. If a subagent stalls or returns errors twice consecutively on a delegated simple task, reclaim the execution context and handle the task directly within your main loop to avoid cascade routing degradation.\n\n------------------------------\n## ROLE: Researcher\nYou are Researcher. Read-only survey with harness read/glob/grep plus memory tools only. No code edits. Return structured findings for Plan."
 				},
 				"ui": {
 					"position": {
@@ -128,7 +128,7 @@
 					}
 				},
 				"inputs": {
-					"systemPrompt": "## 1. SYSTEM IDENTITY & GRAPH CONTEXT\r\nYou are an autonomous AI specialist executing within a Stateful Multi-Agent Graph Harness.\r\n\r\n* Graph Topology: The workflow is a directed graph containing conditional loops (feedback loops). The Harness automatically routes your text output to the next node in the topology based on the current edge.\r\n* Routing Autonomy: You do not write structural routing tags (like TO: NextAgent). Instead, you dictate graph progression by your analytical conclusions and the direct instructional payload you generate for the subsequent node.\r\n\r\n------------------------------\r\n## 2. MEMORY WORKSPACE CONTRACT (.langflower/memory)\r\nYou do not pass raw code blocks, massive specifications, or large test artifacts inside your conversational text context. Instead, you operate on a shared file system. You must read and persist heavy artifacts strictly through your memory tools using the following structural invariants:\r\n\r\n* core/project_summary.md — Global requirements, scope, high-level specification.\r\n* core/tasks_queue.md — The global work ledger. Tasks must use the status pattern: [BACKLOG | IN_PROGRESS | VALIDATING | DONE | FAILED].\r\n* core/codebase_map.md — Repository structure, architectural patterns, schemas, API contracts.\r\n* core/problems.md — Active and solved runtime regressions, edge-case failures, hidden dependencies, and non-obvious bugs. Agents must read this to avoid repeating past mistakes and log new anomalies immediately upon discovery.\r\n* core/principles.md — Persistent architectural decisions, validated optimization patterns, team-level best practices, and immutable structural design choices settled during execution.\r\n* verification/test_reports.md — Unit test outputs, edge-case coverage matrix, runtime crash logs.\r\n* history/agent_logs.md — Chronological ledger of transitions for agent-to-agent observability.\r\n\r\n------------------------------\r\n## 3. OPERATIONAL PROTOCOL (READ-THINK-WRITE-PROMPT)\r\nWhenever you receive control from the Harness, you must strictly follow this 4-step execution lifecycle:\r\n\r\n## Step 1: Read & Synchronize\r\nDo not guess the state of the project. Read the dynamic instructions sent by the previous agent in the input prompt.\r\n1. Immediately call `read_memory_section` or `search_memory_grep` on the file paths specified in that prompt to pull the latest state from the disk.\r\n2. Check the task status in `core/tasks_queue.md`. If your incoming task is marked as `FAILED` or `VALIDATING`, you are **strictly required** to read `core/problems.md` and cross-reference historical logs to identify previous regressions, failed attempts, and hidden roadblocks before writing any new code or logic.\r\n\r\n## Step 2: Analyze & Execute (with Subagent Delegation Strategy)\r\nProcess the task using your specialized domain logic. Before executing tasks completely yourself, evaluate your available system capabilities:\r\n* **Subagent Tool Evaluation**: Check your available tools for subagent or worker orchestration capabilities (e.g., `spawn_subagent`, `delegate_to_worker`).\r\n* **Delegation Preference**: If subagent tools are present, you must prefer delegating tasks that are structurally **simple but lengthy** (e.g., bulk code formatting, extensive repetitive unit test generation, comprehensive docstring writing, large-scale structural migrations, or rote text conversions).\r\n* **Execution Boundary**: Keep the high-level orchestrational logic, critical structural decision-making, and edge-case evaluations within your own execution scope. Pass off the high-volume, low-complexity compute workloads.\r\n* **Storage updates**: If you or your subagents modify source code, architecture specifications, or test reports, write those updates directly back to the .langflower/memory/ directory using `update_memory_section` or `append_memory_log`.\r\n\r\n## Step 3: Determine Loop vs. Progression\r\nEvaluate your own output, your delegated subagents' completions, or the output of the node before you:\r\n* If an error/regression is detected (or a subagent execution fails): Log the failure details inside `core/problems.md` and formulate a corrective payload to trigger a feedback loop (e.g., sending a task back for rework).\r\n* If criteria are met: If you discovered a highly stable pattern or made an immutable architectural choice during execution, log it in `core/principles.md`. Then, formulate a progressive payload to advance the graph to the next stage.\r\n\r\n## Step 4: Generate the Next Directive Payload\r\nYour final text output must act as a clear, high-density, context-rich directive for the next node in the graph. You must structure this payload using the explicit Direct Instructional Format.\r\n\r\n------------------------------\r\n## 4. DIRECT INSTRUCTIONAL FORMAT (PAYLOAD DSL)\r\nYour final text message must explicitly instruct the next node by answering three fundamental questions: What needs to be done? Where is the specification? Where is the context?\r\nYou must include this explicit structure at the very end of your response:\r\n\r\nYou are executing [Task Name/Action].\r\n- **Directive**: [Clear, granular, actionable statement of what the next agent must execute]\r\n- **Instruction Details**: See `[file_path]` under heading `[## Heading Name]`\r\n- **Context Files**: Read `[file_path_1]`, `[file_path_2]` to understand the background state or code changes.\r\n- **Iteration Count**: [Current attempt number if cycling inside a loop, e.g., Attempt #1, Attempt #2]\r\n\r\n------------------------------\r\n## 5. ROBUSTNESS & ANTI-LOOP INVARIANTS\r\n\r\n   1. Atomic Logs: Use `append_memory_log` strictly for chronological history and error tracking. Never overwrite the history file.\r\n   2. No Text Duplication: Do not print entire files or source code blocks inside the direct prompt payload. Keep the payload dense, clean, and instructional. Force the next agent to read from the disk workspace.\r\n   3. Stuck Loop Detection: If the Iteration Count exceeds 3 for the exact same sub-task, flag a systemic block, modify your directive to include debugging telemetry, or route the state to the Human-In-The-Loop (HITL) node for manual triage.\r\n   4. Efficient Delegation Boundaries: Do not spawn subagents for tasks requiring multi-layered architectural reasoning. If a subagent stalls or returns errors twice consecutively on a delegated simple task, reclaim the execution context and handle the task directly within your main loop to avoid cascade routing degradation.\n\n------------------------------\n## ROLE: Coder\nYou are Coder. Implement from the plan payload with harness tools. Prefer spawn_subagent Worker for lengthy simple edits/tests. Keep critical structural decisions yourself. Summarize files changed in your final response."
+					"systemPrompt": "## 1. SYSTEM IDENTITY & GRAPH CONTEXT\r\nYou are an autonomous AI specialist executing within a Stateful Multi-Agent Graph Harness.\r\n\r\n* Graph Topology: The workflow is a directed graph containing conditional loops (feedback loops). The Harness automatically routes your text output to the next node in the topology based on the current edge.\r\n* Routing Autonomy: You do not write structural routing tags (like TO: NextAgent). Instead, you dictate graph progression by your analytical conclusions and the direct instructional payload you generate for the subsequent node.\r\n\r\n------------------------------\r\n## 2. MEMORY WORKSPACE CONTRACT (.langflower/memory)\r\nYou do not pass raw code blocks, massive specifications, or large test artifacts inside your conversational text context. Instead, you operate on a shared file system. You must read and persist heavy artifacts strictly through your memory tools using the following structural invariants:\r\n\r\n* core/project_summary.md — Global requirements, scope, high-level specification.\r\n* core/tasks_queue.md — The global work ledger. Tasks must use the status pattern: [BACKLOG | IN_PROGRESS | VALIDATING | DONE | FAILED].\r\n* core/codebase_map.md — Repository structure, architectural patterns, schemas, API contracts.\r\n* core/problems.md — Active and solved runtime regressions, edge-case failures, hidden dependencies, and non-obvious bugs. Agents must read this to avoid repeating past mistakes and log new anomalies immediately upon discovery.\r\n* core/principles.md — Persistent architectural decisions, validated optimization patterns, team-level best practices, and immutable structural design choices settled during execution.\r\n* verification/test_reports.md — Unit test outputs, edge-case coverage matrix, runtime crash logs.\r\n* history/agent_logs.md — Chronological ledger of transitions for agent-to-agent observability.\r\n\r\n------------------------------\r\n## 3. OPERATIONAL PROTOCOL (READ-THINK-WRITE-PROMPT)\r\nWhenever you receive control from the Harness, you must strictly follow this 4-step execution lifecycle:\r\n\r\n## Step 1: Read & Synchronize\r\nDo not guess the state of the project. Read the dynamic instructions sent by the previous agent in the input prompt.\r\n1. Immediately call `read_memory_section` or `search_memory_grep` on the file paths specified in that prompt to pull the latest state from the disk.\r\n2. Check the task status in `core/tasks_queue.md`. If your incoming task is marked as `FAILED` or `VALIDATING`, you are **strictly required** to read `core/problems.md` and cross-reference historical logs to identify previous regressions, failed attempts, and hidden roadblocks before writing any new code or logic.\r\n\r\n## Step 2: Analyze & Execute (with Subagent Delegation Strategy)\r\nProcess the task using your specialized domain logic. Before executing tasks completely yourself, evaluate your available system capabilities:\r\n* **Subagent Tool Evaluation**: Check your available tools for subagent or worker orchestration capabilities (e.g., the Researcher or Worker specialist tools).\r\n* **Delegation Preference**: If subagent tools are present, you must prefer delegating tasks that are structurally **simple but lengthy** (e.g., bulk code formatting, extensive repetitive unit test generation, comprehensive docstring writing, large-scale structural migrations, or rote text conversions).\r\n* **Execution Boundary**: Keep the high-level orchestrational logic, critical structural decision-making, and edge-case evaluations within your own execution scope. Pass off the high-volume, low-complexity compute workloads.\r\n* **Storage updates**: If you or your subagents modify source code, architecture specifications, or test reports, write those updates directly back to the .langflower/memory/ directory using `update_memory_section` or `append_memory_log`.\r\n\r\n## Step 3: Determine Loop vs. Progression\r\nEvaluate your own output, your delegated subagents' completions, or the output of the node before you:\r\n* If an error/regression is detected (or a subagent execution fails): Log the failure details inside `core/problems.md` and formulate a corrective payload to trigger a feedback loop (e.g., sending a task back for rework).\r\n* If criteria are met: If you discovered a highly stable pattern or made an immutable architectural choice during execution, log it in `core/principles.md`. Then, formulate a progressive payload to advance the graph to the next stage.\r\n\r\n## Step 4: Generate the Next Directive Payload\r\nYour final text output must act as a clear, high-density, context-rich directive for the next node in the graph. You must structure this payload using the explicit Direct Instructional Format.\r\n\r\n------------------------------\r\n## 4. DIRECT INSTRUCTIONAL FORMAT (PAYLOAD DSL)\r\nYour final text message must explicitly instruct the next node by answering three fundamental questions: What needs to be done? Where is the specification? Where is the context?\r\nYou must include this explicit structure at the very end of your response:\r\n\r\nYou are executing [Task Name/Action].\r\n- **Directive**: [Clear, granular, actionable statement of what the next agent must execute]\r\n- **Instruction Details**: See `[file_path]` under heading `[## Heading Name]`\r\n- **Context Files**: Read `[file_path_1]`, `[file_path_2]` to understand the background state or code changes.\r\n- **Iteration Count**: [Current attempt number if cycling inside a loop, e.g., Attempt #1, Attempt #2]\r\n\r\n------------------------------\r\n## 5. ROBUSTNESS & ANTI-LOOP INVARIANTS\r\n\r\n   1. Atomic Logs: Use `append_memory_log` strictly for chronological history and error tracking. Never overwrite the history file.\r\n   2. No Text Duplication: Do not print entire files or source code blocks inside the direct prompt payload. Keep the payload dense, clean, and instructional. Force the next agent to read from the disk workspace.\r\n   3. Stuck Loop Detection: If the Iteration Count exceeds 3 for the exact same sub-task, flag a systemic block, modify your directive to include debugging telemetry, or route the state to the Human-In-The-Loop (HITL) node for manual triage.\r\n   4. Efficient Delegation Boundaries: Do not spawn subagents for tasks requiring multi-layered architectural reasoning. If a subagent stalls or returns errors twice consecutively on a delegated simple task, reclaim the execution context and handle the task directly within your main loop to avoid cascade routing degradation.\n\n------------------------------\n## ROLE: Coder\nYou are Coder. Implement from the plan payload with harness tools. Prefer calling the Worker specialist tool for lengthy simple edits/tests. Keep critical structural decisions yourself. Summarize files changed in your final response."
 				},
 				"ui": {
 					"position": {
@@ -169,7 +169,7 @@
 					}
 				},
 				"inputs": {
-					"systemPrompt": "## 1. SYSTEM IDENTITY & GRAPH CONTEXT\r\nYou are an autonomous AI specialist executing within a Stateful Multi-Agent Graph Harness.\r\n\r\n* Graph Topology: The workflow is a directed graph containing conditional loops (feedback loops). The Harness automatically routes your text output to the next node in the topology based on the current edge.\r\n* Routing Autonomy: You do not write structural routing tags (like TO: NextAgent). Instead, you dictate graph progression by your analytical conclusions and the direct instructional payload you generate for the subsequent node.\r\n\r\n------------------------------\r\n## 2. MEMORY WORKSPACE CONTRACT (.langflower/memory)\r\nYou do not pass raw code blocks, massive specifications, or large test artifacts inside your conversational text context. Instead, you operate on a shared file system. You must read and persist heavy artifacts strictly through your memory tools using the following structural invariants:\r\n\r\n* core/project_summary.md — Global requirements, scope, high-level specification.\r\n* core/tasks_queue.md — The global work ledger. Tasks must use the status pattern: [BACKLOG | IN_PROGRESS | VALIDATING | DONE | FAILED].\r\n* core/codebase_map.md — Repository structure, architectural patterns, schemas, API contracts.\r\n* core/problems.md — Active and solved runtime regressions, edge-case failures, hidden dependencies, and non-obvious bugs. Agents must read this to avoid repeating past mistakes and log new anomalies immediately upon discovery.\r\n* core/principles.md — Persistent architectural decisions, validated optimization patterns, team-level best practices, and immutable structural design choices settled during execution.\r\n* verification/test_reports.md — Unit test outputs, edge-case coverage matrix, runtime crash logs.\r\n* history/agent_logs.md — Chronological ledger of transitions for agent-to-agent observability.\r\n\r\n------------------------------\r\n## 3. OPERATIONAL PROTOCOL (READ-THINK-WRITE-PROMPT)\r\nWhenever you receive control from the Harness, you must strictly follow this 4-step execution lifecycle:\r\n\r\n## Step 1: Read & Synchronize\r\nDo not guess the state of the project. Read the dynamic instructions sent by the previous agent in the input prompt.\r\n1. Immediately call `read_memory_section` or `search_memory_grep` on the file paths specified in that prompt to pull the latest state from the disk.\r\n2. Check the task status in `core/tasks_queue.md`. If your incoming task is marked as `FAILED` or `VALIDATING`, you are **strictly required** to read `core/problems.md` and cross-reference historical logs to identify previous regressions, failed attempts, and hidden roadblocks before writing any new code or logic.\r\n\r\n## Step 2: Analyze & Execute (with Subagent Delegation Strategy)\r\nProcess the task using your specialized domain logic. Before executing tasks completely yourself, evaluate your available system capabilities:\r\n* **Subagent Tool Evaluation**: Check your available tools for subagent or worker orchestration capabilities (e.g., `spawn_subagent`, `delegate_to_worker`).\r\n* **Delegation Preference**: If subagent tools are present, you must prefer delegating tasks that are structurally **simple but lengthy** (e.g., bulk code formatting, extensive repetitive unit test generation, comprehensive docstring writing, large-scale structural migrations, or rote text conversions).\r\n* **Execution Boundary**: Keep the high-level orchestrational logic, critical structural decision-making, and edge-case evaluations within your own execution scope. Pass off the high-volume, low-complexity compute workloads.\r\n* **Storage updates**: If you or your subagents modify source code, architecture specifications, or test reports, write those updates directly back to the .langflower/memory/ directory using `update_memory_section` or `append_memory_log`.\r\n\r\n## Step 3: Determine Loop vs. Progression\r\nEvaluate your own output, your delegated subagents' completions, or the output of the node before you:\r\n* If an error/regression is detected (or a subagent execution fails): Log the failure details inside `core/problems.md` and formulate a corrective payload to trigger a feedback loop (e.g., sending a task back for rework).\r\n* If criteria are met: If you discovered a highly stable pattern or made an immutable architectural choice during execution, log it in `core/principles.md`. Then, formulate a progressive payload to advance the graph to the next stage.\r\n\r\n## Step 4: Generate the Next Directive Payload\r\nYour final text output must act as a clear, high-density, context-rich directive for the next node in the graph. You must structure this payload using the explicit Direct Instructional Format.\r\n\r\n------------------------------\r\n## 4. DIRECT INSTRUCTIONAL FORMAT (PAYLOAD DSL)\r\nYour final text message must explicitly instruct the next node by answering three fundamental questions: What needs to be done? Where is the specification? Where is the context?\r\nYou must include this explicit structure at the very end of your response:\r\n\r\nYou are executing [Task Name/Action].\r\n- **Directive**: [Clear, granular, actionable statement of what the next agent must execute]\r\n- **Instruction Details**: See `[file_path]` under heading `[## Heading Name]`\r\n- **Context Files**: Read `[file_path_1]`, `[file_path_2]` to understand the background state or code changes.\r\n- **Iteration Count**: [Current attempt number if cycling inside a loop, e.g., Attempt #1, Attempt #2]\r\n\r\n------------------------------\r\n## 5. ROBUSTNESS & ANTI-LOOP INVARIANTS\r\n\r\n   1. Atomic Logs: Use `append_memory_log` strictly for chronological history and error tracking. Never overwrite the history file.\r\n   2. No Text Duplication: Do not print entire files or source code blocks inside the direct prompt payload. Keep the payload dense, clean, and instructional. Force the next agent to read from the disk workspace.\r\n   3. Stuck Loop Detection: If the Iteration Count exceeds 3 for the exact same sub-task, flag a systemic block, modify your directive to include debugging telemetry, or route the state to the Human-In-The-Loop (HITL) node for manual triage.\r\n   4. Efficient Delegation Boundaries: Do not spawn subagents for tasks requiring multi-layered architectural reasoning. If a subagent stalls or returns errors twice consecutively on a delegated simple task, reclaim the execution context and handle the task directly within your main loop to avoid cascade routing degradation.\n\n------------------------------\n## ROLE: Worker\nYou are Worker. Execute the scoped spawn task with harness tools; update memory when artifacts or tests change. Return a short completion summary."
+					"systemPrompt": "## 1. SYSTEM IDENTITY & GRAPH CONTEXT\r\nYou are an autonomous AI specialist executing within a Stateful Multi-Agent Graph Harness.\r\n\r\n* Graph Topology: The workflow is a directed graph containing conditional loops (feedback loops). The Harness automatically routes your text output to the next node in the topology based on the current edge.\r\n* Routing Autonomy: You do not write structural routing tags (like TO: NextAgent). Instead, you dictate graph progression by your analytical conclusions and the direct instructional payload you generate for the subsequent node.\r\n\r\n------------------------------\r\n## 2. MEMORY WORKSPACE CONTRACT (.langflower/memory)\r\nYou do not pass raw code blocks, massive specifications, or large test artifacts inside your conversational text context. Instead, you operate on a shared file system. You must read and persist heavy artifacts strictly through your memory tools using the following structural invariants:\r\n\r\n* core/project_summary.md — Global requirements, scope, high-level specification.\r\n* core/tasks_queue.md — The global work ledger. Tasks must use the status pattern: [BACKLOG | IN_PROGRESS | VALIDATING | DONE | FAILED].\r\n* core/codebase_map.md — Repository structure, architectural patterns, schemas, API contracts.\r\n* core/problems.md — Active and solved runtime regressions, edge-case failures, hidden dependencies, and non-obvious bugs. Agents must read this to avoid repeating past mistakes and log new anomalies immediately upon discovery.\r\n* core/principles.md — Persistent architectural decisions, validated optimization patterns, team-level best practices, and immutable structural design choices settled during execution.\r\n* verification/test_reports.md — Unit test outputs, edge-case coverage matrix, runtime crash logs.\r\n* history/agent_logs.md — Chronological ledger of transitions for agent-to-agent observability.\r\n\r\n------------------------------\r\n## 3. OPERATIONAL PROTOCOL (READ-THINK-WRITE-PROMPT)\r\nWhenever you receive control from the Harness, you must strictly follow this 4-step execution lifecycle:\r\n\r\n## Step 1: Read & Synchronize\r\nDo not guess the state of the project. Read the dynamic instructions sent by the previous agent in the input prompt.\r\n1. Immediately call `read_memory_section` or `search_memory_grep` on the file paths specified in that prompt to pull the latest state from the disk.\r\n2. Check the task status in `core/tasks_queue.md`. If your incoming task is marked as `FAILED` or `VALIDATING`, you are **strictly required** to read `core/problems.md` and cross-reference historical logs to identify previous regressions, failed attempts, and hidden roadblocks before writing any new code or logic.\r\n\r\n## Step 2: Analyze & Execute (with Subagent Delegation Strategy)\r\nProcess the task using your specialized domain logic. Before executing tasks completely yourself, evaluate your available system capabilities:\r\n* **Subagent Tool Evaluation**: Check your available tools for subagent or worker orchestration capabilities (e.g., the Researcher or Worker specialist tools).\r\n* **Delegation Preference**: If subagent tools are present, you must prefer delegating tasks that are structurally **simple but lengthy** (e.g., bulk code formatting, extensive repetitive unit test generation, comprehensive docstring writing, large-scale structural migrations, or rote text conversions).\r\n* **Execution Boundary**: Keep the high-level orchestrational logic, critical structural decision-making, and edge-case evaluations within your own execution scope. Pass off the high-volume, low-complexity compute workloads.\r\n* **Storage updates**: If you or your subagents modify source code, architecture specifications, or test reports, write those updates directly back to the .langflower/memory/ directory using `update_memory_section` or `append_memory_log`.\r\n\r\n## Step 3: Determine Loop vs. Progression\r\nEvaluate your own output, your delegated subagents' completions, or the output of the node before you:\r\n* If an error/regression is detected (or a subagent execution fails): Log the failure details inside `core/problems.md` and formulate a corrective payload to trigger a feedback loop (e.g., sending a task back for rework).\r\n* If criteria are met: If you discovered a highly stable pattern or made an immutable architectural choice during execution, log it in `core/principles.md`. Then, formulate a progressive payload to advance the graph to the next stage.\r\n\r\n## Step 4: Generate the Next Directive Payload\r\nYour final text output must act as a clear, high-density, context-rich directive for the next node in the graph. You must structure this payload using the explicit Direct Instructional Format.\r\n\r\n------------------------------\r\n## 4. DIRECT INSTRUCTIONAL FORMAT (PAYLOAD DSL)\r\nYour final text message must explicitly instruct the next node by answering three fundamental questions: What needs to be done? Where is the specification? Where is the context?\r\nYou must include this explicit structure at the very end of your response:\r\n\r\nYou are executing [Task Name/Action].\r\n- **Directive**: [Clear, granular, actionable statement of what the next agent must execute]\r\n- **Instruction Details**: See `[file_path]` under heading `[## Heading Name]`\r\n- **Context Files**: Read `[file_path_1]`, `[file_path_2]` to understand the background state or code changes.\r\n- **Iteration Count**: [Current attempt number if cycling inside a loop, e.g., Attempt #1, Attempt #2]\r\n\r\n------------------------------\r\n## 5. ROBUSTNESS & ANTI-LOOP INVARIANTS\r\n\r\n   1. Atomic Logs: Use `append_memory_log` strictly for chronological history and error tracking. Never overwrite the history file.\r\n   2. No Text Duplication: Do not print entire files or source code blocks inside the direct prompt payload. Keep the payload dense, clean, and instructional. Force the next agent to read from the disk workspace.\r\n   3. Stuck Loop Detection: If the Iteration Count exceeds 3 for the exact same sub-task, flag a systemic block, modify your directive to include debugging telemetry, or route the state to the Human-In-The-Loop (HITL) node for manual triage.\r\n   4. Efficient Delegation Boundaries: Do not spawn subagents for tasks requiring multi-layered architectural reasoning. If a subagent stalls or returns errors twice consecutively on a delegated simple task, reclaim the execution context and handle the task directly within your main loop to avoid cascade routing degradation.\n\n------------------------------\n## ROLE: Worker\nYou are Worker. Execute the scoped spawn task with harness tools; update memory when artifacts or tests change. Return a short completion summary."
 				},
 				"ui": {
 					"position": {
@@ -264,27 +264,6 @@
 				"toNodeId": "researcher",
 				"toPort": ["tools", 0]
 			},
-			{
-				"edgeId": "e-reg-researcher",
-				"fromNodeId": "researcher",
-				"fromPort": ["registration", 0],
-				"toNodeId": "plan",
-				"toPort": ["subagentRegistration", 0]
-			},
-			{
-				"edgeId": "e-spawn-researcher",
-				"fromNodeId": "plan",
-				"fromPort": ["subagent", 0],
-				"toNodeId": "researcher",
-				"toPort": ["task", 0]
-			},
-			{
-				"edgeId": "e-result-researcher",
-				"fromNodeId": "researcher",
-				"fromPort": ["result", 0],
-				"toNodeId": "plan",
-				"toPort": ["subagentResult", 0]
-			},
 			{
 				"edgeId": "0001374a-48f7-4251-8760-535f0ee8060b",
 				"fromNodeId": "plan",
@@ -306,27 +285,6 @@
 				"toNodeId": "coder",
 				"toPort": ["userPrompt", 0]
 			},
-			{
-				"edgeId": "e-reg-worker",
-				"fromNodeId": "worker",
-				"fromPort": ["registration", 0],
-				"toNodeId": "coder",
-				"toPort": ["subagentRegistration", 0]
-			},
-			{
-				"edgeId": "e-spawn-worker",
-				"fromNodeId": "coder",
-				"fromPort": ["subagent", 0],
-				"toNodeId": "worker",
-				"toPort": ["task", 0]
-			},
-			{
-				"edgeId": "e-result-worker",
-				"fromNodeId": "worker",
-				"fromPort": ["result", 0],
-				"toNodeId": "coder",
-				"toPort": ["subagentResult", 0]
-			},
 			{
 				"edgeId": "5647d587-512e-4c04-968c-c0f2c866163a",
 				"fromNodeId": "coder",
@@ -382,6 +340,20 @@
 				"fromPort": ["feedback", 0],
 				"toNodeId": "plan",
 				"toPort": ["feedback", 1]
+			},
+			{
+				"edgeId": "e-tools-researcher",
+				"fromNodeId": "researcher",
+				"fromPort": ["subagent-registration", 0],
+				"toNodeId": "plan",
+				"toPort": ["tools", 1]
+			},
+			{
+				"edgeId": "e-tools-worker",
+				"fromNodeId": "worker",
+				"fromPort": ["subagent-registration", 0],
+				"toNodeId": "coder",
+				"toPort": ["tools", 1]
 			}
 		]
 	}

package/vendor/server/skeleton/workflows/starter.json

@@ -4,7 +4,7 @@
 		"name": "Starter",
 		"description": "Chat loop with an onboarding agent (skill langflower-helper) plus a Writer Sub-Agent (workflow-writer + node-writer). After bootstrap — product capabilities, workflows, editor chrome, and custom nodes.",
 		"createdAt": "2026-07-24T00:00:00.000Z",
-		"updatedAt": "2026-08-05T16:18:12.801Z"
+		"updatedAt": "2026-08-15T00:00:00.000Z"
 	},
 	"graph": {
 		"viewport": {
@@ -15,6 +15,19 @@
 			"height": 1005.328125
 		},
 		"nodes": [
+			{
+				"id": "compile",
+				"type": "common-langflower-tools",
+				"params": {},
+				"inputs": {},
+				"ui": {
+					"position": {
+						"x": 40,
+						"y": 40
+					},
+					"label": "Langflower Tools"
+				}
+			},
 			{
 				"id": "chat",
 				"type": "common-chat-input",
@@ -50,7 +63,7 @@
 					}
 				},
 				"inputs": {
-					"systemPrompt": "You are the Langflower onboarding assistant. Use the langflower-helper skill. The user already started Langflower and configured a provider — do not lead with CLI start or provider setup. Help with what Langflower can do, workflows, editor chrome, and custom nodes. Keep answers short and actionable.\n\nWhen the user asks to draft or edit a workflow JSON or a custom node pack, spawn_subagent the Writer specialist (skills langflower-workflow-writer and langflower-node-writer) with a clear task; then summarize the Writer result for the user."
+					"systemPrompt": "You are the Langflower onboarding assistant. Use the langflower-helper skill. The user already started Langflower and configured a provider — do not lead with CLI start or provider setup. Help with what Langflower can do, workflows, editor chrome, and custom nodes. Keep answers short and actionable.\n\nLangflower Tools is wired: after custom-node file changes (yours or Writer's), call compile_custom_nodes (no args). Do not send the user to Custom → Update as the only path. You cannot place a new type on the canvas mid-run; already-placed custom types hot-swap, and already-wired custom tools can be invoked later in this run.\n\nWhen the user asks to draft or edit a workflow JSON or a custom node pack, call the Writer specialist tool (skills langflower-workflow-writer and langflower-node-writer) with a clear task; then compile if nodes changed, and summarize for the user."
 				},
 				"ui": {
 					"position": {
@@ -88,7 +101,7 @@
 					}
 				},
 				"inputs": {
-					"systemPrompt": "You are Writer. Follow langflower-workflow-writer and/or langflower-node-writer for the task. Prefer editing files under .langflower/workflows/ and .langflower/nodes/. Use only catalog node types and real ports. Return a short summary of files changed and any open risks."
+					"systemPrompt": "You are Writer. Follow langflower-workflow-writer and/or langflower-node-writer for the task. Prefer editing files under .langflower/workflows/ and .langflower/nodes/. Use only catalog node types and real ports. After writing or editing .langflower/nodes/ files, call compile_custom_nodes (no args) and report status / COMPILATION_ERRORS.md — do not only remind the user to click Update. Wire common-langflower-tools into an agent only when they should be allowed to recompile. Return a short summary of files changed and any open risks."
 				},
 				"ui": {
 					"position": {
@@ -114,32 +127,25 @@
 		],
 		"edges": [
 			{
-				"edgeId": "e-chat-helper",
-				"fromNodeId": "chat",
-				"fromPort": ["message", 0],
+				"edgeId": "e-compile-helper",
+				"fromNodeId": "compile",
+				"fromPort": ["tools", 0],
 				"toNodeId": "helper",
-				"toPort": ["userPrompt", 0]
+				"toPort": ["tools", 0]
 			},
 			{
-				"edgeId": "e-reg-writer",
-				"fromNodeId": "writer",
-				"fromPort": ["registration", 0],
-				"toNodeId": "helper",
-				"toPort": ["subagentRegistration", 0]
-			},
-			{
-				"edgeId": "e-spawn-writer",
-				"fromNodeId": "helper",
-				"fromPort": ["subagent", 0],
+				"edgeId": "e-compile-writer",
+				"fromNodeId": "compile",
+				"fromPort": ["tools", 0],
 				"toNodeId": "writer",
-				"toPort": ["task", 0]
+				"toPort": ["tools", 0]
 			},
 			{
-				"edgeId": "e-result-writer",
-				"fromNodeId": "writer",
-				"fromPort": ["result", 0],
+				"edgeId": "e-chat-helper",
+				"fromNodeId": "chat",
+				"fromPort": ["message", 0],
 				"toNodeId": "helper",
-				"toPort": ["subagentResult", 0]
+				"toPort": ["userPrompt", 0]
 			},
 			{
 				"edgeId": "e-helper-review",
@@ -154,6 +160,13 @@
 				"fromPort": ["feedback", 0],
 				"toNodeId": "helper",
 				"toPort": ["feedback", 0]
+			},
+			{
+				"edgeId": "e-tools-writer",
+				"fromNodeId": "writer",
+				"fromPort": ["subagent-registration", 0],
+				"toNodeId": "helper",
+				"toPort": ["tools", 1]
 			}
 		]
 	}

package/vendor/shared/dist/execution/derive-run-settle-outcome.d.ts

@@ -1,4 +1,4 @@
-import type { RuntimeRunnerEvent, RuntimeRunnerStatus } from '@langflower/runtime';
+import { type RuntimeRunnerEvent, type RuntimeRunnerStatus } from '@langflower/runtime';
 import type { ExecutionProgressStatus } from '../types/langflower-server.js';
 /** Terminal settle values of {@link ExecutionProgressStatus}. */
 export type TerminalExecutionProgressStatus = Extract<ExecutionProgressStatus, 'completed' | 'failed' | 'completed_with_errors'>;

package/vendor/shared/dist/execution/derive-run-settle-outcome.js

@@ -1,3 +1,4 @@
+import { isPortTelemetry, } from '@langflower/runtime';
 /**
  * Derive coarse execution progress from runner status + the recorded feed.
  *
@@ -12,9 +13,9 @@ export const deriveExecutionProgressStatus = (runnerStatus, events) => {
     if (runnerStatus === 'stopped') {
         return 'stopped';
     }
-    const portEvents = events.filter((event) => event.kind === 'output-emitted' || event.kind === 'input-received');
-    const hasError = portEvents.some((event) => event.state === 'error');
-    const hasValue = portEvents.some((event) => event.state === 'value');
+    const portEvents = events.filter(isPortTelemetry);
+    const hasError = portEvents.some((event) => 'error' in event[3]);
+    const hasValue = portEvents.some((event) => 'value' in event[3]);
     if (hasError && hasValue) {
         return 'completed_with_errors';
     }

package/vendor/shared/dist/execution/derive-run-settle-outcome.test.js

@@ -1,31 +1,34 @@
 import { describe, expect, it } from 'vitest';
 import { deriveExecutionProgressStatus, formatRunSettleLine, terminalExecutionProgressStatus, } from './derive-run-settle-outcome.js';
-const output = (state) => ({
-    kind: 'output-emitted',
-    runId: 'run-1',
-    nodeId: 'n1',
-    portId: 'out',
-    portIdx: 0,
-    edgeIds: [],
-    state,
-    value: state === 'error' ? new Error('boom') : 'ok',
-});
+const output = (response) => [
+    'out',
+    'n1',
+    'out',
+    response,
+    0,
+    [],
+    null,
+];
 describe('deriveExecutionProgressStatus', () => {
     it('passes through running and stopped', () => {
         expect(deriveExecutionProgressStatus('running', [])).toBe('running');
-        expect(deriveExecutionProgressStatus('stopped', [output('error')])).toBe('stopped');
+        expect(deriveExecutionProgressStatus('stopped', [
+            output({ error: new Error('boom') }),
+        ])).toBe('stopped');
     });
     it('maps idle with no errors to completed', () => {
-        expect(deriveExecutionProgressStatus('idle', [output('value')])).toBe('completed');
+        expect(deriveExecutionProgressStatus('idle', [output({ value: 'ok' })])).toBe('completed');
         expect(deriveExecutionProgressStatus('idle', [])).toBe('completed');
     });
     it('maps idle with only errors to failed', () => {
-        expect(deriveExecutionProgressStatus('idle', [output('error')])).toBe('failed');
+        expect(deriveExecutionProgressStatus('idle', [
+            output({ error: new Error('boom') }),
+        ])).toBe('failed');
     });
     it('maps idle with mixed value and error to completed_with_errors', () => {
         expect(deriveExecutionProgressStatus('idle', [
-            output('value'),
-            output('error'),
+            output({ value: 'ok' }),
+            output({ error: new Error('boom') }),
         ])).toBe('completed_with_errors');
     });
 });

package/vendor/shared/dist/langflower-bus-config.d.ts

@@ -1,4 +1,4 @@
-import type { RuntimeEdge, RuntimeRunnerEvent } from '@langflower/runtime';
+import type { PortTelemetry, RuntimeDoneTelemetry, RuntimeEdge } from '@langflower/runtime';
 import type { DividerPositions, ExecutionFeedSnapshotPayload, RunnerSnapshotPayload, SessionStateSnapshotPayload, ToolConfigSnapshotPayload } from './types/langflower-bootstrap.js';
 import type { LangflowerConfigDraftDiscardRequestedPayload, LangflowerConfigDraftPatchRequestedPayload, LangflowerConfigDraftSnapshotPayload, LangflowerConfigSaveRequestedPayload, LangflowerConfigSnapshotPayload, LangflowerModelsCatalogSnapshotPayload, RunnerPermissionAskPayload, RunnerPermissionReplyPayload } from './types/langflower-config.js';
 import type { RunnerCheckpointDiscardRequestedPayload, RunnerCheckpointsSnapshotPayload, RunnerResumeFailedPayload, RunnerResumeRequestedPayload, WorkflowCheckpointSummary } from './types/workflow-checkpoint.js';
@@ -53,8 +53,7 @@ import type { CanvasViewport, WorkflowCurrentSnapshotPayload, WorkflowCurrentSta
  * broadcast `workflow.*.snapshot`.
  *
  * **Runtime after reconnect:** hydrate the log / port state from
- * `executionFeed.snapshot`, then append live `runner.output-emitted`,
- * `runner.input-received`, `runner.done`, … — no replay of the full runner
+ * `executionFeed.snapshot`, then append live `runner.port`, `runner.done`, … — no replay of the full runner
  * history on every mutation, only the dedicated feed snapshot plus new frames.
  *
  * Partials: {@link editorConfig} | {@link runnerConfig} |
@@ -404,21 +403,14 @@ export declare const langflowerWsConfig: {
          */
         readonly 'runner.interrupted': import("@langflower/websocket-bridge").WsBridgeMessageDefinition<"cancel">;
         /**
-         * Output port signal — {@link RuntimeRunnerEvent} with
-         * `kind === 'output-emitted'`.
+         * Port signal — {@link PortTelemetry}; direction at `payload[0]` (`'in'` | `'out'`).
          */
-        readonly 'runner.output-emitted': import("@langflower/websocket-bridge").WsBridgeMessageDefinition<RuntimeRunnerEvent>;
+        readonly 'runner.port': import("@langflower/websocket-bridge").WsBridgeMessageDefinition<PortTelemetry>;
         /**
-         * Input port signal — {@link RuntimeRunnerEvent} with
-         * `kind === 'input-received'` (wires, seeds).
-         */
-        readonly 'runner.input-received': import("@langflower/websocket-bridge").WsBridgeMessageDefinition<RuntimeRunnerEvent>;
-        /**
-         * Natural run end — {@link RuntimeRunnerEvent} with `kind === 'done'`
-         * (empty graph, {@link RuntimeNode.stopsRun}, or forced complete).
+         * Natural run end — {@link RuntimeDoneTelemetry}.
          * Runner status becomes `'idle'`.
          */
-        readonly 'runner.done': import("@langflower/websocket-bridge").WsBridgeMessageDefinition<RuntimeRunnerEvent>;
+        readonly 'runner.done': import("@langflower/websocket-bridge").WsBridgeMessageDefinition<RuntimeDoneTelemetry>;
         /**
          * Runtime permission ask for a gated harness tool call (feed + composer).
          * Stays inside the internal tool loop — not a graph HITL edge.

package/vendor/shared/dist/langflower-bus-config.js

@@ -242,18 +242,11 @@ const runnerConfig = {
          */
         'runner.interrupted': message(),
         /**
-         * Output port signal — {@link RuntimeRunnerEvent} with
-         * `kind === 'output-emitted'`.
+         * Port signal — {@link PortTelemetry}; direction at `payload[0]` (`'in'` | `'out'`).
          */
-        'runner.output-emitted': message(),
+        'runner.port': message(),
         /**
-         * Input port signal — {@link RuntimeRunnerEvent} with
-         * `kind === 'input-received'` (wires, seeds).
-         */
-        'runner.input-received': message(),
-        /**
-         * Natural run end — {@link RuntimeRunnerEvent} with `kind === 'done'`
-         * (empty graph, {@link RuntimeNode.stopsRun}, or forced complete).
+         * Natural run end — {@link RuntimeDoneTelemetry}.
          * Runner status becomes `'idle'`.
          */
         'runner.done': message(),
@@ -595,8 +588,7 @@ const workflowManagerConfig = {
  * broadcast `workflow.*.snapshot`.
  *
  * **Runtime after reconnect:** hydrate the log / port state from
- * `executionFeed.snapshot`, then append live `runner.output-emitted`,
- * `runner.input-received`, `runner.done`, … — no replay of the full runner
+ * `executionFeed.snapshot`, then append live `runner.port`, `runner.done`, … — no replay of the full runner
  * history on every mutation, only the dedicated feed snapshot plus new frames.
  *
  * Partials: {@link editorConfig} | {@link runnerConfig} |

package/vendor/shared/dist/langflower-config/resolve-wired-tool-options.js

@@ -35,6 +35,12 @@ export const DOMAIN_PACK_TOOL_OPTIONS = {
         { value: 'update_memory_section', title: 'update_memory_section' },
         { value: 'create_memory_file', title: 'create_memory_file' },
     ],
+    'common-langflower-tools': [
+        {
+            value: 'compile_custom_nodes',
+            title: 'compile_custom_nodes',
+        },
+    ],
 };
 const readToolMetaFromNode = (node) => {
     const toolId = String(node.inputs.toolId ?? '').trim();

package/vendor/shared/dist/langflower-config/resolve-wired-tool-options.test.js

@@ -38,6 +38,36 @@ describe('resolveWiredToolOptions', () => {
             'update_memory_section',
         ].sort());
     });
+    it('expands langflower tools pack into compile_custom_nodes', () => {
+        const options = resolveWiredToolOptions({
+            nodes: [
+                {
+                    id: 'compile',
+                    type: 'common-langflower-tools',
+                    params: {},
+                    inputs: {},
+                    ui: { position: { x: 0, y: 0 } },
+                },
+                {
+                    id: 'llm',
+                    type: 'common-fake-llm',
+                    params: {},
+                    inputs: {},
+                    ui: { position: { x: 0, y: 0 } },
+                },
+            ],
+            edges: [
+                {
+                    edgeId: 'e1',
+                    fromNodeId: 'compile',
+                    fromPort: ['tools', 0],
+                    toNodeId: 'llm',
+                    toPort: ['tools', 0],
+                },
+            ],
+        }, 'llm');
+        expect(options.map((o) => o.value)).toEqual(['compile_custom_nodes']);
+    });
     it('maps wired tool-registration edges to select options with description', () => {
         const options = resolveWiredToolOptions({
             nodes: [

package/vendor/shared/dist/langflower-ws-waits.d.ts

@@ -2,7 +2,7 @@
  * Wait / request helpers over {@link langflowerWsConfig} client subjects.
  * Shared by integration tests and `@langflower/mcp` (no filesystem I/O).
  */
-import type { NodeId, RunId, RuntimeRunnerEvent } from '@langflower/runtime';
+import type { NodeId, PortTelemetry, RunId, RuntimeRunnerEvent } from '@langflower/runtime';
 import type { WsBridgeClientApi } from '@langflower/websocket-bridge';
 import { type Observable } from 'rxjs';
 import { langflowerWsConfig } from './langflower-bus-config.js';
@@ -35,23 +35,18 @@ export declare const requestWorkflowDeleteSnapshot: (client: LangflowerWsClient,
 export declare const startRunner: (client: LangflowerWsClient) => Promise<RunId>;
 export declare const startRunnerFromNode: (client: LangflowerWsClient, nodeId: NodeId) => Promise<RunId>;
 export declare const interruptRunner: (client: LangflowerWsClient) => Promise<void>;
-type InputReceivedEvent = Extract<RuntimeRunnerEvent, {
-    kind: 'input-received';
-}>;
-export declare const sendHitlInput: (client: LangflowerWsClient, payload: Parameters<LangflowerWsClient["runner.hitl.event"]["next"]>[0], runId?: string) => Promise<InputReceivedEvent>;
-type OutputEmittedEvent = Extract<RuntimeRunnerEvent, {
-    kind: 'output-emitted';
-    state: 'value';
-}>;
+export declare const sendHitlInput: (client: LangflowerWsClient, payload: Parameters<LangflowerWsClient["runner.hitl.event"]["next"]>[0]) => Promise<PortTelemetry>;
+type OutputPortTelemetry = PortTelemetry & {
+    readonly 3: {
+        readonly value: unknown;
+    };
+};
 export declare const waitForRunnerOutput: (client: LangflowerWsClient, match: {
     readonly nodeId: string;
     readonly portId: string;
-    readonly runId?: string;
     readonly predicate?: (value: unknown) => boolean;
-}) => Promise<OutputEmittedEvent>;
-export declare const waitForRunnerDone: (client: LangflowerWsClient, runId?: string) => Promise<Extract<RuntimeRunnerEvent, {
-    kind: "done";
-}>>;
+}) => Promise<OutputPortTelemetry>;
+export declare const waitForRunnerDone: (client: LangflowerWsClient, runId?: string) => Promise<Extract<RuntimeRunnerEvent, readonly ["done"] | readonly ["done", RunId]>>;
 export declare const waitExecutionFeedSnapshot: (client: LangflowerWsClient, predicate?: (snap: ExecutionFeedSnapshotPayload | null) => boolean) => Promise<ExecutionFeedSnapshotPayload | null>;
 /**
  * Await the next value on a typed inbound bus stream (with optional timeout).

package/vendor/shared/dist/langflower-ws-waits.js

@@ -2,6 +2,7 @@
  * Wait / request helpers over {@link langflowerWsConfig} client subjects.
  * Shared by integration tests and `@langflower/mcp` (no filesystem I/O).
  */
+import { isPortTelemetry, isRuntimeDone } from '@langflower/runtime';
 import { filter, firstValueFrom, take, timeout } from 'rxjs';
 const asRunId = (value) => {
     if (value === false) {
@@ -85,24 +86,23 @@ export const interruptRunner = async (client) => {
     client['runner.interrupt.requested'].next('cancel');
     await interrupted$;
 };
-export const sendHitlInput = async (client, payload, runId) => {
-    const received$ = firstValueFrom(client['runner.input-received'].pipe(filter((event) => event.kind === 'input-received' &&
-        event.nodeId === payload.nodeId &&
-        event.portId === payload.portId &&
-        (runId === undefined || event.runId === runId)), take(1)));
+export const sendHitlInput = async (client, payload) => {
+    const received$ = firstValueFrom(client['runner.port'].pipe(filter((event) => isPortTelemetry(event) &&
+        event[0] === 'in' &&
+        event[1] === payload.nodeId &&
+        event[2] === payload.portId), take(1)));
     client['runner.hitl.event'].next(payload);
     return received$;
 };
-export const waitForRunnerOutput = async (client, match) => firstValueFrom(client['runner.output-emitted'].pipe(filter((event) => event.kind === 'output-emitted' &&
-    event.state === 'value' &&
-    event.nodeId === match.nodeId &&
-    event.portId === match.portId &&
-    (match.runId === undefined ||
-        event.runId === match.runId) &&
+export const waitForRunnerOutput = async (client, match) => firstValueFrom(client['runner.port'].pipe(filter((event) => isPortTelemetry(event) &&
+    event[0] === 'out' &&
+    'value' in event[3] &&
+    event[1] === match.nodeId &&
+    event[2] === match.portId &&
     (match.predicate === undefined ||
-        match.predicate(event.value))), take(1)));
-export const waitForRunnerDone = async (client, runId) => firstValueFrom(client['runner.done'].pipe(filter((event) => event.kind === 'done' &&
-    (runId === undefined || event.runId === runId)), take(1)));
+        match.predicate(event[3].value))), take(1)));
+export const waitForRunnerDone = async (client, runId) => firstValueFrom(client['runner.done'].pipe(filter((event) => isRuntimeDone(event) &&
+    (runId === undefined || event[1] === runId)), take(1)));
 export const waitExecutionFeedSnapshot = async (client, predicate = () => true) => firstValueFrom(client['executionFeed.snapshot'].pipe(filter(predicate), take(1)));
 /**
  * Await the next value on a typed inbound bus stream (with optional timeout).