@synergenius/flow-weaver-pack-weaver 0.9.138 → 0.9.142

package/dist/ui/profile-editor.js

@@ -217,6 +217,8 @@ var OP_VALIDATE = "validate";
 var OP_TSC_CHECK = "tsc_check";
 var OP_RUN_TESTS = "run_tests";
 var OP_TASK_CREATE = "task_create";
+var OP_REMEMBER = "remember";
+var OP_RECALL = "recall";
 
 // src/bot/capability-registry.ts
 var CAP_CORE = {
@@ -266,13 +268,31 @@ Use run_shell for running tests (npx vitest), validation (flow-weaver validate),
 };
 var CAP_TASK_MGMT = {
   name: "task-mgmt",
-  description: "Create and manage swarm subtasks for parallel execution.",
+  description: "Create and manage swarm subtasks for parallel execution, with decomposition and review nudges.",
   tools: [OP_TASK_CREATE],
-  prompt: `## Task Management
-- task_create: Create swarm subtasks for parallel execution. args: { title, description, complexity, subtasks[] }
-- task_list, task_get, task_update: Query and update existing tasks
+  prompt: `## Task Management & Decomposition
 
-Use task_create to decompose complex work into smaller, independent subtasks that other bots can execute in parallel.`
+- task_create: Create swarm subtasks. args: { title, description, complexity, subtasks[], dependsOn[], assignedProfile? }
+
+### Decomposition
+When you encounter a broad objective (multi-file, multi-concern), decompose into subtasks:
+- If the task is bigger than a single file change, create subtasks instead of doing it all yourself.
+- Minimize dependencies between subtasks to maximize parallel execution.
+- Set complexity per subtask: trivial | simple | moderate | complex.
+- Use dependsOn to express blocking relationships (e.g., setup before code, code before tests).
+
+### Review Task Creation
+After creating or modifying multiple files, create a review task:
+- title: "Review: [what was changed]"
+- description: List the files modified and what to check
+- assignedProfile: "reviewer"
+- complexity: "simple"
+Skip review for trivial single-file tasks.
+
+### Dependency Guidelines
+- BAD: A \u2192 B \u2192 C \u2192 D (serial, slow)
+- GOOD: A \u2192 [B + C + D] (A blocks all, but B/C/D run in parallel)
+Structure as: setup \u2192 independent implementations \u2192 integration/testing.`
 };
 var CAP_FW_GRAMMAR = {
   name: "fw-grammar",
@@ -350,17 +370,41 @@ Note: compile, validate, modify, diff, diagram, and describe operations are avai
 };
 var CAP_CODE_REVIEW = {
   name: "code-review",
-  description: "Code review guidelines, quality checklist, and security review patterns.",
-  prompt: `## Code Review
+  description: "Comprehensive code review with correctness, security, style, testing, and performance checks.",
+  tools: [OP_READ_FILE, OP_PATCH_FILE, OP_RUN_SHELL],
+  prompt: `## Code Review Checklist
+
+### 1. Correctness
+- Does the code do what the task asked?
+- Edge cases handled (empty input, null, invalid types)?
+- Error paths covered (try/catch, validation)?
+- Return types match function signature?
 
-When reviewing code, check for:
-1. Correctness: Does the code do what the task asked?
-2. Security: No hardcoded secrets, no injection vulnerabilities, no exposed APIs
-3. Style: Consistent with project conventions, proper naming, no dead code
-4. Testing: Are there tests? Do they cover edge cases?
-5. Performance: No unnecessary loops, no blocking calls in async code
+### 2. Security
+- NO hardcoded API keys, passwords, or tokens (use env vars)
+- NO shell: true in child_process (command injection risk)
+- NO eval() or Function() with untrusted input
+- User input validated and sanitized before use
+- File paths validated (no ../ traversal)
 
-Report concerns with specific file:line references and suggested fixes.`
+### 3. Style
+- Naming is clear and consistent with project conventions
+- No dead code (unused variables, unreachable branches)
+- No debug statements left in (console.log, debugger)
+- Imports organized, no duplicates
+
+### 4. Testing
+- Unit tests exist for new/changed functions
+- Tests cover happy path AND edge cases
+- Error cases have tests
+- Code coverage adequate (aim for 80%+ of changed code)
+
+### 5. Performance
+- No O(n\xB2) loops where O(n) is possible
+- No blocking I/O in async code
+- No memory leaks (listeners removed, timers cleared)
+
+Report findings as: FILE:LINE | SEVERITY (critical/high/medium/low) | ISSUE \u2192 Fix suggestion`
 };
 var CAP_WEB = {
   name: "web",
@@ -377,6 +421,123 @@ var CAP_CONTEXT = {
 Use list_files to understand the project structure before making changes.
 The context bundle (when available) provides a snapshot of the workspace.`
 };
+var CAP_VERIFICATION = {
+  name: "verification",
+  description: "Post-write verification: run tsc and tests to catch errors before delivery.",
+  tools: [OP_RUN_SHELL],
+  prompt: `## Verification
+
+After writing or patching code, ALWAYS verify your work:
+1. Run \`npx tsc --noEmit\` in the project root to catch TypeScript errors
+2. If package.json has a "test" script, run \`npm test\` to validate functionality
+3. If verification fails, read the errors, fix the code, and re-verify
+
+Include verification as explicit steps in your plan. Verification is NOT optional.
+Do NOT deliver code that hasn't been verified.`
+};
+var CAP_CROSS_FILE_CHECK = {
+  name: "cross-file-check",
+  description: "Verify imports, exports, module paths, and cross-file dependencies.",
+  tools: [OP_READ_FILE, OP_LIST_FILES, OP_RUN_SHELL],
+  prompt: `## Cross-File Dependency Checks
+
+When modifying code that affects multiple files:
+1. If you rename an export, grep for all imports of it and update them
+2. Verify relative import paths resolve correctly (../types vs ./types)
+3. Check for circular dependencies (A imports B imports A)
+4. If you change a function signature, update all callers
+5. Use \`run_shell\` with grep to search: grep -r "functionName" src/
+
+Do NOT move or rename exports without verifying all dependents.`
+};
+var CAP_PROJECT_SETUP = {
+  name: "project-setup",
+  description: "Initialize new projects with correct structure, config, and dependencies.",
+  tools: [OP_WRITE_FILE, OP_RUN_SHELL],
+  prompt: `## Project Setup
+
+When initializing a project:
+1. Create package.json with name, type: "module", main, scripts (build, test)
+2. Create tsconfig.json with strict: true, module: "esnext", target: "ES2020"
+3. Create standard directories: src/, tests/
+4. Install dependencies with run_shell: npm install <deps>
+5. Create .gitignore excluding node_modules/, dist/
+6. Verify setup: run tsc --noEmit to ensure TypeScript compiles`
+};
+var CAP_SECURITY = {
+  name: "security",
+  description: "Audit code for vulnerabilities, secrets, and security best practices.",
+  tools: [OP_READ_FILE, OP_LIST_FILES, OP_RUN_SHELL],
+  prompt: `## Security Audit
+
+Check for:
+1. **Secrets**: NO hardcoded API keys, passwords, tokens. Use env vars.
+   grep -r "password\\|secret\\|apiKey\\|token" src/ to find leaks.
+2. **Injection**: NO string concatenation in SQL. NO shell: true in child_process. NO eval().
+3. **Dependencies**: Run npm audit to check for known CVEs.
+4. **File paths**: Validate paths to prevent ../ traversal attacks.
+5. **Data handling**: Validate user input (type, length, format). Sanitize before logging.
+
+Report findings with severity: critical | high | medium | low.`
+};
+var CAP_DECOMPOSITION = {
+  name: "decomposition",
+  description: "Break complex objectives into subtask DAGs with dependencies for parallel execution.",
+  tools: [OP_TASK_CREATE],
+  prompt: `## Task Decomposition
+
+When given a large objective, break it into smaller subtasks:
+1. Identify all work items (files, features, tests)
+2. Group by dependency: what must happen first?
+3. Create subtasks with task_create, each focused on one responsibility
+4. Set dependencies with dependsOn to model blocking relationships
+5. Minimize dependencies to maximize parallel execution
+6. Estimate complexity per subtask: trivial | simple | moderate | complex
+
+Example: "Implement auth module"
+- Task A: Extract shared auth types (simple)
+- Task B: Rewrite login endpoint (moderate, depends on A)
+- Task C: Add login tests (moderate, depends on B)
+- Task D: Update auth docs (simple, independent \u2014 runs in parallel with B)
+
+Assign profiles: code tasks \u2192 developer, review tasks \u2192 reviewer, infra \u2192 ops.`
+};
+var CAP_ROUTING = {
+  name: "routing",
+  description: "Route tasks to appropriate bot profiles based on capabilities and complexity.",
+  tools: [OP_TASK_CREATE],
+  prompt: `## Task Routing
+
+When creating subtasks, assign the right profile:
+- Code writing, file creation, bug fixes \u2192 developer profile
+- Code review, quality checks \u2192 reviewer profile
+- Shell commands, project setup, infrastructure \u2192 ops profile
+- Leave assignedProfile empty for auto-triage when unsure
+
+Match complexity to profile capabilities:
+- trivial/simple tasks: any profile (prefer cheapest)
+- moderate tasks: specialist profiles
+- complex tasks: profiles with full capability sets`
+};
+var CAP_MEMORY = {
+  name: "memory",
+  description: "Remember and recall project conventions for continuity across sessions.",
+  tools: [OP_REMEMBER, OP_RECALL],
+  prompt: `## Project Memory
+
+Persist project conventions for future sessions:
+- remember: Save a convention. args: { key: "naming", value: "kebab-case for files" }
+- recall: Load all saved conventions. args: {} \u2014 returns project memory.
+
+What to remember:
+- Naming conventions (file names, variable names)
+- Architecture decisions (Result pattern, Zod for validation)
+- Test patterns (where tests go, what framework)
+- Common dependencies and their usage
+
+Before planning, recall project memory to follow established patterns.
+When you discover a new convention, remember it for future bots.`
+};
 var BUILT_IN_CAPABILITIES = [
   CAP_CORE,
   CAP_FILE_OPS,
@@ -388,7 +549,15 @@ var BUILT_IN_CAPABILITIES = [
   CAP_FW_CLI,
   CAP_CODE_REVIEW,
   CAP_WEB,
-  CAP_CONTEXT
+  CAP_CONTEXT,
+  // Swarm improvement capabilities
+  CAP_VERIFICATION,
+  CAP_CROSS_FILE_CHECK,
+  CAP_PROJECT_SETUP,
+  CAP_SECURITY,
+  CAP_DECOMPOSITION,
+  CAP_ROUTING,
+  CAP_MEMORY
 ];
 var capabilityMap = new Map(
   BUILT_IN_CAPABILITIES.map((c) => [c.name, c])

package/dist/ui/swarm-dashboard.js

@@ -556,6 +556,7 @@ function useStreamTimeline(events, isDone) {
     const entries = [];
     const nodeEntryIndex = /* @__PURE__ */ new Map();
     const nodeStarts = /* @__PURE__ */ new Map();
+    const completedNodes = /* @__PURE__ */ new Set();
     let idCounter = 0;
     for (const event of events) {
       const d = event.data ?? {};
@@ -572,6 +573,11 @@ function useStreamTimeline(events, isDone) {
         case "node-start": {
           const nodeId = d.nodeId;
           if (nodeId) nodeStarts.set(nodeId, event.timestamp);
+          const existingStartIdx = nodeEntryIndex.get(nodeId);
+          if (existingStartIdx != null && entries[existingStartIdx]?.type === "node-started") {
+            break;
+          }
+          completedNodes.delete(nodeId);
           const idx = entries.length;
           nodeEntryIndex.set(nodeId, idx);
           entries.push({
@@ -587,54 +593,79 @@ function useStreamTimeline(events, isDone) {
         }
         case "node-complete": {
           const nodeId = d.nodeId;
+          if (completedNodes.has(nodeId)) break;
           const startTs = nodeStarts.get(nodeId);
           const duration = d.durationMs ?? (startTs ? event.timestamp - startTs : void 0);
           if (nodeId) nodeStarts.delete(nodeId);
-          const rawOutputs = d.outputs;
-          const completed = {
-            id: `s-${idCounter++}`,
-            timestamp: new Date(startTs ?? event.timestamp),
-            type: "node-completed",
-            nodeId,
-            label: d.label ?? d.nodeType ?? nodeId ?? "Node",
-            duration,
-            color: d.color,
-            icon: d.icon,
-            outputs: rawOutputs && rawOutputs.length > 0 ? rawOutputs : void 0
-          };
+          completedNodes.add(nodeId);
           const existingIdx = nodeEntryIndex.get(nodeId);
           if (existingIdx != null && entries[existingIdx]) {
-            entries[existingIdx] = completed;
+            const rawOutputs = d.outputs;
+            entries[existingIdx] = {
+              id: entries[existingIdx].id,
+              timestamp: new Date(startTs ?? event.timestamp),
+              type: "node-completed",
+              nodeId,
+              label: d.label ?? d.nodeType ?? nodeId ?? "Node",
+              duration,
+              color: d.color,
+              icon: d.icon,
+              outputs: rawOutputs && rawOutputs.length > 0 ? rawOutputs : void 0
+            };
             nodeEntryIndex.delete(nodeId);
           } else {
-            entries.push(completed);
+            const rawOutputs = d.outputs;
+            entries.push({
+              id: `s-${idCounter++}`,
+              timestamp: new Date(startTs ?? event.timestamp),
+              type: "node-completed",
+              nodeId,
+              label: d.label ?? d.nodeType ?? nodeId ?? "Node",
+              duration,
+              color: d.color,
+              icon: d.icon,
+              outputs: rawOutputs && rawOutputs.length > 0 ? rawOutputs : void 0
+            });
           }
           break;
         }
         case "node-error": {
           const nodeId = d.nodeId;
+          if (completedNodes.has(nodeId)) break;
           const startTs = nodeStarts.get(nodeId);
           const duration = d.durationMs ?? (startTs ? event.timestamp - startTs : void 0);
           if (nodeId) nodeStarts.delete(nodeId);
-          const rawOutputs = d.outputs;
-          const failed = {
-            id: `s-${idCounter++}`,
-            timestamp: new Date(startTs ?? event.timestamp),
-            type: "node-failed",
-            nodeId,
-            label: d.label ?? d.nodeType ?? nodeId ?? "Node",
-            detail: d.error,
-            duration,
-            color: d.color,
-            icon: d.icon,
-            outputs: rawOutputs && rawOutputs.length > 0 ? rawOutputs : void 0
-          };
+          completedNodes.add(nodeId);
           const existingIdx = nodeEntryIndex.get(nodeId);
           if (existingIdx != null && entries[existingIdx]) {
-            entries[existingIdx] = failed;
+            const rawOutputs = d.outputs;
+            entries[existingIdx] = {
+              id: entries[existingIdx].id,
+              timestamp: new Date(startTs ?? event.timestamp),
+              type: "node-failed",
+              nodeId,
+              label: d.label ?? d.nodeType ?? nodeId ?? "Node",
+              detail: d.error,
+              duration,
+              color: d.color,
+              icon: d.icon,
+              outputs: rawOutputs && rawOutputs.length > 0 ? rawOutputs : void 0
+            };
             nodeEntryIndex.delete(nodeId);
           } else {
-            entries.push(failed);
+            const rawOutputs = d.outputs;
+            entries.push({
+              id: `s-${idCounter++}`,
+              timestamp: new Date(startTs ?? event.timestamp),
+              type: "node-failed",
+              nodeId,
+              label: d.label ?? d.nodeType ?? nodeId ?? "Node",
+              detail: d.error,
+              duration,
+              color: d.color,
+              icon: d.icon,
+              outputs: rawOutputs && rawOutputs.length > 0 ? rawOutputs : void 0
+            });
           }
           break;
         }
@@ -2672,6 +2703,8 @@ var OP_VALIDATE = "validate";
 var OP_TSC_CHECK = "tsc_check";
 var OP_RUN_TESTS = "run_tests";
 var OP_TASK_CREATE = "task_create";
+var OP_REMEMBER = "remember";
+var OP_RECALL = "recall";
 
 // src/bot/capability-registry.ts
 var CAP_CORE = {
@@ -2721,13 +2754,31 @@ Use run_shell for running tests (npx vitest), validation (flow-weaver validate),
 };
 var CAP_TASK_MGMT = {
   name: "task-mgmt",
-  description: "Create and manage swarm subtasks for parallel execution.",
+  description: "Create and manage swarm subtasks for parallel execution, with decomposition and review nudges.",
   tools: [OP_TASK_CREATE],
-  prompt: `## Task Management
-- task_create: Create swarm subtasks for parallel execution. args: { title, description, complexity, subtasks[] }
-- task_list, task_get, task_update: Query and update existing tasks
+  prompt: `## Task Management & Decomposition
+
+- task_create: Create swarm subtasks. args: { title, description, complexity, subtasks[], dependsOn[], assignedProfile? }
 
-Use task_create to decompose complex work into smaller, independent subtasks that other bots can execute in parallel.`
+### Decomposition
+When you encounter a broad objective (multi-file, multi-concern), decompose into subtasks:
+- If the task is bigger than a single file change, create subtasks instead of doing it all yourself.
+- Minimize dependencies between subtasks to maximize parallel execution.
+- Set complexity per subtask: trivial | simple | moderate | complex.
+- Use dependsOn to express blocking relationships (e.g., setup before code, code before tests).
+
+### Review Task Creation
+After creating or modifying multiple files, create a review task:
+- title: "Review: [what was changed]"
+- description: List the files modified and what to check
+- assignedProfile: "reviewer"
+- complexity: "simple"
+Skip review for trivial single-file tasks.
+
+### Dependency Guidelines
+- BAD: A \u2192 B \u2192 C \u2192 D (serial, slow)
+- GOOD: A \u2192 [B + C + D] (A blocks all, but B/C/D run in parallel)
+Structure as: setup \u2192 independent implementations \u2192 integration/testing.`
 };
 var CAP_FW_GRAMMAR = {
   name: "fw-grammar",
@@ -2805,17 +2856,41 @@ Note: compile, validate, modify, diff, diagram, and describe operations are avai
 };
 var CAP_CODE_REVIEW = {
   name: "code-review",
-  description: "Code review guidelines, quality checklist, and security review patterns.",
-  prompt: `## Code Review
+  description: "Comprehensive code review with correctness, security, style, testing, and performance checks.",
+  tools: [OP_READ_FILE, OP_PATCH_FILE, OP_RUN_SHELL],
+  prompt: `## Code Review Checklist
+
+### 1. Correctness
+- Does the code do what the task asked?
+- Edge cases handled (empty input, null, invalid types)?
+- Error paths covered (try/catch, validation)?
+- Return types match function signature?
 
-When reviewing code, check for:
-1. Correctness: Does the code do what the task asked?
-2. Security: No hardcoded secrets, no injection vulnerabilities, no exposed APIs
-3. Style: Consistent with project conventions, proper naming, no dead code
-4. Testing: Are there tests? Do they cover edge cases?
-5. Performance: No unnecessary loops, no blocking calls in async code
+### 2. Security
+- NO hardcoded API keys, passwords, or tokens (use env vars)
+- NO shell: true in child_process (command injection risk)
+- NO eval() or Function() with untrusted input
+- User input validated and sanitized before use
+- File paths validated (no ../ traversal)
 
-Report concerns with specific file:line references and suggested fixes.`
+### 3. Style
+- Naming is clear and consistent with project conventions
+- No dead code (unused variables, unreachable branches)
+- No debug statements left in (console.log, debugger)
+- Imports organized, no duplicates
+
+### 4. Testing
+- Unit tests exist for new/changed functions
+- Tests cover happy path AND edge cases
+- Error cases have tests
+- Code coverage adequate (aim for 80%+ of changed code)
+
+### 5. Performance
+- No O(n\xB2) loops where O(n) is possible
+- No blocking I/O in async code
+- No memory leaks (listeners removed, timers cleared)
+
+Report findings as: FILE:LINE | SEVERITY (critical/high/medium/low) | ISSUE \u2192 Fix suggestion`
 };
 var CAP_WEB = {
   name: "web",
@@ -2832,6 +2907,123 @@ var CAP_CONTEXT = {
 Use list_files to understand the project structure before making changes.
 The context bundle (when available) provides a snapshot of the workspace.`
 };
+var CAP_VERIFICATION = {
+  name: "verification",
+  description: "Post-write verification: run tsc and tests to catch errors before delivery.",
+  tools: [OP_RUN_SHELL],
+  prompt: `## Verification
+
+After writing or patching code, ALWAYS verify your work:
+1. Run \`npx tsc --noEmit\` in the project root to catch TypeScript errors
+2. If package.json has a "test" script, run \`npm test\` to validate functionality
+3. If verification fails, read the errors, fix the code, and re-verify
+
+Include verification as explicit steps in your plan. Verification is NOT optional.
+Do NOT deliver code that hasn't been verified.`
+};
+var CAP_CROSS_FILE_CHECK = {
+  name: "cross-file-check",
+  description: "Verify imports, exports, module paths, and cross-file dependencies.",
+  tools: [OP_READ_FILE, OP_LIST_FILES, OP_RUN_SHELL],
+  prompt: `## Cross-File Dependency Checks
+
+When modifying code that affects multiple files:
+1. If you rename an export, grep for all imports of it and update them
+2. Verify relative import paths resolve correctly (../types vs ./types)
+3. Check for circular dependencies (A imports B imports A)
+4. If you change a function signature, update all callers
+5. Use \`run_shell\` with grep to search: grep -r "functionName" src/
+
+Do NOT move or rename exports without verifying all dependents.`
+};
+var CAP_PROJECT_SETUP = {
+  name: "project-setup",
+  description: "Initialize new projects with correct structure, config, and dependencies.",
+  tools: [OP_WRITE_FILE, OP_RUN_SHELL],
+  prompt: `## Project Setup
+
+When initializing a project:
+1. Create package.json with name, type: "module", main, scripts (build, test)
+2. Create tsconfig.json with strict: true, module: "esnext", target: "ES2020"
+3. Create standard directories: src/, tests/
+4. Install dependencies with run_shell: npm install <deps>
+5. Create .gitignore excluding node_modules/, dist/
+6. Verify setup: run tsc --noEmit to ensure TypeScript compiles`
+};
+var CAP_SECURITY = {
+  name: "security",
+  description: "Audit code for vulnerabilities, secrets, and security best practices.",
+  tools: [OP_READ_FILE, OP_LIST_FILES, OP_RUN_SHELL],
+  prompt: `## Security Audit
+
+Check for:
+1. **Secrets**: NO hardcoded API keys, passwords, tokens. Use env vars.
+   grep -r "password\\|secret\\|apiKey\\|token" src/ to find leaks.
+2. **Injection**: NO string concatenation in SQL. NO shell: true in child_process. NO eval().
+3. **Dependencies**: Run npm audit to check for known CVEs.
+4. **File paths**: Validate paths to prevent ../ traversal attacks.
+5. **Data handling**: Validate user input (type, length, format). Sanitize before logging.
+
+Report findings with severity: critical | high | medium | low.`
+};
+var CAP_DECOMPOSITION = {
+  name: "decomposition",
+  description: "Break complex objectives into subtask DAGs with dependencies for parallel execution.",
+  tools: [OP_TASK_CREATE],
+  prompt: `## Task Decomposition
+
+When given a large objective, break it into smaller subtasks:
+1. Identify all work items (files, features, tests)
+2. Group by dependency: what must happen first?
+3. Create subtasks with task_create, each focused on one responsibility
+4. Set dependencies with dependsOn to model blocking relationships
+5. Minimize dependencies to maximize parallel execution
+6. Estimate complexity per subtask: trivial | simple | moderate | complex
+
+Example: "Implement auth module"
+- Task A: Extract shared auth types (simple)
+- Task B: Rewrite login endpoint (moderate, depends on A)
+- Task C: Add login tests (moderate, depends on B)
+- Task D: Update auth docs (simple, independent \u2014 runs in parallel with B)
+
+Assign profiles: code tasks \u2192 developer, review tasks \u2192 reviewer, infra \u2192 ops.`
+};
+var CAP_ROUTING = {
+  name: "routing",
+  description: "Route tasks to appropriate bot profiles based on capabilities and complexity.",
+  tools: [OP_TASK_CREATE],
+  prompt: `## Task Routing
+
+When creating subtasks, assign the right profile:
+- Code writing, file creation, bug fixes \u2192 developer profile
+- Code review, quality checks \u2192 reviewer profile
+- Shell commands, project setup, infrastructure \u2192 ops profile
+- Leave assignedProfile empty for auto-triage when unsure
+
+Match complexity to profile capabilities:
+- trivial/simple tasks: any profile (prefer cheapest)
+- moderate tasks: specialist profiles
+- complex tasks: profiles with full capability sets`
+};
+var CAP_MEMORY = {
+  name: "memory",
+  description: "Remember and recall project conventions for continuity across sessions.",
+  tools: [OP_REMEMBER, OP_RECALL],
+  prompt: `## Project Memory
+
+Persist project conventions for future sessions:
+- remember: Save a convention. args: { key: "naming", value: "kebab-case for files" }
+- recall: Load all saved conventions. args: {} \u2014 returns project memory.
+
+What to remember:
+- Naming conventions (file names, variable names)
+- Architecture decisions (Result pattern, Zod for validation)
+- Test patterns (where tests go, what framework)
+- Common dependencies and their usage
+
+Before planning, recall project memory to follow established patterns.
+When you discover a new convention, remember it for future bots.`
+};
 var BUILT_IN_CAPABILITIES = [
   CAP_CORE,
   CAP_FILE_OPS,
@@ -2843,7 +3035,15 @@ var BUILT_IN_CAPABILITIES = [
   CAP_FW_CLI,
   CAP_CODE_REVIEW,
   CAP_WEB,
-  CAP_CONTEXT
+  CAP_CONTEXT,
+  // Swarm improvement capabilities
+  CAP_VERIFICATION,
+  CAP_CROSS_FILE_CHECK,
+  CAP_PROJECT_SETUP,
+  CAP_SECURITY,
+  CAP_DECOMPOSITION,
+  CAP_ROUTING,
+  CAP_MEMORY
 ];
 var capabilityMap = new Map(
   BUILT_IN_CAPABILITIES.map((c) => [c.name, c])