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

package/src/bot/capability-registry.ts

@@ -10,7 +10,7 @@ import type { CapabilityDefinition } from './capability-types.js';
 import {
   OP_WRITE_FILE, OP_READ_FILE, OP_PATCH_FILE, OP_LIST_FILES,
   OP_RUN_SHELL, OP_VALIDATE, OP_TSC_CHECK, OP_RUN_TESTS,
-  OP_TASK_CREATE,
+  OP_TASK_CREATE, OP_REMEMBER, OP_RECALL,
 } from './operations.js';
 
 // ---------------------------------------------------------------------------
@@ -36,6 +36,92 @@ Do NOT describe what you would do — actually do it by calling tools.
 - Be concise — let tool results speak.`,
 };
 
+// ---------------------------------------------------------------------------
+// Role capabilities — define bot identity and primary directive
+// ---------------------------------------------------------------------------
+
+const CAP_ROLE_ORCHESTRATOR: CapabilityDefinition = {
+  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 → "developer"
+   - Code review, quality checks → "reviewer"
+   - Project setup, dependencies, config → "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 — 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)`,
+};
+
+const CAP_ROLE_DEVELOPER: CapabilityDefinition = {
+  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 — 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 — 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 — you must produce artifacts.`,
+};
+
+const CAP_ROLE_REVIEWER: CapabilityDefinition = {
+  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.`,
+};
+
+const CAP_ROLE_OPS: CapabilityDefinition = {
+  name: 'role-ops',
+  description: 'Ops role: sets up project infrastructure, configs, dependencies.',
+  prompt: `## YOUR ROLE: Ops
+You SET UP infrastructure — 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.`,
+};
+
 const CAP_FILE_OPS: CapabilityDefinition = {
   name: 'file-ops',
   description: 'File read/write/patch operations and best practices for file manipulation.',
@@ -67,13 +153,31 @@ Use run_shell for running tests (npx vitest), validation (flow-weaver validate),
 
 const CAP_TASK_MGMT: CapabilityDefinition = {
   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
-
-Use task_create to decompose complex work into smaller, independent subtasks that other bots can execute in parallel.`,
+  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.
+
+### Dependency Guidelines
+- BAD: A → B → C → D (serial, slow)
+- GOOD: A → [B + C + D] (A blocks all, but B/C/D run in parallel)
+Structure as: setup → independent implementations → integration/testing.`,
 };
 
 const CAP_FW_GRAMMAR: CapabilityDefinition = {
@@ -156,17 +260,41 @@ Note: compile, validate, modify, diff, diagram, and describe operations are avai
 
 const CAP_CODE_REVIEW: CapabilityDefinition = {
   name: 'code-review',
-  description: 'Code review guidelines, quality checklist, and security review patterns.',
-  prompt: `## Code Review
-
-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
-
-Report concerns with specific file:line references and suggested fixes.`,
+  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?
+
+### 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²) 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 → Fix suggestion`,
 };
 
 const CAP_WEB: CapabilityDefinition = {
@@ -186,6 +314,134 @@ Use list_files to understand the project structure before making changes.
 The context bundle (when available) provides a snapshot of the workspace.`,
 };
 
+// ---------------------------------------------------------------------------
+// New capabilities — swarm improvements
+// ---------------------------------------------------------------------------
+
+const CAP_VERIFICATION: CapabilityDefinition = {
+  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.`,
+};
+
+const CAP_CROSS_FILE_CHECK: CapabilityDefinition = {
+  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.`,
+};
+
+const CAP_PROJECT_SETUP: CapabilityDefinition = {
+  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`,
+};
+
+const CAP_SECURITY: CapabilityDefinition = {
+  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.`,
+};
+
+const CAP_DECOMPOSITION: CapabilityDefinition = {
+  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 — runs in parallel with B)
+
+Assign profiles: code tasks → developer, review tasks → reviewer, infra → ops.`,
+};
+
+const CAP_ROUTING: CapabilityDefinition = {
+  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 → developer profile
+- Code review, quality checks → reviewer profile
+- Shell commands, project setup, infrastructure → 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`,
+};
+
+const CAP_MEMORY: CapabilityDefinition = {
+  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: {} — 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.`,
+};
+
 // ---------------------------------------------------------------------------
 // Registry
 // ---------------------------------------------------------------------------
@@ -193,6 +449,12 @@ The context bundle (when available) provides a snapshot of the workspace.`,
 /** All built-in capability definitions. */
 export const BUILT_IN_CAPABILITIES: readonly CapabilityDefinition[] = [
   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,
@@ -203,8 +465,28 @@ export const BUILT_IN_CAPABILITIES: readonly CapabilityDefinition[] = [
   CAP_CODE_REVIEW,
   CAP_WEB,
   CAP_CONTEXT,
+  // Swarm improvement capabilities
+  CAP_VERIFICATION,
+  CAP_CROSS_FILE_CHECK,
+  CAP_PROJECT_SETUP,
+  CAP_SECURITY,
+  CAP_DECOMPOSITION,
+  CAP_ROUTING,
+  CAP_MEMORY,
 ];
 
+// ---------------------------------------------------------------------------
+// Per-profile capability pools — defines what each role CAN use
+// ---------------------------------------------------------------------------
+
+/** Capability pools per profile role. Triage selects from these per task. */
+export const PROFILE_CAPABILITIES: Record<string, string[]> = {
+  orchestrator: ['core', 'role-orchestrator', 'decomposition', 'routing', 'task-mgmt', 'context'],
+  developer: ['core', 'role-developer', 'file-ops', 'shell', 'verification', 'cross-file-check', 'fw-grammar', 'fw-validate', 'context'],
+  reviewer: ['core', 'role-reviewer', 'code-review', 'file-ops', 'security', 'context'],
+  ops: ['core', 'role-ops', 'file-ops', 'shell', 'project-setup', 'verification', 'context'],
+};
+
 const capabilityMap = new Map<string, CapabilityDefinition>(
   BUILT_IN_CAPABILITIES.map(c => [c.name, c]),
 );

package/src/bot/dashboard.ts

@@ -326,12 +326,12 @@ export class DashboardServer {
       const pending = tasks.filter(t => t.status === 'pending').length;
       const inProgress = tasks.filter(t => t.status === 'in-progress').length;
       const done = tasks.filter(t => t.status === 'done').length;
-      const failed = tasks.filter(t => t.status === 'failed').length;
+      const cancelled = tasks.filter(t => t.status === 'cancelled').length;
       res.writeHead(200, { 'Content-Type': 'application/json' });
-      res.end(JSON.stringify({ status: inProgress > 0 ? 'executing' : 'idle', pending, inProgress, done, failed }));
+      res.end(JSON.stringify({ status: inProgress > 0 ? 'executing' : 'idle', pending, inProgress, done, cancelled }));
     }).catch(() => {
       res.writeHead(200, { 'Content-Type': 'application/json' });
-      res.end(JSON.stringify({ status: 'idle', pending: 0, inProgress: 0, done: 0, failed: 0 }));
+      res.end(JSON.stringify({ status: 'idle', pending: 0, inProgress: 0, done: 0, cancelled: 0 }));
     });
   }
 

package/src/bot/hierarchy-event-log.ts

@@ -0,0 +1,64 @@
+import * as fs from 'node:fs';
+import * as path from 'node:path';
+
+export interface HierarchyEvent {
+  id: number;
+  parentId: string;
+  type: string;
+  taskId: string;
+  timestamp: number;
+  data?: Record<string, unknown>;
+}
+
+/**
+ * Append-only event log scoped to task hierarchies.
+ *
+ * Events are tagged with `parentId` so sibling tasks can read only
+ * events relevant to their hierarchy. Unrelated task hierarchies
+ * don't see each other's events.
+ *
+ * Writes to `.weaver/hierarchy-events.ndjson`.
+ */
+export class HierarchyEventLog {
+  private readonly filePath: string;
+  private nextId = 0;
+
+  constructor(projectDir: string) {
+    const dir = path.join(projectDir, '.weaver');
+    if (!fs.existsSync(dir)) fs.mkdirSync(dir, { recursive: true });
+    this.filePath = path.join(dir, 'hierarchy-events.ndjson');
+  }
+
+  /** Append a hierarchy-scoped event. */
+  emit(event: { parentId: string; type: string; taskId: string; data?: Record<string, unknown> }): void {
+    const full: HierarchyEvent = { ...event, id: this.nextId++, timestamp: Date.now() };
+    fs.appendFileSync(this.filePath, JSON.stringify(full) + '\n', 'utf-8');
+  }
+
+  /**
+   * Read events for a specific parent hierarchy, starting from offset.
+   * Only returns events matching the given parentId.
+   */
+  tailByParent(parentId: string, offset = 0): HierarchyEvent[] {
+    if (!fs.existsSync(this.filePath)) return [];
+    const content = fs.readFileSync(this.filePath, 'utf-8');
+    const result: HierarchyEvent[] = [];
+    for (const line of content.split('\n')) {
+      const trimmed = line.trim();
+      if (!trimmed) continue;
+      try {
+        const event = JSON.parse(trimmed) as HierarchyEvent;
+        if (event.parentId === parentId && event.id >= offset) {
+          result.push(event);
+        }
+      } catch { /* skip corrupt line */ }
+    }
+    return result;
+  }
+
+  /** Remove all events. */
+  clear(): void {
+    try { fs.unlinkSync(this.filePath); } catch { /* ok */ }
+    this.nextId = 0;
+  }
+}

package/src/bot/operations.ts

@@ -34,6 +34,13 @@ export const OP_RUN_TESTS = 'run_tests';
 
 export const OP_TASK_CREATE = 'task_create';
 
+// ---------------------------------------------------------------------------
+// Memory
+// ---------------------------------------------------------------------------
+
+export const OP_REMEMBER = 'remember';
+export const OP_RECALL = 'recall';
+
 // ---------------------------------------------------------------------------
 // Passthrough (no execution needed)
 // ---------------------------------------------------------------------------

package/src/bot/profile-store.ts

@@ -3,6 +3,7 @@ import * as path from 'node:path';
 import * as crypto from 'node:crypto';
 import type { BotProfile, CreateProfileInput, Capability } from './profile-types.js';
 import { buildDefaultBehavior } from './behavior-defaults.js';
+import { PROFILE_CAPABILITIES } from './capability-registry.js';
 
 // ---------------------------------------------------------------------------
 // Default profiles — enterprise-ready starting kit
@@ -152,6 +153,7 @@ const DEFAULT_PROFILES: Record<string, Array<Omit<CreateProfileInput, 'botId'>>>
         // Standard tier for plan+execute. 3 retries then block.
         // Iron Law: investigate before fixing → reportConcerns on.
         behavior: {
+          capabilities: PROFILE_CAPABILITIES.developer,
           phases: {
             plan: { enabled: true, tier: 'standard' as const },
             execute: { enabled: true, tier: 'standard' as const },
@@ -185,6 +187,7 @@ const DEFAULT_PROFILES: Record<string, Array<Omit<CreateProfileInput, 'botId'>>>
         // Finding classification: AUTO-FIX / ASK / INFORM → requireEvidence.
         // Low retries — if review fails twice, escalate to human.
         behavior: {
+          capabilities: PROFILE_CAPABILITIES.reviewer,
           phases: {
             plan: { enabled: true, tier: 'fast' as const },
             execute: { enabled: false, tier: 'standard' as const },
@@ -217,6 +220,7 @@ const DEFAULT_PROFILES: Record<string, Array<Omit<CreateProfileInput, 'botId'>>>
         // Blocked from src/ and lib/ — ops touches config, scripts, CI only.
         // Reassign on exhaustion — don't block, escalate to human.
         behavior: {
+          capabilities: PROFILE_CAPABILITIES.ops,
           phases: {
             plan: { enabled: true, tier: 'standard' as const },
             execute: { enabled: true, tier: 'standard' as const },
@@ -230,6 +234,48 @@ const DEFAULT_PROFILES: Record<string, Array<Omit<CreateProfileInput, 'botId'>>>
         },
       },
     },
+    {
+      name: 'Orchestrator',
+      description: 'Decomposes high-level objectives into tasks, assigns profiles, manages dependencies.',
+      icon: 'accountTree',
+      color: 'color-node-purple-icon',
+      capabilities: [
+        { name: 'decomposition', description: 'Break complex objectives into subtask DAGs with dependencies' },
+        { name: 'routing', description: 'Match tasks to the right bot profile based on capabilities' },
+        { name: 'task-mgmt', description: 'Create, prioritize, and manage swarm tasks' },
+      ],
+      preferences: {
+        costStrategy: 'frugal',
+        requireApproval: false,
+        instructions: `You are the orchestrator. Your job is to decompose high-level objectives into concrete, actionable subtasks that other bots can execute.
+
+## Protocol
+1. ANALYZE: Understand the objective. What files, features, and concerns are involved?
+2. DECOMPOSE: Break into subtasks. Each subtask should be completable by a single bot.
+3. ASSIGN: Set assignedProfile per task (developer, reviewer, ops). Set complexity and priority.
+4. DEPENDENCIES: Use dependsOn to model blocking relationships. Minimize deps for parallelism.
+
+## Rules
+- You do NOT write code yourself. You create tasks for other bots.
+- CRITICAL: Every subtask MUST have assignedProfile set to "developer", "reviewer", or "ops". NEVER leave it empty or set it to "orchestrator".
+- Every subtask needs: title, description, assignedProfile, complexity.
+- Code/file tasks → assignedProfile: "developer". Setup/infra → assignedProfile: "ops". Review → assignedProfile: "reviewer".
+- Structure as: setup → independent implementations → integration → review.
+- If a task is simple enough (single file, clear scope), don't decompose further.`,
+        behavior: {
+          capabilities: PROFILE_CAPABILITIES.orchestrator,
+          phases: {
+            plan: { enabled: true, tier: 'fast' as const },
+            execute: { enabled: true, tier: 'fast' as const },
+            review: { enabled: false },
+            validate: { enabled: false },
+            gitOps: { enabled: false },
+          },
+          escalation: { maxAttempts: 2, onExhausted: 'block' as const },
+          exitProtocol: { reportConcerns: false, requireEvidence: false },
+        },
+      },
+    },
   ],
   'weaver-genesis': [
     {

package/src/bot/runner.ts

@@ -289,10 +289,6 @@ export async function runWorkflow(
     const nodeStartTimes = new Map<string, number>();
     const nodeTypes = new Map<string, string>(); // nodeId → nodeTypeName
     const nodeOutputs = new Map<string, Array<{ portLabel: string; value: unknown }>>();
-    // Dedup: the FW runtime can emit duplicate STATUS_CHANGED events per node
-    // (from both the expression evaluator and the graph engine). Track which
-    // node-start/node-complete events we've already emitted to avoid duplicates.
-    const emittedNodeEvents = new Set<string>(); // "nodeId:eventType"
 
     /** Try to parse JSON strings into objects so the UI renders them as structured JSON. */
     function resolveOutputValue(value: unknown): unknown {
@@ -358,17 +354,6 @@ export async function runWorkflow(
       }
 
       if (eventType) {
-        // Deduplicate: skip if we already emitted this event for this node
-        const dedupKey = `${nodeId}:${eventType}`;
-        if (emittedNodeEvents.has(dedupKey)) return;
-        emittedNodeEvents.add(dedupKey);
-        // Clear dedup tracking for the node when it completes/errors so it can
-        // re-enter the pipeline (e.g. in retry loops or multi-execution workflows)
-        if (eventType !== 'node-start') {
-          emittedNodeEvents.delete(`${nodeId}:node-start`);
-          emittedNodeEvents.delete(dedupKey);
-        }
-
         // Attach accumulated outputs on completion/error, then clear
         const outputs = nodeOutputs.get(nodeId);
         if (eventType !== 'node-start') nodeOutputs.delete(nodeId);
@@ -454,6 +439,54 @@ export async function runWorkflow(
       }
     } catch { /* extraction is best-effort */ }
 
+    // Build markdown report from the extracted context data
+    let report: string | undefined;
+    try {
+      const ctxStr = result?.ctx as string | undefined;
+      if (ctxStr) {
+        const ctx = JSON.parse(ctxStr);
+        const md: string[] = [];
+        md.push(`## ${success ? 'Task Completed' : 'Task Failed'}`);
+        md.push('');
+
+        // Steps
+        if (stepLog && stepLog.length > 0) {
+          md.push('### Steps');
+          md.push('');
+          for (const s of stepLog) {
+            const icon = s.status === 'ok' ? '**ok**' : s.status === 'error' ? '**error**' : '**blocked**';
+            md.push(`- ${s.step} (${icon})${s.detail ? `: ${s.detail}` : ''}`);
+          }
+          md.push('');
+        }
+
+        // Files
+        const files: string[] = ctx.filesModified ? JSON.parse(ctx.filesModified) : [];
+        if (files.length > 0) {
+          md.push('### Files Modified');
+          md.push('');
+          for (const f of files) md.push(`- \`${f}\``);
+          md.push('');
+        }
+
+        // Review
+        if (ctx.reviewJson) {
+          const review = JSON.parse(ctx.reviewJson) as Record<string, string>;
+          if (review.intent || review.execution || review.result || review.completeness) {
+            md.push('### Review');
+            md.push('');
+            for (const key of ['intent', 'execution', 'result', 'completeness']) {
+              if (review[key]) md.push(`- **${key}:** ${review[key]}`);
+            }
+            if (review.reason) md.push(`\n${review.reason}`);
+            md.push('');
+          }
+        }
+
+        if (md.length > 2) report = md.join('\n');
+      }
+    } catch { /* report generation is best-effort */ }
+
     await notifier({
       type: 'workflow-complete',
       workflowFile: absPath,
@@ -466,6 +499,7 @@ export async function runWorkflow(
     persistCost(costSummary, absPath, providerConfig.name, verbose);
     recordRun(store, {
       id: runId, workflowFile: absPath, startedAt, success, outcome: outcome as RunOutcome, summary,
+      report,
       functionName: execResult.functionName, executionTime: execResult.executionTime,
       dryRun: false, provider: providerConfig.name, params: options?.params, stepLog,
       trace: collectedTrace.length > 0 ? collectedTrace : undefined,
@@ -477,13 +511,14 @@ export async function runWorkflow(
       botId: options?.botId,
     }, verbose);
 
-    logEvent?.({ type: 'bot-completed', timestamp: Date.now(), data: { success, outcome, summary } });
+    logEvent?.({ type: 'bot-completed', timestamp: Date.now(), data: { success, outcome, summary, report } });
 
     auditEmit('run-complete', { success, outcome, summary });
 
     return {
       success,
       summary,
+      report,
       outcome,
       functionName: execResult.functionName,
       executionTime: execResult.executionTime,