langflower 0.0.3 → 0.0.5

package/vendor/server/skeleton/workflows/kb-create.json

@@ -1,4 +1,5 @@
 {
+	"$schema": "../schemas/workflow.schema.json",
 	"metadata": {
 		"name": "Memory create",
 		"description": "Index-then-serial Memory create: Orchestrator builds a work queue via glob/read, then spawns Explorer→Composer one unit at a time into `.langflower/memory/`. common-review blocks exit until the bar is met. Configure a provider before running.",
@@ -20,7 +21,10 @@
 				"params": {},
 				"inputs": {},
 				"ui": {
-					"position": { "x": 40, "y": 280 },
+					"position": {
+						"x": 40,
+						"y": 280
+					},
 					"label": "Brief"
 				}
 			},
@@ -30,7 +34,10 @@
 				"params": {},
 				"inputs": {},
 				"ui": {
-					"position": { "x": 40, "y": 40 },
+					"position": {
+						"x": 40,
+						"y": 40
+					},
 					"label": "Memory Tools"
 				}
 			},
@@ -56,7 +63,10 @@
 					"systemPrompt": "You are the Orchestrator for building a DETAILED project memory map (project wiki) under `.langflower/memory/`.\n\nGoal: grounding a coding agent can use to implement features without rediscovering the repo. A thin whole-repo skim is NOT enough.\n\n## Required memory layout (all under `.langflower/memory/`)\n\n1) `core/overview.md` — purpose, primary user, ships vs not, how to run\n2) `core/layout.md` — directory / package map with ownership\n3) `core/architecture.md` — runtime flow, boundaries, key ADRs / invariants\n4) `core/build-test.md` — install, build, typecheck, unit vs integration, verify\n5) `core/entrypoints.md` — CLI / server / UI / MCP paths and ports\n6) `core/conventions.md` — coding rules agents must follow\n7) `modules/<area>.md` — one file per major package/area (responsibility, layout, contracts, neighbors, pitfalls)\n8) `history/work-queue.md` — indexed work units (Pending / In progress / Done)\n9) `history/build-log.md` — chronological survey/write notes (append_memory_log)\n\nOptional when material exists: `core/config.md`, `core/workflows-skills.md`.\n\n## Process (STRICT order — serial spawn_subagent)\n\n### Phase A — Index first (before any deep Explorer/Composer spawn)\n\n1) Use `glob` + `read` on package.json workspaces, top-level dirs, README*, AGENTS.md, docs/** (or equivalents). List every workspace package / major area and each mandatory `core/*` topic.\n2) Persist `.langflower/memory/history/work-queue.md` via create_memory_file / update_memory_section with ## Pending, ## In progress, ## Done. Each Pending item: id, path(s) to survey, target memory file (`modules/<area>.md` or `core/<name>.md`), status.\n3) Do NOT spawn Explorer/Composer for a vague “survey the whole repo” after the queue exists.\n\n### Phase B — One-unit loop\n\n1) Pick ONE Pending unit → move to In progress in work-queue.md.\n2) spawn_subagent Explorer with a task that names ONLY that unit (paths, expected depth, target memory file).\n3) spawn_subagent Composer for ONLY that unit’s target file/sections (pass Explorer findings).\n4) Mark the unit Done; append_memory_log on history/build-log.md.\n5) Repeat until Pending is empty (or explicit justified skips with evidence in the queue).\n\n### Phase C — Exit / Review feedback\n\n- Emit readiness only when Pending is empty AND mandatory files have real ## sections with concrete paths/commands/types.\n- Module pages MUST cover every indexed package/area from the queue.\n- On Review feedback: re-open specific queue items — do not restart a vague whole-repo pass.\n- Cite evidence (paths + section headings) in the readiness report."
 				},
 				"ui": {
-					"position": { "x": 300, "y": 240 },
+					"position": {
+						"x": 300,
+						"y": 240
+					},
 					"label": "Orchestrator"
 				}
 			},
@@ -78,7 +88,10 @@
 					"systemPrompt": "You are Explorer. You survey ONE scoped unit named in the spawn task — not the whole monorepo.\n\n## Scope\n\nThe Orchestrator task names: unit id, path(s)/package to read, expected depth, and target memory file. Stay inside that scope. Use glob / read / grep aggressively inside those paths. Cross-links to neighbors only when needed for contracts.\n\nIf the task is ambiguous, return a short gap list for Orchestrator — do NOT expand into a full-repo skim.\n\n## Finding report (return this structure for the assigned unit)\n\n1. Unit id + paths surveyed\n2. Ownership / responsibility (one paragraph)\n3. Layout (key folders + what lives where)\n4. Public contracts / exports / entrypoints (with paths)\n5. Neighbors (how it talks to other packages)\n6. Pitfalls / STATUS honesty for this unit\n7. Evidence paths (files actually read)\n8. Suggested ## sections for the target `.langflower/memory/` file\n\nRules: Prefer facts with file paths. Do not invent APIs. Check get_memory_tree / read_memory_section only to avoid duplicating what is already deep enough for THIS unit."
 				},
 				"ui": {
-					"position": { "x": 620, "y": 40 },
+					"position": {
+						"x": 620,
+						"y": 40
+					},
 					"label": "Explorer"
 				}
 			},
@@ -108,7 +121,10 @@
 					"systemPrompt": "You are Composer. Materialize Explorer findings for ONE assigned queue unit into `.langflower/memory/`.\n\n## Scope\n\nThe Orchestrator task names the target file (e.g. `core/overview.md` or `modules/<area>.md`) and may include Explorer findings. Create/update THAT target only — do not rewrite the entire corpus in one turn.\n\nSection sets by target type:\n- `core/overview.md` — ## Purpose, ## User, ## Scope, ## How to run\n- `core/layout.md` — ## Tree, ## Package ownership\n- `core/architecture.md` — ## Runtime flow, ## Boundaries, ## Key ADRs\n- `core/build-test.md` — ## Install, ## Build, ## Unit tests, ## Integration, ## Verify\n- `core/entrypoints.md` — ## CLI, ## Server, ## UI, ## Ports\n- `core/conventions.md` — ## TypeScript, ## Errors, ## Modules, ## Reactivity/agents (as applicable)\n- `modules/<area>.md` — ## Responsibility, ## Layout, ## Contracts, ## Neighbors, ## Pitfalls\n- `history/build-log.md` / `history/work-queue.md` — only when Orchestrator assigns those units\n\n## Quality bar\n\n- Concrete paths, commands, type/package names — no vague filler.\n- Prefer memory tools: create_memory_file, update_memory_section, append_memory_log, get_memory_tree, read_memory_section, search_memory_grep. Harness write/edit/create on `.langflower/memory/…` is OK.\n- Ground every claim in Explorer evidence + your own reads. Do not invent APIs.\n- If the target exists, update sections — do not leave stubs.\n\nReturn: files/sections written + whether this queue unit is complete + any residual gaps for Orchestrator."
 				},
 				"ui": {
-					"position": { "x": 620, "y": 280 },
+					"position": {
+						"x": 620,
+						"y": 280
+					},
 					"label": "Composer"
 				}
 			},
@@ -120,7 +136,10 @@
 					"value": "Accept ONLY when `.langflower/memory/` is a coding-agent-ready project map built via an indexed work queue. ALL must hold:\n1) `history/work-queue.md` exists with ## Pending empty (or explicit justified skips with evidence); Done covers every indexed major package/area plus mandatory core topics.\n2) Mandatory files exist: core/overview.md, core/layout.md, core/architecture.md, core/build-test.md, core/entrypoints.md, core/conventions.md, modules/*.md for each indexed package/area, history/build-log.md, history/work-queue.md.\n3) Each core/module file has real ## sections with concrete paths/commands — not placeholders or one-paragraph fluff.\n4) Module pages state responsibility, layout, contracts, neighbors, pitfalls with file evidence matching the queue.\n5) get_memory_tree shows the structure; search_memory_grep finds build/test commands and package names; spot-check read_memory_section on work-queue Done items and at least two modules.\n6) Reject if content looks like one shallow whole-repo pass instead of queued units, or if Pending still has work.\n7) Readiness report is honest.\nVerify with memory tools before accept."
 				},
 				"ui": {
-					"position": { "x": 300, "y": 520 },
+					"position": {
+						"x": 300,
+						"y": 520
+					},
 					"label": "Ready criteria"
 				}
 			},
@@ -136,7 +155,10 @@
 					"systemPrompt": "You are the Memory readiness Review (Validator) for a CODING-AGENT project map / project wiki.\nCall tool accept or feedback — never reply in plain text only.\n\nHard reject:\n- Missing or non-empty ## Pending in history/work-queue.md (unless skips are justified with evidence)\n- Thin corpora: single overview, missing modules/*, missing build-test/entrypoints/conventions\n- Vague prose without paths/commands\n- Evidence of one shallow whole-repo skim instead of serial queued units\n\nVerify with get_memory_tree, search_memory_grep, and read_memory_section: spot-check history/work-queue.md, core/*, and at least two modules/* against the task criteria before accept.\nCall accept only when the map is detailed enough to start real coding work. Call feedback with concrete missing queue items / files / sections otherwise."
 				},
 				"ui": {
-					"position": { "x": 920, "y": 280 },
+					"position": {
+						"x": 920,
+						"y": 280
+					},
 					"label": "Memory Ready Review"
 				}
 			},
@@ -146,7 +168,10 @@
 				"params": {},
 				"inputs": {},
 				"ui": {
-					"position": { "x": 1200, "y": 280 },
+					"position": {
+						"x": 1200,
+						"y": 280
+					},
 					"label": "Finish"
 				}
 			}

package/vendor/server/skeleton/workflows/kb-navigate.json

@@ -1,4 +1,5 @@
 {
+	"$schema": "../schemas/workflow.schema.json",
 	"metadata": {
 		"name": "Memory navigate",
 		"description": "Chat loop: Navigator LLM + Searcher Sub-Agent answer questions grounded in `.langflower/memory/` via common-memory-tools. Configure a provider; build memory with kb-create (Memory create) first when empty.",
@@ -20,7 +21,10 @@
 				"params": {},
 				"inputs": {},
 				"ui": {
-					"position": { "x": 40, "y": 240 },
+					"position": {
+						"x": 40,
+						"y": 240
+					},
 					"label": "Ask"
 				}
 			},
@@ -30,7 +34,10 @@
 				"params": {},
 				"inputs": {},
 				"ui": {
-					"position": { "x": 40, "y": 40 },
+					"position": {
+						"x": 40,
+						"y": 40
+					},
 					"label": "Memory Tools"
 				}
 			},
@@ -49,7 +56,10 @@
 					"systemPrompt": "You answer questions about this project grounded in project memory.\n\nConvention: markdown under `.langflower/memory/` (built by the kb-create / Memory create workflow). Memory is also readable with harness file tools on `.langflower/memory/…`.\n\nBefore answering, use get_memory_tree / search_memory_grep / read_memory_section (yourself or via spawn_subagent Searcher). Prefer memory hits over guessing. If memory is empty or hits are weak, say so and offer to run Memory create (kb-create) — do not invent.\n\nWhen HITL feedback arrives, revise the answer — do not ignore it. Keep answers short and cite memory file paths / headings when available."
 				},
 				"ui": {
-					"position": { "x": 300, "y": 200 },
+					"position": {
+						"x": 300,
+						"y": 200
+					},
 					"label": "Navigator"
 				}
 			},
@@ -72,7 +82,10 @@
 					"systemPrompt": "You are Searcher. Use get_memory_tree, search_memory_grep, and read_memory_section for the task query. Return top hits with file paths and heading context. If memory is missing or empty, say so clearly. Do not invent content."
 				},
 				"ui": {
-					"position": { "x": 580, "y": 40 },
+					"position": {
+						"x": 580,
+						"y": 40
+					},
 					"label": "Searcher"
 				}
 			},
@@ -82,7 +95,10 @@
 				"params": {},
 				"inputs": {},
 				"ui": {
-					"position": { "x": 580, "y": 280 },
+					"position": {
+						"x": 580,
+						"y": 280
+					},
 					"label": "Review"
 				}
 			}

package/vendor/server/skeleton/workflows/node-writer.json

@@ -1,4 +1,5 @@
 {
+	"$schema": "../schemas/workflow.schema.json",
 	"metadata": {
 		"name": "Node writer",
 		"description": "Chat loop with an agent that has skill langflower-node-writer — draft defineNode / defineReactiveNode packs under .langflower/nodes.",
@@ -20,7 +21,10 @@
 				"params": {},
 				"inputs": {},
 				"ui": {
-					"position": { "x": 40, "y": 220 },
+					"position": {
+						"x": 40,
+						"y": 220
+					},
 					"label": "Ask"
 				}
 			},
@@ -39,7 +43,10 @@
 					"systemPrompt": "You help the user write Langflower custom nodes. Follow the langflower-node-writer skill and ADR-030 pack layout. Prefer defineNode; use defineReactiveNode only when exclusive branches are required."
 				},
 				"ui": {
-					"position": { "x": 320, "y": 180 },
+					"position": {
+						"x": 320,
+						"y": 180
+					},
 					"label": "Node writer"
 				}
 			},
@@ -49,7 +56,10 @@
 				"params": {},
 				"inputs": {},
 				"ui": {
-					"position": { "x": 620, "y": 220 },
+					"position": {
+						"x": 620,
+						"y": 220
+					},
 					"label": "Review"
 				}
 			}

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

@@ -1,17 +1,18 @@
 {
+	"$schema": "../schemas/workflow.schema.json",
 	"metadata": {
 		"name": "Simple coder",
-		"description": "Plan → coder → HITL loop. Product coding smoke spine (successor intent to basic-coder). Configure a provider before running.",
+		"description": "Plan (+ Researcher) → coder (+ Worker) with HITL loops and shared Memory Tools. Product coding smoke spine (successor intent to basic-coder). Configure a provider before running.",
 		"createdAt": "2026-07-24T00:00:00.000Z",
-		"updatedAt": "2026-07-24T00:00:00.000Z"
+		"updatedAt": "2026-08-05T16:14:41.418Z"
 	},
 	"graph": {
 		"viewport": {
-			"x": -117.39587175846478,
-			"y": 91.64430031530618,
-			"scale": 0.5197751407121728,
-			"width": 756.1875,
-			"height": 1009.0625
+			"x": -87.54590555669785,
+			"y": -12.974709392232825,
+			"scale": 0.7169036842821539,
+			"width": 719.0625,
+			"height": 1005.328125
 		},
 		"nodes": [
 			{
@@ -27,6 +28,19 @@
 					"label": "Goal"
 				}
 			},
+			{
+				"id": "memory-tools",
+				"type": "common-memory-tools",
+				"params": {},
+				"inputs": {},
+				"ui": {
+					"position": {
+						"x": 40,
+						"y": 40
+					},
+					"label": "Memory Tools"
+				}
+			},
 			{
 				"id": "plan",
 				"type": "common-openai-llm",
@@ -36,15 +50,58 @@
 					"model": "",
 					"maxIterations": 8
 				},
-				"inputs": {},
+				"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."
+				},
 				"ui": {
 					"position": {
 						"x": 320,
-						"y": 120
+						"y": 220
 					},
 					"label": "Plan"
 				}
 			},
+			{
+				"id": "researcher",
+				"type": "common-sub-agent",
+				"params": {
+					"name": "Researcher",
+					"description": "Read-only survey specialist for Plan — repo/memory exploration without code edits",
+					"skillIds": [],
+					"rolePreset": "explorer",
+					"providerId": "",
+					"model": "",
+					"maxIterations": 12,
+					"contextSize": 32768,
+					"compactOnError": false,
+					"toolPermissions": {
+						"read": "allow",
+						"glob": "deny",
+						"grep": "deny",
+						"edit": "deny",
+						"write": "ask",
+						"create": "ask",
+						"delete": "deny",
+						"bash": "deny",
+						"get_memory_tree": "allow",
+						"read_memory_section": "allow",
+						"search_memory_grep": "allow",
+						"append_memory_log": "allow",
+						"update_memory_section": "allow",
+						"create_memory_file": "allow"
+					}
+				},
+				"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."
+				},
+				"ui": {
+					"position": {
+						"x": 320,
+						"y": 960
+					},
+					"label": "Researcher"
+				}
+			},
 			{
 				"id": "coder",
 				"type": "common-openai-llm",
@@ -52,19 +109,76 @@
 					"rolePreset": "coder",
 					"providerId": "",
 					"model": "",
-					"maxIterations": 8
+					"maxIterations": 8,
+					"toolPermissions": {
+						"read": "allow",
+						"glob": "allow",
+						"grep": "allow",
+						"edit": "allow",
+						"write": "allow",
+						"create": "allow",
+						"delete": "ask",
+						"bash": "ask",
+						"get_memory_tree": "allow",
+						"read_memory_section": "allow",
+						"search_memory_grep": "allow",
+						"append_memory_log": "allow",
+						"update_memory_section": "allow",
+						"create_memory_file": "allow"
+					}
 				},
 				"inputs": {
-					"systemPrompt": "You receive a Plan agent summary as the user prompt. Implement the plan with harness tools. Prefer minimal edits. 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., `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."
 				},
 				"ui": {
 					"position": {
 						"x": 1080,
-						"y": 160
+						"y": 200
 					},
 					"label": "Coder"
 				}
 			},
+			{
+				"id": "worker",
+				"type": "common-sub-agent",
+				"params": {
+					"name": "Worker",
+					"description": "Scoped implementer for Coder — lengthy simple edits, tests, and rote changes",
+					"skillIds": [],
+					"rolePreset": "custom",
+					"providerId": "",
+					"model": "",
+					"maxIterations": 12,
+					"contextSize": 32768,
+					"compactOnError": false,
+					"toolPermissions": {
+						"read": "allow",
+						"glob": "allow",
+						"grep": "allow",
+						"edit": "allow",
+						"write": "allow",
+						"create": "allow",
+						"delete": "ask",
+						"bash": "ask",
+						"get_memory_tree": "allow",
+						"read_memory_section": "allow",
+						"search_memory_grep": "allow",
+						"append_memory_log": "allow",
+						"update_memory_section": "allow",
+						"create_memory_file": "allow"
+					}
+				},
+				"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."
+				},
+				"ui": {
+					"position": {
+						"x": 1080,
+						"y": 960
+					},
+					"label": "Worker"
+				}
+			},
 			{
 				"id": "f67ee3a6-c8ea-4bad-bb7d-d0c1c3e90521",
 				"type": "common-hitl-review-gate",
@@ -72,8 +186,8 @@
 				"inputs": {},
 				"ui": {
 					"position": {
-						"x": 620,
-						"y": 780
+						"x": 640,
+						"y": 760
 					}
 				}
 			},
@@ -84,8 +198,8 @@
 				"inputs": {},
 				"ui": {
 					"position": {
-						"x": 1094.219576990285,
-						"y": 782.6495614795315
+						"x": 1380,
+						"y": 760
 					}
 				}
 			},
@@ -96,8 +210,34 @@
 				"inputs": {},
 				"ui": {
 					"position": {
-						"x": 1462.316578408799,
-						"y": 804.9460874158642
+						"x": 1940,
+						"y": 800
+					}
+				}
+			},
+			{
+				"id": "d80650bf-8250-488c-9773-b2f0622517b8",
+				"type": "common-router",
+				"params": {},
+				"inputs": {},
+				"ui": {
+					"position": {
+						"x": 740,
+						"y": 40
+					}
+				}
+			},
+			{
+				"id": "db0c5a0e-0ebd-49ef-bed9-c42edec92a48",
+				"type": "common-hitl-review-gate",
+				"params": {},
+				"inputs": {},
+				"ui": {
+					"position": {
+						"x": 1640,
+						"y": 800,
+						"width": 188.875,
+						"height": 141.0625
 					}
 				}
 			}
@@ -110,6 +250,41 @@
 				"toNodeId": "plan",
 				"toPort": ["userPrompt", 0]
 			},
+			{
+				"edgeId": "e-mem-plan",
+				"fromNodeId": "memory-tools",
+				"fromPort": ["tools", 0],
+				"toNodeId": "plan",
+				"toPort": ["tools", 0]
+			},
+			{
+				"edgeId": "e-mem-researcher",
+				"fromNodeId": "memory-tools",
+				"fromPort": ["tools", 0],
+				"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",
@@ -131,6 +306,27 @@
 				"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",
@@ -146,11 +342,46 @@
 				"toPort": ["feedback", 0]
 			},
 			{
-				"edgeId": "fe17cdd0-c337-4ea5-bc83-be960e3532f1",
+				"edgeId": "9078315a-1b02-4ce9-a976-2326a317bf2a",
+				"fromNodeId": "memory-tools",
+				"fromPort": ["tools", 0],
+				"toNodeId": "d80650bf-8250-488c-9773-b2f0622517b8",
+				"toPort": ["ch", 0]
+			},
+			{
+				"edgeId": "a1619a9f-c0b4-4eab-a9db-ff36e5a45961",
+				"fromNodeId": "d80650bf-8250-488c-9773-b2f0622517b8",
+				"fromPort": ["ch", 0],
+				"toNodeId": "coder",
+				"toPort": ["tools", 0]
+			},
+			{
+				"edgeId": "59638f55-bf1f-4345-b711-87c9bef04639",
+				"fromNodeId": "d80650bf-8250-488c-9773-b2f0622517b8",
+				"fromPort": ["ch", 0],
+				"toNodeId": "worker",
+				"toPort": ["tools", 0]
+			},
+			{
+				"edgeId": "6561ab66-3218-4870-a5af-bffc1b0f1f67",
 				"fromNodeId": "dcf00a52-7d55-4242-8dac-3896414e5d88",
 				"fromPort": ["response", 0],
+				"toNodeId": "db0c5a0e-0ebd-49ef-bed9-c42edec92a48",
+				"toPort": ["result", 0]
+			},
+			{
+				"edgeId": "a24ad4d0-134c-4f5a-b6b3-0751e04d29d6",
+				"fromNodeId": "db0c5a0e-0ebd-49ef-bed9-c42edec92a48",
+				"fromPort": ["response", 0],
 				"toNodeId": "f9df4410-fa4a-459f-8d89-603f9fb29198",
 				"toPort": ["value", 0]
+			},
+			{
+				"edgeId": "3b7f3889-3bd2-4e50-85fa-0aa7fe8dd771",
+				"fromNodeId": "db0c5a0e-0ebd-49ef-bed9-c42edec92a48",
+				"fromPort": ["feedback", 0],
+				"toNodeId": "plan",
+				"toPort": ["feedback", 1]
 			}
 		]
 	}