langflower 0.0.4 → 0.0.6

package/vendor/server/dist/session/settings-draft-session.js

@@ -0,0 +1,82 @@
+import { configToDraft, mergeDraftPatch, providerConnectionKey, redactDraftSecrets, sameDraft, } from '@langflower/shared/langflower.js';
+export const emptySettingsDraftStore = () => ({
+    project: undefined,
+    global: undefined,
+});
+export const idleConnectionsForDraft = (draft) => Object.fromEntries(draft.providers.map((_, index) => [
+    providerConnectionKey(index),
+    { state: 'idle' },
+]));
+/**
+ * Initial connection map after seeding from disk: rows with a Base URL start
+ * as `checking` so the UI does not show the empty-URL hint until a probe runs.
+ */
+const initialConnectionsForDraft = (draft) => Object.fromEntries(draft.providers.map((row, index) => [
+    providerConnectionKey(index),
+    row.baseURL.trim().length > 0
+        ? { state: 'checking' }
+        : { state: 'idle' },
+]));
+export const seedScopeDraft = (layerConfig) => {
+    const baseline = configToDraft(layerConfig);
+    return {
+        draft: baseline,
+        baseline,
+        connections: initialConnectionsForDraft(baseline),
+    };
+};
+/** Indexes of draft rows that should be probed (non-empty Base URL). */
+export const providerIndexesWithBaseUrl = (draft) => draft.providers.flatMap((row, index) => row.baseURL.trim().length > 0 ? [index] : []);
+export const buildDraftSnapshot = (scope, state) => ({
+    scope,
+    draft: redactDraftSecrets(state.draft),
+    baseline: redactDraftSecrets(state.baseline),
+    dirty: !sameDraft(redactDraftSecrets(state.draft), redactDraftSecrets(state.baseline)) || state.draft.providers.some((row) => row.apiKey.trim().length > 0),
+    connections: state.connections,
+});
+export const applyDraftPatch = (previous, incoming) => {
+    const merged = mergeDraftPatch(previous.draft, incoming);
+    const probeIndexes = [];
+    const max = Math.max(previous.draft.providers.length, merged.providers.length);
+    for (let index = 0; index < max; index++) {
+        const before = previous.draft.providers[index];
+        const after = merged.providers[index];
+        if (after === undefined) {
+            continue;
+        }
+        const urlChanged = (before?.baseURL ?? '') !== after.baseURL;
+        const keyChanged = (before?.apiKey ?? '') !== after.apiKey;
+        if (urlChanged || keyChanged) {
+            probeIndexes.push(index);
+        }
+    }
+    const connections = {};
+    for (let index = 0; index < merged.providers.length; index++) {
+        const key = providerConnectionKey(index);
+        if (probeIndexes.includes(index)) {
+            const baseURL = merged.providers[index].baseURL.trim();
+            connections[key] =
+                baseURL.length === 0
+                    ? { state: 'idle' }
+                    : { state: 'checking' };
+        }
+        else {
+            connections[key] = previous.connections[key] ?? { state: 'idle' };
+        }
+    }
+    return {
+        next: {
+            draft: merged,
+            baseline: previous.baseline,
+            connections,
+        },
+        probeIndexes: probeIndexes.filter((index) => merged.providers[index].baseURL.trim().length > 0),
+    };
+};
+export const setConnectionStatus = (state, index, status) => ({
+    ...state,
+    connections: {
+        ...state.connections,
+        [providerConnectionKey(index)]: status,
+    },
+});

package/vendor/server/skeleton/schemas/langflower-config.schema.json

@@ -18,6 +18,10 @@
 			"type": "string",
 			"description": "Optional default model id (provider/model or bare id)."
 		},
+		"serverLogs": {
+			"type": "boolean",
+			"description": "Bridge diagnostic JSONL logging under `.langflower/logs/`. Omit to inherit; true enables; false disables."
+		},
 		"provider": {
 			"type": "object",
 			"additionalProperties": {

package/vendor/server/skeleton/skills/langflower-helper/SKILL.md

@@ -71,12 +71,15 @@ do not say coding pipelines “don’t exist” or are unavailable.
   provider configured, they are seeded on first-run → load → composer **Start**.
 - **Can:** Second `langflower start` on an existing `.langflower/` **reuses**
   it as-is (no wipe).
-- **Can:** Configure providers via `.langflower/langflower.jsonc` (prefer
-  `{env:VAR}`). Bootstrap never invents API keys.
+- **Can:** Configure providers via **Settings** (Global opens on first connect
+  when none are configured) or `.langflower/langflower.jsonc` (prefer
+  `{env:VAR}`). Bootstrap never invents API keys. Simple nodes / Fake LLM work
+  without a provider; a real OpenAI-compatible provider is required for live
+  model runs and seeded coding samples.
 - **Cannot:** Claim bootstrap invents secrets, or that a polished
-  **named-path** empty-provider fail-closed error is already shipped — tell
-  users to edit `langflower.jsonc`; prefer fail over hang, without inventing
-  a finished error UX.
+  **named-path** empty-provider fail-closed error on run is already shipped —
+  tell users to add a provider in Settings or `langflower.jsonc`; prefer fail
+  over hang, without inventing a finished run-error UX.
 
 ### 3. Skeleton and samples
 
@@ -95,9 +98,12 @@ do not say coding pipelines “don’t exist” or are unavailable.
 ### 4. Providers and Settings
 
 - **Can:** Gear opens **Settings** in the **right aside**, swapping feed /
-  inspector; canvas stays. Project and Global scopes; merge **project >
-  global**; Save applies without a full app reload. Keys are write-only;
-  prefer `{env:VAR}`.
+  inspector; canvas stays. Open/close/scope are server-driven. Project and
+  Global scopes; merge **project > global**; Save applies without a full app
+  reload. Keys are write-only; prefer `{env:VAR}`.
+- **Can:** With no providers configured, connect opens **Global Settings** with
+  onboarding copy (add OpenAI-compatible provider; Fake LLM / simple nodes
+  still work).
 - **Cannot:** Treat Settings as the selected-node inspector (ports/params).
 - **Cannot:** Reveal a saved API key in the UI.
 
@@ -126,6 +132,7 @@ do not say coding pipelines “don’t exist” or are unavailable.
 | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `starter`      | Onboarding chat + this skill + Writer Sub-Agent (`langflower-workflow-writer` + `langflower-node-writer`) — default open after seed                                                                                                                                                                |
 | Skeleton stubs | `simple-coder`, `advanced-coder`, `kb-create`, `kb-navigate`, … seeded on first-run; with provider → Start                                                                                                                                                                                         |
+| `simple-coder` | Plan⇄HITL→Coder⇄HITL→Finish smoke spine + `common-memory-tools` on Plan/Coder/Researcher/Worker; Researcher Sub-Agent under Plan, Worker under Coder — **not** full multi-loop `coding-agent`                                                                                                      |
 | `kb-create`    | Memory / project wiki create: Orchestrator **indexes** the repo with `glob`/`read`, persists `history/work-queue.md`, then **serially** spawns Explorer → Composer **one unit at a time**; `common-memory-tools` writes `core/*` + `modules/*`; Review rejects non-empty Pending or thin overviews |
 | `kb-navigate`  | Memory navigate: Navigator + Searcher + memory tree/grep/section tools; HITL Review Gate for follow-ups                                                                                                                                                                                            |
 | `basic-coder`  | Basic coding harness (Plan⇄HITL→Coder⇄HITL→Finish) — not a toy, **not** full multi-loop `coding-agent`                                                                                                                                                                                             |
@@ -213,9 +220,14 @@ When the user asks to “create a project wiki”, “build a knowledge base”,
   `tsc` / IDE types act as compile-time validators before Custom → **Update**.
   Packs under `.langflower/nodes/<pack>/`; user runs `npm install` in the pack.
   See `instructions.md` and `nodes/my-nodes/README.md`.
+  Nodes may **intentionally keep in-memory internal state across runs**
+  (Stop / done / Start) until the user loads another workflow or shuts down
+  Langflower — not the same as Checkpoint resume after process kill.
 - **Cannot:** Plain JS as the authoring path, Go, Python, or other languages.
   Server auto-install. Sandboxed arbitrary user-node execution as shipped.
   Custom-pack compiler as product-Implementable.
+  Claim that every node always resets on Stop, or that in-memory node state
+  survives process restart without Checkpoints.
 
 ### 12. Status vocabulary
 

package/vendor/server/skeleton/skills/langflower-helper/architecture.md

@@ -49,6 +49,11 @@ Project product data for Langflower lives under **`.langflower/`**.
 - Nodes and edges run on a **reactive runtime**: ports are live streams. A node
   may receive and emit **at any time** while the run is alive — not a single
   batch “call node → return once”.
+- Canvas node instances stay alive across **Stop / done / Start** while the
+  same workflow is loaded. Authors may **intentionally** keep in-memory
+  internal state across runs until the user **loads another workflow** or
+  **shuts down Langflower**. That is not durable Checkpoint resume after
+  process restart.
 - **HITL loops** (Review Gate, feedback ports, composer Start/Send) are normal
   **internal waiting state of nodes**, not a separate product “interrupt the
   engine” mechanism.

package/vendor/server/skeleton/skills/langflower-helper/layout.md

@@ -10,27 +10,28 @@ Facts for UI chrome and on-disk paths. Prefer this file over guessing.
   custom packs after disk changes.
 - **Center** — canvas (nodes, edges, selection).
 - **Right aside** — mutually exclusive modes: **feed** | **inspector** |
-  **Settings**. Opening Settings (gear) swaps out feed/inspector; canvas stays.
+  **Settings**. Opening Settings (gear or empty-provider onboarding) swaps out
+  feed/inspector; canvas stays. Settings open/close is server-driven.
 - **Composer (bottom)** — **Start** / Hard **Stop** / soft **Pause**; HITL
   input and actions; `permission.ask` Allow/Deny while a run needs them.
 
 ## Where can I…?
 
-| Goal                                   | Where                                                                                                                     |
-| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
-| Change provider / API key              | Gear → **Settings** (right aside), or edit `.langflower/langflower.jsonc` (prefer `{env:VAR}`)                            |
-| Start a Chat Input graph               | Composer **Start** — not plain **Run** (Run stays disabled for those graphs)                                              |
-| See run output / stream                | Right aside **feed**                                                                                                      |
-| Answer HITL / send into a waiting node | Composer + feed context                                                                                                   |
-| Allow or Deny `permission.ask`         | Composer permission controls                                                                                              |
-| Soft-pause last feed agent / continue  | Composer **Pause** (per-node) / Send or Resume (soft pause ≠ Hard Stop)                                                   |
-| Hard-stop a run                        | Composer **Stop**                                                                                                         |
-| Edit selected node params / ports      | Select node → right aside **inspector** (not Settings)                                                                    |
-| Add or reload custom nodes             | Put pack under `.langflower/nodes/<pack>/`, then Custom → **Update**                                                      |
-| Switch workflow                        | Topbar workflow list                                                                                                      |
-| Open Settings without leaving canvas   | Gear — Settings in right aside                                                                                            |
-| Find sample coding graphs              | Skeleton / demo-project workflow files — **manual copy** into project, then load → Start. No Sample workflows catalog UI. |
-| Project instructions for agents        | `.langflower/instructions.md`                                                                                             |
+| Goal                                   | Where                                                                                                                                  |
+| -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
+| Change provider / API key              | Gear → **Settings** (right aside; Global auto-opens when none configured), or edit `.langflower/langflower.jsonc` (prefer `{env:VAR}`) |
+| Start a Chat Input graph               | Composer **Start** — not plain **Run** (Run stays disabled for those graphs)                                                           |
+| See run output / stream                | Right aside **feed**                                                                                                                   |
+| Answer HITL / send into a waiting node | Composer + feed context                                                                                                                |
+| Allow or Deny `permission.ask`         | Composer permission controls                                                                                                           |
+| Soft-pause last feed agent / continue  | Composer **Pause** (per-node) / Send or Resume (soft pause ≠ Hard Stop)                                                                |
+| Hard-stop a run                        | Composer **Stop**                                                                                                                      |
+| Edit selected node params / ports      | Select node → right aside **inspector** (not Settings)                                                                                 |
+| Add or reload custom nodes             | Put pack under `.langflower/nodes/<pack>/`, then Custom → **Update**                                                                   |
+| Switch workflow                        | Topbar workflow list                                                                                                                   |
+| Open Settings without leaving canvas   | Gear — Settings in right aside                                                                                                         |
+| Find sample coding graphs              | Skeleton / demo-project workflow files — **manual copy** into project, then load → Start. No Sample workflows catalog UI.              |
+| Project instructions for agents        | `.langflower/instructions.md`                                                                                                          |
 
 ## On-disk `.langflower/` map
 
@@ -42,6 +43,7 @@ Facts for UI chrome and on-disk paths. Prefer this file over guessing.
 | `nodes/`           | Custom node packs (e.g. `my-nodes/`)                                                          |
 | `instructions.md`  | Project-level agent instructions                                                              |
 | `runs/`            | Run artifacts / checkpoints when created                                                      |
+| `logs/`            | Server bridge diagnostic JSONL logs when the server runs                                      |
 
 ## Out of chrome
 

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

@@ -2,17 +2,17 @@
 	"$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": [
 			{
@@ -28,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",
@@ -37,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",
@@ -53,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",
@@ -73,8 +186,8 @@
 				"inputs": {},
 				"ui": {
 					"position": {
-						"x": 620,
-						"y": 780
+						"x": 640,
+						"y": 760
 					}
 				}
 			},
@@ -85,8 +198,8 @@
 				"inputs": {},
 				"ui": {
 					"position": {
-						"x": 1094.219576990285,
-						"y": 782.6495614795315
+						"x": 1380,
+						"y": 760
 					}
 				}
 			},
@@ -97,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
 					}
 				}
 			}
@@ -111,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",
@@ -132,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",
@@ -147,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]
 			}
 		]
 	}