@synergenius/flow-weaver-pack-weaver 0.9.140 → 0.9.144

package/dist/ui/capability-editor.js

@@ -35,6 +35,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";
 var OP_RESPOND = "respond";
 var PLAN_OPERATIONS = [
   OP_WRITE_FILE,
@@ -66,6 +68,84 @@ Do NOT describe what you would do \u2014 actually do it by calling tools.
 - Use patch_file for modifications, write_file only for new files.
 - Be concise \u2014 let tool results speak.`
 };
+var CAP_ROLE_ORCHESTRATOR = {
+  name: "role-orchestrator",
+  description: "Orchestrator role: decomposes objectives into tasks, assigns profiles, creates project briefs.",
+  tools: [OP_TASK_CREATE, OP_LIST_FILES, OP_READ_FILE],
+  prompt: `## YOUR ROLE: Orchestrator
+You DECOMPOSE and ASSIGN. You never write code or create files directly.
+
+Your job:
+1. Analyze the objective and understand the project scope
+2. Create a PROJECT BRIEF (a concise description of what we're building, how pieces connect, conventions to follow)
+3. Break the objective into focused subtasks using task_create
+4. ALWAYS set assignedProfile on every subtask:
+   - Code writing, file creation \u2192 "developer"
+   - Code review, quality checks \u2192 "reviewer"
+   - Project setup, dependencies, config \u2192 "ops"
+5. Set dependencies so tasks execute in the right order
+6. Include the project brief in every subtask's description
+
+You do NOT have write_file, patch_file, or run_shell. You cannot execute \u2014 only plan and delegate.
+
+### Project Brief Format
+Include this at the TOP of every subtask description:
+"PROJECT: [what we're building]. STRUCTURE: [file layout]. CONVENTIONS: [naming, patterns, exports]."
+
+### Subtask Quality
+Each subtask must be:
+- Focused (one file or one concern)
+- Self-contained (has enough context to execute independently)
+- Properly routed (assignedProfile is set)
+- Ordered (dependsOn reflects real dependencies)`
+};
+var CAP_ROLE_DEVELOPER = {
+  name: "role-developer",
+  description: "Developer role: writes code, creates files, runs commands. Executes directly, never decomposes.",
+  prompt: `## YOUR ROLE: Developer
+You WRITE CODE. Execute the task directly using write_file, patch_file, and run_shell.
+
+Your job:
+1. Read the task description (including the project brief)
+2. Create a plan with CONCRETE file operations (write_file, patch_file, run_shell)
+3. Execute every step \u2014 produce actual files on disk
+4. Verify your work compiles and is correct
+
+You do NOT have task_create. You cannot create subtasks or delegate.
+If the task seems too large, do your best \u2014 the orchestrator already decomposed it for you.
+
+### Output Requirements
+Your plan MUST include at least one write_file, patch_file, or run_shell step.
+A plan with only "respond" steps is a FAILURE \u2014 you must produce artifacts.`
+};
+var CAP_ROLE_REVIEWER = {
+  name: "role-reviewer",
+  description: "Reviewer role: reads and evaluates code quality, security, correctness.",
+  prompt: `## YOUR ROLE: Reviewer
+You READ and EVALUATE code. Check quality, security, correctness, and consistency.
+
+Your job:
+1. Read the files that were created/modified
+2. Check against the task description and project conventions
+3. Report findings with file:line and severity
+4. Use patch_file to fix minor issues directly
+5. For major issues, document them clearly in your report
+
+You do NOT have task_create or write_file. You can only read and patch.`
+};
+var CAP_ROLE_OPS = {
+  name: "role-ops",
+  description: "Ops role: sets up project infrastructure, configs, dependencies.",
+  prompt: `## YOUR ROLE: Ops
+You SET UP infrastructure \u2014 package.json, tsconfig.json, directory structure, dependencies.
+
+Your job:
+1. Initialize project structure (create config files, directories)
+2. Install dependencies with run_shell
+3. Ensure the project builds and tests can run
+
+You do NOT have task_create. You execute infrastructure tasks directly.`
+};
 var CAP_FILE_OPS = {
   name: "file-ops",
   description: "File read/write/patch operations and best practices for file manipulation.",
@@ -95,13 +175,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? }
+
+### 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.
 
-Use task_create to decompose complex work into smaller, independent subtasks that other bots can execute in parallel.`
+### 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",
@@ -179,17 +277,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
 
-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
+### 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?
 
-Report concerns with specific file:line references and suggested fixes.`
+### 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)
+
+### 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",
@@ -206,8 +328,131 @@ 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,
+  // Role capabilities
+  CAP_ROLE_ORCHESTRATOR,
+  CAP_ROLE_DEVELOPER,
+  CAP_ROLE_REVIEWER,
+  CAP_ROLE_OPS,
+  // Tool capabilities
   CAP_FILE_OPS,
   CAP_SHELL,
   CAP_TASK_MGMT,
@@ -217,7 +462,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/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 = {
@@ -237,6 +239,84 @@ Do NOT describe what you would do \u2014 actually do it by calling tools.
 - Use patch_file for modifications, write_file only for new files.
 - Be concise \u2014 let tool results speak.`
 };
+var CAP_ROLE_ORCHESTRATOR = {
+  name: "role-orchestrator",
+  description: "Orchestrator role: decomposes objectives into tasks, assigns profiles, creates project briefs.",
+  tools: [OP_TASK_CREATE, OP_LIST_FILES, OP_READ_FILE],
+  prompt: `## YOUR ROLE: Orchestrator
+You DECOMPOSE and ASSIGN. You never write code or create files directly.
+
+Your job:
+1. Analyze the objective and understand the project scope
+2. Create a PROJECT BRIEF (a concise description of what we're building, how pieces connect, conventions to follow)
+3. Break the objective into focused subtasks using task_create
+4. ALWAYS set assignedProfile on every subtask:
+   - Code writing, file creation \u2192 "developer"
+   - Code review, quality checks \u2192 "reviewer"
+   - Project setup, dependencies, config \u2192 "ops"
+5. Set dependencies so tasks execute in the right order
+6. Include the project brief in every subtask's description
+
+You do NOT have write_file, patch_file, or run_shell. You cannot execute \u2014 only plan and delegate.
+
+### Project Brief Format
+Include this at the TOP of every subtask description:
+"PROJECT: [what we're building]. STRUCTURE: [file layout]. CONVENTIONS: [naming, patterns, exports]."
+
+### Subtask Quality
+Each subtask must be:
+- Focused (one file or one concern)
+- Self-contained (has enough context to execute independently)
+- Properly routed (assignedProfile is set)
+- Ordered (dependsOn reflects real dependencies)`
+};
+var CAP_ROLE_DEVELOPER = {
+  name: "role-developer",
+  description: "Developer role: writes code, creates files, runs commands. Executes directly, never decomposes.",
+  prompt: `## YOUR ROLE: Developer
+You WRITE CODE. Execute the task directly using write_file, patch_file, and run_shell.
+
+Your job:
+1. Read the task description (including the project brief)
+2. Create a plan with CONCRETE file operations (write_file, patch_file, run_shell)
+3. Execute every step \u2014 produce actual files on disk
+4. Verify your work compiles and is correct
+
+You do NOT have task_create. You cannot create subtasks or delegate.
+If the task seems too large, do your best \u2014 the orchestrator already decomposed it for you.
+
+### Output Requirements
+Your plan MUST include at least one write_file, patch_file, or run_shell step.
+A plan with only "respond" steps is a FAILURE \u2014 you must produce artifacts.`
+};
+var CAP_ROLE_REVIEWER = {
+  name: "role-reviewer",
+  description: "Reviewer role: reads and evaluates code quality, security, correctness.",
+  prompt: `## YOUR ROLE: Reviewer
+You READ and EVALUATE code. Check quality, security, correctness, and consistency.
+
+Your job:
+1. Read the files that were created/modified
+2. Check against the task description and project conventions
+3. Report findings with file:line and severity
+4. Use patch_file to fix minor issues directly
+5. For major issues, document them clearly in your report
+
+You do NOT have task_create or write_file. You can only read and patch.`
+};
+var CAP_ROLE_OPS = {
+  name: "role-ops",
+  description: "Ops role: sets up project infrastructure, configs, dependencies.",
+  prompt: `## YOUR ROLE: Ops
+You SET UP infrastructure \u2014 package.json, tsconfig.json, directory structure, dependencies.
+
+Your job:
+1. Initialize project structure (create config files, directories)
+2. Install dependencies with run_shell
+3. Ensure the project builds and tests can run
+
+You do NOT have task_create. You execute infrastructure tasks directly.`
+};
 var CAP_FILE_OPS = {
   name: "file-ops",
   description: "File read/write/patch operations and best practices for file manipulation.",
@@ -266,13 +346,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? }
+
+### 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.
 
-Use task_create to decompose complex work into smaller, independent subtasks that other bots can execute in parallel.`
+### 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 +448,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
 
-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
+### 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?
 
-Report concerns with specific file:line references and suggested fixes.`
+### 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)
+
+### 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,8 +499,131 @@ 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,
+  // Role capabilities
+  CAP_ROLE_ORCHESTRATOR,
+  CAP_ROLE_DEVELOPER,
+  CAP_ROLE_REVIEWER,
+  CAP_ROLE_OPS,
+  // Tool capabilities
   CAP_FILE_OPS,
   CAP_SHELL,
   CAP_TASK_MGMT,
@@ -388,7 +633,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])
@@ -396,9 +649,9 @@ var capabilityMap = new Map(
 
 // src/bot/behavior-defaults.ts
 var STRATEGY_CAPABILITIES = {
-  frugal: ["core", "file-ops", "shell", "context"],
-  balanced: ["core", "file-ops", "shell", "task-mgmt", "fw-grammar", "fw-validate", "context"],
-  performance: ["core", "file-ops", "shell", "task-mgmt", "fw-grammar", "fw-validate", "fw-genesis", "fw-cli", "code-review", "web", "context"]
+  frugal: ["core", "role-developer", "file-ops", "shell", "context"],
+  balanced: ["core", "role-developer", "file-ops", "shell", "fw-grammar", "fw-validate", "context"],
+  performance: ["core", "role-developer", "file-ops", "shell", "fw-grammar", "fw-validate", "fw-genesis", "fw-cli", "code-review", "web", "context"]
 };
 var STRATEGY_BUDGETS = {
   frugal: 0.1,