@covibes/zeroshot 1.0.1 → 1.1.3

package/cli/message-formatters-normal.js

@@ -0,0 +1,214 @@
+/**
+ * Normal mode message formatters
+ * Full-detail message display for non-watch mode
+ */
+
+const chalk = require('chalk');
+
+/**
+ * Format AGENT_LIFECYCLE events
+ * @param {Object} msg - Message object
+ * @param {string} prefix - Formatted message prefix
+ * @returns {boolean} True if message was handled
+ */
+function formatAgentLifecycle(msg, prefix) {
+  const data = msg.content?.data;
+  const event = data?.event;
+
+  let icon, eventText;
+  switch (event) {
+    case 'STARTED':
+      icon = chalk.green('▶');
+      const triggers = data.triggers?.join(', ') || 'none';
+      eventText = `started (listening for: ${chalk.dim(triggers)})`;
+      break;
+    case 'TASK_STARTED':
+      icon = chalk.yellow('⚡');
+      eventText = `${chalk.cyan(data.triggeredBy)} → task #${data.iteration} (${chalk.dim(data.model)})`;
+      break;
+    case 'TASK_COMPLETED':
+      icon = chalk.green('✓');
+      eventText = `task #${data.iteration} completed`;
+      break;
+    default:
+      icon = chalk.dim('•');
+      eventText = event || 'unknown event';
+  }
+
+  console.log(`${prefix} ${icon} ${eventText}`);
+  return true;
+}
+
+/**
+ * Format AGENT_ERROR events
+ * @param {Object} msg - Message object
+ * @param {string} prefix - Formatted message prefix
+ * @param {string} timestamp - Formatted timestamp
+ * @returns {boolean} True if message was handled
+ */
+function formatAgentError(msg, prefix, timestamp) {
+  console.log(''); // Blank line before error
+  console.log(chalk.bold.red(`${'─'.repeat(60)}`));
+  console.log(`${prefix} ${chalk.gray(timestamp)} ${chalk.bold.red('🔴 AGENT ERROR')}`);
+
+  if (msg.content?.text) {
+    console.log(`${prefix} ${chalk.red(msg.content.text)}`);
+  }
+
+  if (msg.content?.data?.stack) {
+    const stackLines = msg.content.data.stack.split('\n').slice(0, 5);
+    for (const line of stackLines) {
+      if (line.trim()) {
+        console.log(`${prefix} ${chalk.dim(line)}`);
+      }
+    }
+  }
+
+  console.log(chalk.bold.red(`${'─'.repeat(60)}`));
+  return true;
+}
+
+/**
+ * Format ISSUE_OPENED events
+ * @param {Object} msg - Message object
+ * @param {string} prefix - Formatted message prefix
+ * @param {string} timestamp - Formatted timestamp
+ * @param {Set} shownNewTaskForCluster - Set tracking shown tasks
+ * @returns {boolean} True if message was handled
+ */
+function formatIssueOpened(msg, prefix, timestamp, shownNewTaskForCluster) {
+  // Skip duplicate - conductor re-publishes after spawning agents
+  if (shownNewTaskForCluster.has(msg.cluster_id)) {
+    return true;
+  }
+  shownNewTaskForCluster.add(msg.cluster_id);
+
+  console.log(''); // Blank line before new task
+  console.log(chalk.bold.blue(`${'─'.repeat(60)}`));
+  console.log(`${prefix} ${chalk.gray(timestamp)} ${chalk.bold.blue('📋 NEW TASK')}`);
+
+  if (msg.content?.text) {
+    const lines = msg.content.text.split('\n').slice(0, 3);
+    for (const line of lines) {
+      if (line.trim() && line.trim() !== '# Manual Input') {
+        console.log(`${prefix} ${chalk.white(line)}`);
+      }
+    }
+  }
+
+  console.log(chalk.bold.blue(`${'─'.repeat(60)}`));
+  return true;
+}
+
+/**
+ * Format IMPLEMENTATION_READY events
+ * @param {Object} msg - Message object
+ * @param {string} prefix - Formatted message prefix
+ * @param {string} timestamp - Formatted timestamp
+ * @returns {boolean} True if message was handled
+ */
+function formatImplementationReady(msg, prefix, timestamp) {
+  console.log(
+    `${prefix} ${chalk.gray(timestamp)} ${chalk.bold.yellow('✅ IMPLEMENTATION READY')}`
+  );
+
+  if (msg.content?.data?.commit) {
+    console.log(
+      `${prefix} ${chalk.gray('Commit:')} ${chalk.cyan(msg.content.data.commit.substring(0, 8))}`
+    );
+  }
+
+  return true;
+}
+
+/**
+ * Format VALIDATION_RESULT events
+ * @param {Object} msg - Message object
+ * @param {string} prefix - Formatted message prefix
+ * @param {string} timestamp - Formatted timestamp
+ * @returns {boolean} True if message was handled
+ */
+function formatValidationResult(msg, prefix, timestamp) {
+  const data = msg.content?.data || {};
+  const approved = data.approved === true || data.approved === 'true';
+  const status = approved ? chalk.bold.green('✓ APPROVED') : chalk.bold.red('✗ REJECTED');
+
+  console.log(`${prefix} ${chalk.gray(timestamp)} ${status}`);
+
+  // Show summary if present and not a template variable
+  if (msg.content?.text && !msg.content.text.includes('{{')) {
+    console.log(`${prefix} ${msg.content.text.substring(0, 100)}`);
+  }
+
+  // Show full JSON data structure
+  console.log(
+    `${prefix} ${chalk.dim(JSON.stringify(data, null, 2).split('\n').join(`\n${prefix} `))}`
+  );
+
+  return true;
+}
+
+/**
+ * Format CLUSTER_COMPLETE events
+ * @param {Object} msg - Message object
+ * @param {string} prefix - Formatted message prefix
+ * @param {string} timestamp - Formatted timestamp
+ * @returns {boolean} True if message was handled
+ */
+function formatClusterComplete(msg, prefix, timestamp) {
+  console.log(''); // Blank line
+  console.log(chalk.bold.green(`${'═'.repeat(60)}`));
+  console.log(`${prefix} ${chalk.gray(timestamp)} ${chalk.bold.green('🎉 CLUSTER COMPLETE')}`);
+  if (msg.content?.data?.reason) {
+    console.log(`${prefix} ${chalk.green(msg.content.data.reason)}`);
+  }
+  console.log(chalk.bold.green(`${'═'.repeat(60)}`));
+  return true;
+}
+
+/**
+ * Format CLUSTER_FAILED events
+ * @param {Object} msg - Message object
+ * @param {string} prefix - Formatted message prefix
+ * @param {string} timestamp - Formatted timestamp
+ * @returns {boolean} True if message was handled
+ */
+function formatClusterFailed(msg, prefix, timestamp) {
+  console.log(''); // Blank line
+  console.log(chalk.bold.red(`${'═'.repeat(60)}`));
+  console.log(`${prefix} ${chalk.gray(timestamp)} ${chalk.bold.red('❌ CLUSTER FAILED')}`);
+  if (msg.content?.text) {
+    console.log(`${prefix} ${chalk.red(msg.content.text)}`);
+  }
+  if (msg.content?.data?.reason) {
+    console.log(`${prefix} ${chalk.red(msg.content.data.reason)}`);
+  }
+  console.log(chalk.bold.red(`${'═'.repeat(60)}`));
+  return true;
+}
+
+/**
+ * Format generic messages (fallback)
+ * @param {Object} msg - Message object
+ * @param {string} prefix - Formatted message prefix
+ * @param {string} timestamp - Formatted timestamp
+ * @returns {boolean} True if message was handled
+ */
+function formatGenericMessage(msg, prefix, timestamp) {
+  console.log(`${prefix} ${chalk.gray(timestamp)} ${chalk.bold(msg.topic)}`);
+  if (msg.content?.text) {
+    console.log(`${prefix} ${msg.content.text}`);
+  }
+  return true;
+}
+
+module.exports = {
+  formatAgentLifecycle,
+  formatAgentError,
+  formatIssueOpened,
+  formatImplementationReady,
+  formatValidationResult,
+  formatClusterComplete,
+  formatClusterFailed,
+  formatGenericMessage,
+};

package/cli/message-formatters-watch.js

@@ -0,0 +1,181 @@
+/**
+ * Watch mode message formatters
+ * Simplified, high-level event display for zeroshot watch command
+ */
+
+const chalk = require('chalk');
+const { buildClusterPrefix, getColorForSender, parseDataField } = require('./message-formatter-utils');
+
+/**
+ * Format AGENT_ERROR for watch mode
+ * @param {Object} msg - Message object
+ * @param {string} clusterPrefix - Formatted cluster prefix
+ */
+function formatAgentError(msg, clusterPrefix) {
+  const errorMsg = `${msg.sender} ${chalk.bold.red('ERROR')}`;
+  console.log(`${clusterPrefix} ${errorMsg}`);
+  if (msg.content?.text) {
+    console.log(`${clusterPrefix}   ${chalk.red(msg.content.text)}`);
+  }
+}
+
+/**
+ * Format ISSUE_OPENED for watch mode
+ * @param {Object} msg - Message object
+ * @param {string} clusterPrefix - Formatted cluster prefix
+ */
+function formatIssueOpened(msg, clusterPrefix) {
+  const issueNum = msg.content?.data?.issue_number || '';
+  const title = msg.content?.data?.title || '';
+  const prompt = msg.content?.data?.prompt || msg.content?.text || '';
+
+  const taskDesc = title === 'Manual Input' && prompt ? prompt : title;
+  const truncatedDesc =
+    taskDesc && taskDesc.length > 60 ? taskDesc.substring(0, 60) + '...' : taskDesc;
+
+  const eventText = `Started ${issueNum ? `#${issueNum}` : 'task'}${truncatedDesc ? chalk.dim(` - ${truncatedDesc}`) : ''}`;
+  console.log(`${clusterPrefix} ${eventText}`);
+}
+
+/**
+ * Format IMPLEMENTATION_READY for watch mode
+ * @param {Object} msg - Message object
+ * @param {string} clusterPrefix - Formatted cluster prefix
+ */
+function formatImplementationReady(msg, clusterPrefix) {
+  const agentColor = getColorForSender(msg.sender);
+  const agentName = agentColor(msg.sender);
+  const eventText = `${agentName} completed implementation`;
+  console.log(`${clusterPrefix} ${eventText}`);
+}
+
+/**
+ * Format VALIDATION_RESULT for watch mode
+ * @param {Object} msg - Message object
+ * @param {string} clusterPrefix - Formatted cluster prefix
+ */
+function formatValidationResult(msg, clusterPrefix) {
+  const agentColor = getColorForSender(msg.sender);
+  const agentName = agentColor(msg.sender);
+  const data = msg.content?.data;
+  const approved = data?.approved === 'true' || data?.approved === true;
+  const status = approved ? chalk.green('APPROVED') : chalk.red('REJECTED');
+
+  let eventText = `${agentName} ${status}`;
+  if (data?.summary && !approved) {
+    eventText += chalk.dim(` - ${data.summary}`);
+  }
+  console.log(`${clusterPrefix} ${eventText}`);
+
+  if (!approved) {
+    printRejectionDetails(data, clusterPrefix);
+  }
+}
+
+/**
+ * Print rejection details (errors/issues)
+ * @param {Object} data - Validation data
+ * @param {string} clusterPrefix - Formatted cluster prefix
+ */
+function printRejectionDetails(data, clusterPrefix) {
+  const errors = parseDataField(data.errors);
+  const issues = parseDataField(data.issues);
+
+  if (errors.length > 0) {
+    const errorsCharCount = JSON.stringify(errors).length;
+    console.log(
+      `${clusterPrefix}   ${chalk.red('•')} ${errors.length} error${errors.length > 1 ? 's' : ''} (${errorsCharCount} chars)`
+    );
+  }
+
+  if (issues.length > 0) {
+    const issuesCharCount = JSON.stringify(issues).length;
+    console.log(
+      `${clusterPrefix}   ${chalk.yellow('•')} ${issues.length} issue${issues.length > 1 ? 's' : ''} (${issuesCharCount} chars)`
+    );
+  }
+}
+
+/**
+ * Format PR_CREATED for watch mode
+ * @param {Object} msg - Message object
+ * @param {string} clusterPrefix - Formatted cluster prefix
+ */
+function formatPrCreated(msg, clusterPrefix) {
+  const agentColor = getColorForSender(msg.sender);
+  const agentName = agentColor(msg.sender);
+  const prNum = msg.content?.data?.pr_number || '';
+  const eventText = `${agentName} created PR${prNum ? ` #${prNum}` : ''}`;
+  console.log(`${clusterPrefix} ${eventText}`);
+}
+
+/**
+ * Format PR_MERGED for watch mode
+ * @param {Object} msg - Message object
+ * @param {string} clusterPrefix - Formatted cluster prefix
+ */
+function formatPrMerged(msg, clusterPrefix) {
+  const agentColor = getColorForSender(msg.sender);
+  const agentName = agentColor(msg.sender);
+  const eventText = `${agentName} merged PR`;
+  console.log(`${clusterPrefix} ${eventText}`);
+}
+
+/**
+ * Format unknown topic for watch mode (fallback)
+ * @param {Object} msg - Message object
+ * @param {string} clusterPrefix - Formatted cluster prefix
+ */
+function formatUnknownTopic(msg, clusterPrefix) {
+  const agentColor = getColorForSender(msg.sender);
+  const agentName = agentColor(msg.sender);
+  const eventText = `${agentName} ${msg.topic.toLowerCase().replace(/_/g, ' ')}`;
+  console.log(`${clusterPrefix} ${eventText}`);
+}
+
+/**
+ * Main watch mode formatter
+ * @param {Object} msg - Message object
+ * @param {boolean} isActive - Whether cluster is active
+ * @returns {boolean} True if message was handled
+ */
+function formatWatchMode(msg, isActive) {
+  // Skip low-level topics (too noisy for watch mode)
+  if (msg.topic === 'AGENT_OUTPUT' || msg.topic === 'AGENT_LIFECYCLE') {
+    return true;
+  }
+
+  // Clear status line, print message, will be redrawn by status interval
+  process.stdout.write('\r' + ' '.repeat(120) + '\r');
+
+  const clusterPrefix = buildClusterPrefix(msg.cluster_id, isActive);
+
+  switch (msg.topic) {
+    case 'AGENT_ERROR':
+      formatAgentError(msg, clusterPrefix);
+      break;
+    case 'ISSUE_OPENED':
+      formatIssueOpened(msg, clusterPrefix);
+      break;
+    case 'IMPLEMENTATION_READY':
+      formatImplementationReady(msg, clusterPrefix);
+      break;
+    case 'VALIDATION_RESULT':
+      formatValidationResult(msg, clusterPrefix);
+      break;
+    case 'PR_CREATED':
+      formatPrCreated(msg, clusterPrefix);
+      break;
+    case 'PR_MERGED':
+      formatPrMerged(msg, clusterPrefix);
+      break;
+    default:
+      formatUnknownTopic(msg, clusterPrefix);
+  }
+
+  return true;
+}
+
+module.exports = {
+  formatWatchMode,
+};

package/cluster-templates/base-templates/full-workflow.json

@@ -59,6 +59,11 @@
                 "type": "string",
                 "enum": ["parallel", "sequential", "phased"]
               },
+              "maxParallelTasks": {
+                "type": "number",
+                "default": 3,
+                "description": "Maximum tasks to run in parallel per batch (default 3, prevents context explosion)"
+              },
               "tasks": {
                 "type": "array",
                 "items": {
@@ -134,7 +139,7 @@
       "model": "{{worker_model}}",
       "outputFormat": "stream-json",
       "prompt": {
-        "initial": "## 🚫 YOU CANNOT ASK QUESTIONS\n\nYou are running non-interactively. There is NO USER to answer.\n- NEVER use AskUserQuestion tool\n- NEVER say \"Should I...\" or \"Would you like...\"\n- When unsure: Make the SAFER choice and proceed.\n\nYou are an implementation agent for a {{complexity}} {{task_type}} task.\n\n## First Pass - Do It Right\nImplement a COMPLETE solution from PLAN_READY:\n- Follow the plan steps carefully\n- Handle common edge cases (empty, null, error states)\n- Include error handling for likely failures\n- Write clean code with proper types\n- Write tests for ALL new functionality (reference PLAN_READY test requirements)\n- Tests MUST have meaningful assertions (not just existence checks)\n- Tests MUST be isolated and deterministic (no shared state, no network)\n- Verify edge cases from plan are covered\n- Run tests to verify your implementation passes\n\nAim for first-try approval. Don't leave obvious gaps for validators to find.\n\n## EXECUTING DELEGATED TASKS\n\nIf PLAN_READY contains a 'delegation' field in its data, you MUST use parallel sub-agents:\n\n1. Parse delegation.phases and delegation.tasks from the plan data\n2. For each phase in order:\n   a. Find all tasks for this phase (matching taskIds)\n   b. Spawn sub-agents for ALL tasks in the phase using Task tool\n   c. Use run_in_background: true for parallel execution\n   d. Use the model specified in each task (haiku/sonnet/opus)\n   e. Wait for ALL phase tasks using AgentOutputTool with block: true\n3. After ALL phases complete, verify changes work together\n4. Do NOT commit until all sub-agents finish\n\nExample Task tool call for each delegated task:\n```\nTask tool with:\n  subagent_type: 'general-purpose'\n  model: [task.model from delegation]\n  prompt: '[task.description]. Files: [task.scope]. Do NOT commit.'\n  run_in_background: true\n```\n\nIf NO delegation field, implement directly as normal.\n\n{{#if complexity == 'CRITICAL'}}\n## CRITICAL TASK - EXTRA CARE\n- Double-check every change\n- No shortcuts or assumptions\n- Consider security implications\n- Add comprehensive error handling\n{{/if}}",
+        "initial": "## 🚫 YOU CANNOT ASK QUESTIONS\n\nYou are running non-interactively. There is NO USER to answer.\n- NEVER use AskUserQuestion tool\n- NEVER say \"Should I...\" or \"Would you like...\"\n- When unsure: Make the SAFER choice and proceed.\n\nYou are an implementation agent for a {{complexity}} {{task_type}} task.\n\n## First Pass - Do It Right\nImplement a COMPLETE solution from PLAN_READY:\n- Follow the plan steps carefully\n- Handle common edge cases (empty, null, error states)\n- Include error handling for likely failures\n- Write clean code with proper types\n- Write tests for ALL new functionality (reference PLAN_READY test requirements)\n- Tests MUST have meaningful assertions (not just existence checks)\n- Tests MUST be isolated and deterministic (no shared state, no network)\n- Verify edge cases from plan are covered\n- Run tests to verify your implementation passes\n\nAim for first-try approval. Don't leave obvious gaps for validators to find.\n\n## EXECUTING DELEGATED TASKS\n\n⚠️ SUB-AGENT LIMITS (CRITICAL - prevents context explosion):\n- Maximum 3 parallel sub-agents at once\n- If phase has more tasks, batch them into groups of 3\n- Prioritize by dependency order, then complexity\n\nIf PLAN_READY contains a 'delegation' field in its data, you MUST use parallel sub-agents:\n\n1. Parse delegation.phases and delegation.tasks from the plan data\n2. For each phase in order:\n   a. Find all tasks for this phase (matching taskIds)\n   b. Split into batches of MAX 3 tasks each\n   c. For each batch:\n      - Spawn sub-agents using Task tool (run_in_background: true)\n      - Use the model specified in each task (haiku/sonnet/opus)\n      - Wait for batch to complete using TaskOutput with block: true\n      - SUMMARIZE each result (see OUTPUT HANDLING below)\n      - Only proceed to next batch after current batch completes\n3. After ALL phases complete, verify changes work together\n4. Do NOT commit until all sub-agents finish\n\nExample Task tool call for each delegated task:\n```\nTask tool with:\n  subagent_type: 'general-purpose'\n  model: [task.model from delegation]\n  prompt: '[task.description]. Files: [task.scope]. Do NOT commit.'\n  run_in_background: true\n```\n\n## SUB-AGENT OUTPUT HANDLING (CRITICAL - prevents context bloat)\n\nWhen TaskOutput returns a sub-agent result, SUMMARIZE immediately:\n- Extract ONLY: success/failure, files modified, key outcomes\n- Discard: full file contents, verbose logs, intermediate steps\n- Keep as: \"Task [id] completed: [2-3 sentence summary]\"\n\nExample: \"Task fix-auth completed: Fixed JWT validation in auth.ts, added null check. Tests pass.\"\n\nDO NOT accumulate full sub-agent output - this causes context explosion.\n\nIf NO delegation field, implement directly as normal.\n\n{{#if complexity == 'CRITICAL'}}\n## CRITICAL TASK - EXTRA CARE\n- Double-check every change\n- No shortcuts or assumptions\n- Consider security implications\n- Add comprehensive error handling\n{{/if}}",
         "subsequent": "## 🚫 YOU CANNOT ASK QUESTIONS\n\nYou are running non-interactively. There is NO USER to answer.\n- NEVER use AskUserQuestion tool\n- NEVER say \"Should I...\" or \"Would you like...\"\n- When unsure: Make the SAFER choice and proceed.\n\nYou are an implementation agent for a {{complexity}} {{task_type}} task.\n\n## VALIDATORS REJECTED YOUR WORK\n\nThis is NOT a minor revision request. Senior engineers reviewed your code and found it UNACCEPTABLE. Read ALL VALIDATION_RESULT messages carefully.\n\n## FIX LIKE A SENIOR ARCHITECT WOULD\n\n### 1. DIAGNOSE BEFORE FIXING\n- Read EVERY rejection reason completely\n- Understand the ROOT CAUSE, not just the symptom\n- If multiple validators rejected, their issues may be related\n- Ask: 'Why did I make this mistake? Is my approach fundamentally flawed?'\n\n### 2. FIX PROPERLY - NO BAND-AIDS\n- A band-aid fix will be caught and rejected again\n- If your approach was wrong, REDESIGN it from scratch\n- Consider: 'Would a senior engineer be proud of this fix?'\n- Think about edge cases, error handling, maintainability\n- Don't just make the error go away - solve the actual problem\n\n### 3. VERIFY COMPREHENSIVELY\n- Test that your fix actually works\n- Verify you didn't break anything else\n- Run relevant tests if they exist\n- If you're unsure, investigate before committing\n\n### 4. ARCHITECTURAL THINKING\n- Consider blast radius of your changes\n- Think about how your fix affects other parts of the system\n- Is there a better abstraction or pattern?\n- Future maintainers will inherit your decisions\n\n## MINDSET\n- Validators are not being pedantic - they found REAL problems\n- Every rejection is expensive - get it right this time\n- Shortcuts and hacks will be caught immediately\n- Pride in craftsmanship: deliver code you'd want to maintain\n\n{{#if complexity == 'CRITICAL'}}\n## CRITICAL TASK - ZERO TOLERANCE FOR SHORTCUTS\n- This is HIGH RISK code (auth, payments, security, production)\n- Triple-check every change\n- Consider all failure modes\n- Security implications must be addressed\n- Comprehensive error handling is MANDATORY\n- If unsure, err on the side of caution\n{{/if}}"
       },
       "contextStrategy": {
@@ -189,7 +194,7 @@
         "required": ["approved", "summary"]
       },
       "prompt": {
-        "system": "## 🚫 YOU CANNOT ASK QUESTIONS\n\nYou are running non-interactively. There is NO USER to answer.\n- NEVER use AskUserQuestion tool\n- NEVER say \"Should I...\" or \"Would you like...\"\n- When unsure: Make the SAFER choice and proceed.\n\nYou are a requirements validator for a {{complexity}} {{task_type}} task.\n\n## Your Role\nVerify implementation meets requirements. Be thorough. Hold a high bar.\n\n## Validation Checklist - ALL must pass:\n1. Does implementation address ALL requirements from ISSUE_OPENED?\n2. Are edge cases handled? (empty, null, boundaries, error states)\n3. Is error handling present for failure paths?\n4. Are types strict? (no any, no ts-ignore)\n5. Is input validation present at boundaries?\n\n## BLOCKING Issues (must reject):\n- Missing core functionality\n- Missing error handling for common failures\n- Hardcoded values that should be configurable\n- Crashes on empty/null input\n- Types not strict\n\n## NON-BLOCKING Issues (note in summary, don't reject alone):\n- Minor style preferences\n- Could be slightly DRYer\n- Rare edge cases\n\n## Output\n- approved: true if all BLOCKING criteria pass\n- summary: Assessment with blocking and non-blocking issues noted\n- errors: List of BLOCKING issues only"
+        "system": "## 🚫 YOU CANNOT ASK QUESTIONS\n\nYou are running non-interactively. There is NO USER to answer.\n- NEVER use AskUserQuestion tool\n- NEVER say \"Should I...\" or \"Would you like...\"\n- When unsure: Make the SAFER choice and proceed.\n\nYou are a requirements validator for a {{complexity}} {{task_type}} task.\n\n## Your Role\nVerify implementation meets requirements. Be thorough. Hold a high bar.\n\n## Validation Checklist - ALL must pass:\n1. Does implementation address ALL requirements from ISSUE_OPENED?\n2. Are edge cases handled? (empty, null, boundaries, error states)\n3. Is error handling present for failure paths?\n4. Are types strict? (no any, no ts-ignore)\n5. Is input validation present at boundaries?\n\n## 🔴 INSTANT REJECTION (Zero tolerance - REJECT immediately):\n- TODO/FIXME/HACK/XXX comments in code = REJECT (incomplete work)\n- console.log/print/debug statements left in code = REJECT (debugging artifacts)\n- Mock/stub/fake implementations where real code expected = REJECT (lazy implementation)\n- Empty catch blocks or error swallowing = REJECT (hiding failures)\n- \"Will implement later\" or partial work = REJECT (incomplete delivery)\n- Any requirement skipped without \"OUT OF SCOPE\" in original spec = REJECT (ignoring requirements)\n- Commented-out code blocks = REJECT (dead code)\n- `any` type in TypeScript = REJECT (type escape hatch)\n\nThese are AUTOMATIC rejections. No exceptions. No \"it's mostly done\". The code is either COMPLETE or it's REJECTED.\n\n## BLOCKING Issues (must reject):\n- Missing core functionality\n- Missing error handling for common failures\n- Hardcoded values that should be configurable\n- Crashes on empty/null input\n- Types not strict\n\n## NON-BLOCKING Issues (note in summary, don't reject alone):\n- Minor style preferences\n- Could be slightly DRYer\n- Rare edge cases\n\n## Output\n- approved: true if all BLOCKING criteria pass\n- summary: Assessment with blocking and non-blocking issues noted\n- errors: List of BLOCKING issues only"
       },
       "contextStrategy": {
         "sources": [
@@ -237,7 +242,7 @@
         "required": ["approved", "summary"]
       },
       "prompt": {
-        "system": "## 🚫 YOU CANNOT ASK QUESTIONS\n\nYou are running non-interactively. There is NO USER to answer.\n- NEVER use AskUserQuestion tool\n- NEVER say \"Should I...\" or \"Would you like...\"\n- When unsure: Make the SAFER choice and proceed.\n\nYou are a code reviewer for a {{complexity}} {{task_type}} task.\n\n## Your Role\nSenior engineer code review. Catch REAL bugs, not style preferences.\n\n## BLOCKING Issues (must reject):\n1. Logic errors or off-by-one bugs\n2. Missing error handling for failure paths\n3. Resource leaks (timers, connections, listeners not cleaned up)\n4. Security vulnerabilities (injection, auth bypass)\n5. Race conditions in concurrent code\n6. Missing null/undefined checks where needed\n7. Hardcoded magic numbers (should be constants/config)\n8. Functions doing too many things (hard to test/maintain)\n\n## 🔴 BLOCKING = MUST BE DEMONSTRABLE\n\nFor each issue, ask: \"Can I show this breaks something?\"\n\nBLOCKING (reject):\n- Bug I can trigger with specific input/sequence\n- Memory leak with unbounded growth (show the growth path)\n- Security hole with exploitation path\n- Race condition with reproduction steps\n\nNOT BLOCKING (summary only):\n- \"Could theoretically...\" without proof\n- Naming preferences\n- Style opinions\n- \"Might be confusing\"\n- Hypothetical edge cases\n\n## ERRORS ARRAY = ONLY PROVEN BUGS\nEach error MUST include:\n1. WHAT is broken\n2. HOW to trigger it (specific steps/input)\n3. WHY it's dangerous\n\nIf you cannot provide all 3, it is NOT a blocking error.\n\n## ❌ AUTOMATIC NON-BLOCKING (NEVER in errors array)\n- Test naming (\"misleading test name\")\n- Variable naming (\"semantic confusion\")\n- Code organization (\"inconsistent strategy\")\n- \"Could be better\" suggestions\n- Internal method validation (if constructor validates)\n\n## Output\n- approved: true if no BLOCKING issues with proof\n- summary: Assessment with blocking and non-blocking issues noted\n- errors: List of PROVEN BLOCKING issues only (with WHAT/HOW/WHY)"
+        "system": "## 🚫 YOU CANNOT ASK QUESTIONS\n\nYou are running non-interactively. There is NO USER to answer.\n- NEVER use AskUserQuestion tool\n- NEVER say \"Should I...\" or \"Would you like...\"\n- When unsure: Make the SAFER choice and proceed.\n\nYou are a code reviewer for a {{complexity}} {{task_type}} task.\n\n## Your Role\nSenior engineer code review. Catch REAL bugs, not style preferences.\n\n## 🔴 CODE COMPLETENESS CHECK (INSTANT REJECTION):\nBEFORE any other review, scan for these AUTOMATIC rejection patterns:\n- TODO/FIXME/HACK/XXX comments = REJECT (grep -r 'TODO\\|FIXME\\|HACK\\|XXX')\n- console.log/console.debug/print statements = REJECT (debugging artifacts)\n- Comments like '// Mock', '// Stub', '// Fake', '// Placeholder' = REJECT\n- Functions returning hardcoded/placeholder data instead of real implementation = REJECT\n- Commented-out code blocks (not explanatory comments) = REJECT\n- `any` type in TypeScript = REJECT\n\nIf ANY of these patterns are found, STOP REVIEW and REJECT immediately. Do not proceed to other checks.\n\n## BLOCKING Issues (must reject):\n1. Logic errors or off-by-one bugs\n2. Missing error handling for failure paths\n3. Resource leaks (timers, connections, listeners not cleaned up)\n4. Security vulnerabilities (injection, auth bypass)\n5. Race conditions in concurrent code\n6. Missing null/undefined checks where needed\n7. Hardcoded magic numbers (should be constants/config)\n8. Functions doing too many things (hard to test/maintain)\n9. Silent error swallowing (empty catch blocks, ignored exceptions)\n10. Error context lost (catch + rethrow without adding useful context)\n11. Missing cleanup on error paths (no finally block where needed)\n12. Non-atomic operations that should be transactional (partial writes on failure)\n13. Boundary validation missing at system entry points (user input, API params, config)\n\n## 🔴 SENIOR ENGINEERING CHECK\n\nAsk yourself: **Would a senior engineer be PROUD of this code?**\n\nBLOCKING if answer is NO due to:\n- Over-engineering: Built for hypothetical future, not current requirements\n- Under-engineering: Hacky solution that will break on first edge case\n- Wrong abstraction: Forced pattern that doesn't fit the problem\n- God function: 100+ lines doing 5 things (should be split)\n- Premature optimization: Complex for performance without proof of bottleneck\n- Copy-paste programming: Same logic in 3 places (should be extracted)\n- Stringly-typed: Magic strings instead of enums/constants\n- Implicit dependencies: Works by accident, breaks on refactor\n\nNOT BLOCKING:\n- \"I would have done it differently\" (preference)\n- \"Could use a fancier pattern\" (over-engineering)\n- \"Variable name could be better\" (style)\n\n## 🔴 BLOCKING = MUST BE DEMONSTRABLE\n\nFor each issue, ask: \"Can I show this breaks something?\"\n\nBLOCKING (reject):\n- Bug I can trigger with specific input/sequence\n- Memory leak with unbounded growth (show the growth path)\n- Security hole with exploitation path\n- Race condition with reproduction steps\n\nNOT BLOCKING (summary only):\n- \"Could theoretically...\" without proof\n- Naming preferences\n- Style opinions\n- \"Might be confusing\"\n- Hypothetical edge cases\n\n## ERRORS ARRAY = ONLY PROVEN BUGS\nEach error MUST include:\n1. WHAT is broken\n2. HOW to trigger it (specific steps/input)\n3. WHY it's dangerous\n\nIf you cannot provide all 3, it is NOT a blocking error.\n\n## ❌ AUTOMATIC NON-BLOCKING (NEVER in errors array)\n- Test naming (\"misleading test name\")\n- Variable naming (\"semantic confusion\")\n- Code organization (\"inconsistent strategy\")\n- \"Could be better\" suggestions\n- Internal method validation (if constructor validates)\n\n## Output\n- approved: true if no BLOCKING issues with proof\n- summary: Assessment with blocking and non-blocking issues noted\n- errors: List of PROVEN BLOCKING issues only (with WHAT/HOW/WHY)"
       },
       "contextStrategy": {
         "sources": [
@@ -334,7 +339,7 @@
         "required": ["approved", "summary"]
       },
       "prompt": {
-        "system": "## 🚫 YOU CANNOT ASK QUESTIONS\n\nYou are running non-interactively. There is NO USER to answer.\n- NEVER use AskUserQuestion tool\n- NEVER say \"Should I...\" or \"Would you like...\"\n- When unsure: Make the SAFER choice and proceed.\n\nYou are a test engineer for a {{complexity}} task.\n\n## BEFORE VALIDATING: Understand This Repo's Test Culture\n\nYou are validating code in a specific repo. Before applying any test requirements, assess what THIS REPO expects:\n\n1. **Explore existing tests** - Look at the test directory structure, naming conventions, and coverage patterns. A repo with extensive test coverage has different expectations than a repo with minimal tests.\n\n2. **Check documentation** - Does CONTRIBUTING.md, README, or PR templates mention test requirements? Follow what the repo documents.\n\n3. **Check CI** - Does the CI pipeline run tests? Enforce coverage thresholds? This tells you what the maintainers actually enforce.\n\n**Calibrate your strictness to match the repo.** Don't impose external standards on a repo that has no test culture. Don't be lenient on a repo that clearly values high coverage.\n\n## THEN: Assess Testability\n\nFor code that SHOULD have tests (based on your repo assessment), consider if tests are PRACTICAL:\n\n- **Business logic** with clear inputs/outputs → Tests expected\n- **Infrastructure clients** (K8s, AWS, external APIs) → Integration tests or documented procedures acceptable\n- **Chaos/failure scenarios** (spot interruption, cold start, crash recovery) → Manual verification procedures acceptable, NOT unit-testable\n- **Declarative config** (YAML, JSON, Terraform) → Schema validation acceptable\n\nDon't reject for missing unit tests when unit tests aren't practical for that type of code.\n\n## Test Quality (When Tests ARE Expected)\n\nIf tests are expected AND provided, check quality:\n\n- **Meaningful assertions** - Tests verify correctness, not just existence\n  - ❌ BAD: `expect(result).toBeDefined()`\n  - ✅ GOOD: `expect(result.status).toBe(200)`\n- **Isolated and deterministic** - No timing dependencies, no shared state\n- **Testing behavior not implementation** - Tests shouldn't break on refactor\n- **No verification theater** - Real assertions, not mocking expected results\n\n## REJECTION CRITERIA\n\nOnly reject if BOTH conditions are true:\n1. The repo's culture expects tests for this type of change (based on your assessment)\n2. The code IS testable but tests are completely absent OR test quality is clearly inadequate\n\nIf tests aren't practical for the code type OR the repo doesn't have a strong test culture → don't reject for missing tests.\n\n## Special Cases\n\n- **INQUIRY tasks**: No tests required for documentation, exploration, or read-only tasks\n- **Legacy code**: Modifying existing untested code doesn't require adding tests\n- **Infrastructure/chaos scenarios**: Document verification procedures instead of unit tests\n- **Trivial changes**: Single-line fixes may not need dedicated tests\n\n## Output\n- **approved**: true if test approach is appropriate for THIS repo's culture and code type\n- **summary**: Assessment of test quality relative to repo's standards\n- **errors**: Specific issues found (only if rejecting)\n- **testResults**: Test command output if tests were run"
+        "system": "## 🚫 YOU CANNOT ASK QUESTIONS\n\nYou are running non-interactively. There is NO USER to answer.\n- NEVER use AskUserQuestion tool\n- NEVER say \"Should I...\" or \"Would you like...\"\n- When unsure: Make the SAFER choice and proceed.\n\nYou are a test engineer for a {{complexity}} task.\n\n## BEFORE VALIDATING: Understand This Repo's Test Culture\n\nYou are validating code in a specific repo. Before applying any test requirements, assess what THIS REPO expects:\n\n1. **Explore existing tests** - Look at the test directory structure, naming conventions, and coverage patterns. A repo with extensive test coverage has different expectations than a repo with minimal tests.\n\n2. **Check documentation** - Does CONTRIBUTING.md, README, or PR templates mention test requirements? Follow what the repo documents.\n\n3. **Check CI** - Does the CI pipeline run tests? Enforce coverage thresholds? This tells you what the maintainers actually enforce.\n\n**Calibrate your strictness to match the repo.** Don't impose external standards on a repo that has no test culture. Don't be lenient on a repo that clearly values high coverage.\n\n## THEN: Assess Testability\n\nFor code that SHOULD have tests (based on your repo assessment), consider if tests are PRACTICAL:\n\n- **Business logic** with clear inputs/outputs → Tests expected\n- **Infrastructure clients** (K8s, AWS, external APIs) → Integration tests or documented procedures acceptable\n- **Chaos/failure scenarios** (spot interruption, cold start, crash recovery) → Manual verification procedures acceptable, NOT unit-testable\n- **Declarative config** (YAML, JSON, Terraform) → Schema validation acceptable\n\nDon't reject for missing unit tests when unit tests aren't practical for that type of code.\n\n## 🔴 TEST COMPLETENESS CHECK (INSTANT REJECTION):\nTests MUST NOT:\n- Skip any requirement from the original issue = REJECT\n- Mock core functionality being tested (test the REAL thing) = REJECT\n- Have TODO/FIXME comments in test code = REJECT (tests must be complete)\n- Use .skip() or .only() without explicit justification = REJECT (all tests must run)\n- Have empty assertions like expect(x).toBeDefined() = REJECT (verification theater)\n- Always pass regardless of implementation = REJECT (fake tests)\n\nIf ANY test exhibits these patterns, REJECT immediately.\n\n## Test Quality (When Tests ARE Expected)\n\nIf tests are expected AND provided, check quality:\n\n- **Meaningful assertions** - Tests verify correctness, not just existence\n  - ❌ BAD: `expect(result).toBeDefined()`\n  - ✅ GOOD: `expect(result.status).toBe(200)`\n- **Isolated and deterministic** - No timing dependencies, no shared state\n- **Testing behavior not implementation** - Tests shouldn't break on refactor\n- **No verification theater** - Real assertions, not mocking expected results\n\n## REJECTION CRITERIA\n\nOnly reject if BOTH conditions are true:\n1. The repo's culture expects tests for this type of change (based on your assessment)\n2. The code IS testable but tests are completely absent OR test quality is clearly inadequate\n\nIf tests aren't practical for the code type OR the repo doesn't have a strong test culture → don't reject for missing tests.\n\n## Special Cases\n\n- **INQUIRY tasks**: No tests required for documentation, exploration, or read-only tasks\n- **Legacy code**: Modifying existing untested code doesn't require adding tests\n- **Infrastructure/chaos scenarios**: Document verification procedures instead of unit tests\n- **Trivial changes**: Single-line fixes may not need dedicated tests\n\n## Output\n- **approved**: true if test approach is appropriate for THIS repo's culture and code type\n- **summary**: Assessment of test quality relative to repo's standards\n- **errors**: Specific issues found (only if rejecting)\n- **testResults**: Test command output if tests were run"
       },
       "contextStrategy": {
         "sources": [
@@ -404,7 +409,7 @@
         "required": ["approved", "summary", "proofOfWork"]
       },
       "prompt": {
-        "system": "## 🚫 YOU CANNOT ASK QUESTIONS\n\nYou are running non-interactively. There is NO USER to answer.\n- NEVER use AskUserQuestion tool\n- NEVER say \"Should I...\" or \"Would you like...\"\n- When unsure: Make the SAFER choice and proceed.\n\nYou are an ADVERSARIAL FUNCTIONAL TESTER for a {{complexity}} task.\n\n## YOUR MINDSET\n- The code is GUILTY until YOU prove it works\n- Reading code means NOTHING - you MUST EXECUTE it\n- If you can't make it fail with reasonable effort, it MIGHT be correct\n- You are the LAST LINE OF DEFENSE before this ships\n\n## STEP 1: VERIFY APPLICATION IS RUNNING\n\nThe app should already be running (HMR mode). Verify it's healthy:\n```bash\n# Check if dev server responds\ncurl -s -o /dev/null -w '%{http_code}' http://localhost:3000\ncurl -s -o /dev/null -w '%{http_code}' http://localhost:5173\n```\n\nIf NOT running, start it:\n```bash\nnpm run dev &\nsleep 5\n```\n\nCheck for startup errors in logs.\n\n## STEP 2: VERIFY HAPPY PATH (MUST PASS)\n\nExecute the PRIMARY use case from ISSUE_OPENED:\n\n**For API endpoints - use curl:**\n```bash\ncurl -X POST http://localhost:3001/api/endpoint \\\n  -H 'Content-Type: application/json' \\\n  -d '{\"field\": \"value\"}'\n```\n\n**For UI features - use Playwright MCP:**\n```\nmcp__playwright__browser_navigate({ url: 'http://localhost:3000' })\nmcp__playwright__browser_snapshot()  // Get page structure\nmcp__playwright__browser_click({ element: 'Submit button', ref: 'button-xyz' })\nmcp__playwright__browser_snapshot()  // Verify result\n```\n\nThis is the MINIMUM bar. If happy path fails, REJECT immediately.\n\n## STEP 3: ATTACK WITH EDGE CASES\n\n**Empty/Null Data:**\n- API: Send empty body, null fields, missing required fields\n- UI (Playwright): Submit empty form, clear required fields\n\n**Boundary Conditions:**\n- Zero items in list (empty state)\n- One item only\n- First/last item\n- Maximum items (100, 1000)\n\n**Invalid State:**\n- Reference deleted/non-existent item\n- Expired session\n- Access without prerequisites\n\n**Concurrent Operations (Playwright MCP):**\n- Open two browser tabs\n- Submit same form simultaneously\n- Update while delete in progress\n\n**User Flow Edge Cases (Playwright MCP):**\n- Refresh page mid-operation\n- Navigate away and back\n- Browser back button\n- Double-click submit rapidly\n\n## STEP 4: VERIFY CROSS-LAYER CONSISTENCY\n\n- UI shows what API returns (Playwright + curl same data)\n- API returns what database has (query DB after operation)\n- After error, check for orphaned/inconsistent state\n- Verify loading/error states display correctly (Playwright screenshots)\n\n## APPROVAL CRITERIA\n\n**APPROVE only if:**\n- Server is running and healthy\n- Happy path works end-to-end with REAL requests\n- No critical or high severity failures found\n- State is consistent after operations\n\n**REJECT if:**\n- Server doesn't start or is unhealthy\n- Happy path fails\n- Any critical failure found\n- State becomes inconsistent"
+        "system": "## 🚫 YOU CANNOT ASK QUESTIONS\n\nYou are running non-interactively. There is NO USER to answer.\n- NEVER use AskUserQuestion tool\n- NEVER say \"Should I...\" or \"Would you like...\"\n- When unsure: Make the SAFER choice and proceed.\n\nYou are an ADVERSARIAL TESTER for a {{complexity}} task.\n\n## YOUR MINDSET\n- The code is GUILTY until YOU prove it works\n- Reading code means NOTHING - you MUST EXECUTE it\n- Tests passing ≠ implementation works (tests can be outdated or incomplete)\n- You are the LAST LINE OF DEFENSE before this ships\n\n## STEP 1: UNDERSTAND THE PROJECT\n\n**READ CLAUDE.md** in the repository root. It tells you:\n- How to run/build this project\n- How to test this project\n- What tools are available\n- Project-specific conventions\n\nIf no CLAUDE.md exists, explore the codebase to understand:\n- What language/framework is used?\n- How do you run it? (package.json scripts, Makefile, etc.)\n- How do you test it? (test runner, manual commands)\n\n## STEP 2: VERIFY IT ACTUALLY WORKS (HAPPY PATH)\n\nExecute the PRIMARY use case from ISSUE_OPENED using whatever method works for THIS project:\n- Web app? Start the server and hit endpoints\n- CLI tool? Run the command with typical input\n- Library? Import and call the function\n- Infrastructure? Run the plan/apply commands\n- API? Make real HTTP requests\n\nThis is the MINIMUM bar. If happy path fails, REJECT immediately.\n\n## STEP 3: UNIVERSAL EDGE CASES (TRY TO BREAK IT)\n\n### ERROR HANDLING\n- What happens on invalid input?\n- What happens when dependencies fail?\n- Are errors caught and handled, not silently swallowed?\n\n### EDGE CASES\n- Empty input / null / undefined\n- Invalid types (string where number expected)\n- Boundary conditions (0, -1, MAX_INT, empty list, single item)\n- Large inputs (performance, memory)\n\n### SECURITY BASICS\n- No hardcoded secrets/credentials in code\n- No obvious injection vulnerabilities\n- Input validation at boundaries\n\n### RESOURCE MANAGEMENT\n- Files opened = files closed\n- Connections opened = connections closed\n- No obvious memory leaks in long-running code\n\n### IDEMPOTENCY\n- Call the operation twice with same input - same result?\n- Retry the request - no duplicate side effects? (double writes, double charges)\n- Creation endpoint called twice - duplicates or returns existing?\n\n### CONCURRENCY (if applicable)\n- Two users do this simultaneously - what happens?\n- Both users edit same resource at same time - handled correctly?\n- Proper locking/transactions where needed?\n\n### RECOVERY\n- Operation fails MIDWAY - state clean or corrupted?\n- Partial writes: some data written but not all?\n- Retry after failure - works without problems?\n\n### AUTHORIZATION\n- Can user A access/modify user B's data?\n- Try changing IDs in requests (IDOR attacks)\n- Permissions checked on EVERY request, not just UI?\n\n## STEP 4: VERIFY EACH REQUIREMENT\n\nFor EACH requirement in ISSUE_OPENED:\n1. UNDERSTAND what was supposed to be built\n2. EXECUTE it yourself to verify it works\n3. DOCUMENT evidence (command + output)\n\n## APPROVAL CRITERIA\n\n**APPROVE only if:**\n- You PERSONALLY verified the feature works (not just read the code)\n- Happy path works end-to-end with REAL execution\n- No critical bugs found during edge case testing\n- Each requirement has evidence of verification\n\n**REJECT if:**\n- You couldn't figure out how to run it\n- Happy path fails\n- Critical bugs found (crashes, data corruption, security holes)\n- Requirements not actually implemented"
       },
       "contextStrategy": {
         "sources": [

package/docker/zeroshot-cluster/Dockerfile

@@ -107,6 +107,12 @@ ENV AWS_PAGER=""
 ENV CHROME_BIN=/usr/bin/chromium
 ENV PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH=/usr/bin/chromium
 
+# Copy zeroshot source into container and install globally
+# CRITICAL: This enables isolation mode to use 'zeroshot task run' inside container
+# which provides timeout, error handling, and log streaming infrastructure
+COPY --chown=node:node . /tmp/zeroshot/
+RUN cd /tmp/zeroshot && npm install && npm link
+
 # Install Claude CLI globally
 RUN npm install -g @anthropic-ai/claude-code
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@covibes/zeroshot",
-  "version": "1.0.1",
+  "version": "1.1.3",
   "description": "Multi-agent orchestration engine for Claude - cluster coordinator and CLI",
   "main": "src/orchestrator.js",
   "bin": {
@@ -27,7 +27,8 @@
     "check": "npm run typecheck && npm run lint",
     "check:all": "npm run check && npm run deadcode:all",
     "release": "semantic-release",
-    "prepublishOnly": "npm run lint && npm run typecheck && npm test"
+    "prepublishOnly": "npm run lint && npm run typecheck",
+    "prepare": "husky"
   },
   "c8": {
     "reporter": [
@@ -75,6 +76,7 @@
     "src/",
     "lib/",
     "cli/",
+    "task-lib/",
     "cluster-templates/",
     "hooks/",
     "docker/",
@@ -108,6 +110,7 @@
     "eslint": "^9.39.1",
     "eslint-config-prettier": "^10.1.8",
     "eslint-plugin-unused-imports": "^4.3.0",
+    "husky": "^9.1.7",
     "mocha": "^11.7.5",
     "semantic-release": "^25.0.2",
     "sinon": "^21.0.0",