@liriraid/agentflow-ai 1.0.18 → 1.0.20

package/orchestrator.js

@@ -122,6 +122,7 @@ const config = JSON.parse(fs.readFileSync(CONFIG_FILE, "utf-8"));
 
 const QUEUE_FILE = path.join(WORKSPACE, "QUEUE.md");
 const INBOX_FILE = path.join(WORKSPACE, "INBOX.md");
+const NOTIFY_FILE = path.join(WORKSPACE, "NOTIFY.md");
 const AWAY_MODE_FILE = path.join(WORKSPACE, ".away-mode");
 const LOG_DIR = path.join(WORKSPACE, "logs");
 
@@ -266,6 +267,11 @@ const TEXT = {
     inboxReasonLabel: "- **Motivo:**",
     inboxNewAgentLabel: "- **Nuevo agente:**",
     inboxFailAction: "- **Acción:** La TUI reasignó automáticamente. Verifica en QUEUE.md o espera la siguiente notificación de completada.",
+    // NOTIFY.md — notificación concisa a la sesión interactiva de Claude
+    notifyComplete: (ts, id, agent, dur) => `🔔 [${ts}] ${id} completada por ${agent} (${dur}).\nRevisa INBOX.md y crea la siguiente tarea de implementación en QUEUE.md si aún no existe.`,
+    notifyFailed: (ts, id, from, to, reason) => `⚠️ [${ts}] ${id} falló en ${from} → reasignada a ${to}.\nMotivo: ${reason}\nRevisa INBOX.md para el contexto.`,
+    notifyPermanentFail: (ts, id, agent) => `🚨 [${ts}] ${id} falló permanentemente en ${agent} (sin más reintentos).\nDecide si eliminar, reasignar o escalar la tarea en QUEUE.md.`,
+    notifyRateLimit: (ts, id, agent, resetStr, retries, max) => `⏳ [${ts}] ${id} — ${agent} alcanzó el límite de tokens (reintento ${retries}/${max}, ${resetStr}).\nSi quieres reasignar ahora: asigna a Claude-Worker (Frontend). Si esperas, reintentará automáticamente.`,
   },
   en: {
     configExists:
@@ -370,6 +376,11 @@ const TEXT = {
     inboxReasonLabel: "- **Reason:**",
     inboxNewAgentLabel: "- **New agent:**",
     inboxFailAction: "- **Action:** TUI reassigned automatically. Check QUEUE.md or wait for the next completion notification.",
+    // NOTIFY.md — concise notification to the interactive Claude session
+    notifyComplete: (ts, id, agent, dur) => `🔔 [${ts}] ${id} completed by ${agent} (${dur}).\nCheck INBOX.md and create the next implementation task in QUEUE.md if it does not exist yet.`,
+    notifyFailed: (ts, id, from, to, reason) => `⚠️ [${ts}] ${id} failed on ${from} → reassigned to ${to}.\nReason: ${reason}\nCheck INBOX.md for context.`,
+    notifyPermanentFail: (ts, id, agent) => `🚨 [${ts}] ${id} permanently failed on ${agent} (no more retries).\nDecide whether to remove, reassign, or escalate the task in QUEUE.md.`,
+    notifyRateLimit: (ts, id, agent, resetStr, retries, max) => `⏳ [${ts}] ${id} — ${agent} hit token/rate limit (retry ${retries}/${max}, ${resetStr}).\nTo reassign now: assign to Claude-Worker (Frontend). Otherwise it will retry automatically.`,
   },
 };
 const L = TEXT[WORKSPACE_LANGUAGE];
@@ -1064,6 +1075,15 @@ function writeInboxFailureNotification(task, failedAgent, newAgent, reason) {
   } catch {}
 }
 
+// Escribe una notificación concisa en NOTIFY.md para la sesión interactiva de Claude.
+// Los hooks de .claude/settings.json leen y limpian este archivo automáticamente.
+function writeNotifyFile(message) {
+  try {
+    const sep = fs.existsSync(NOTIFY_FILE) ? '\n---\n' : '';
+    fs.appendFileSync(NOTIFY_FILE, sep + message + '\n', 'utf-8');
+  } catch {}
+}
+
 // GAP 2 — Move a task line from ## Pending to ## In Progress when it starts
 function moveTaskToInProgress(task) {
   if (!fs.existsSync(QUEUE_FILE)) return;
@@ -1523,6 +1543,7 @@ function completeTask(task, agentName) {
   ag.lastLine = L.lastCompleted(task.id);
   updateQueueFile(task);
   writeInboxNotification(task, agentName, elapsed);
+  writeNotifyFile(L.notifyComplete(timestamp(), task.id, agentName, formatDuration(elapsed)));
   scheduleNext();
   renderDashboard();
 }
@@ -1591,6 +1612,7 @@ function failTask(task, agentName, code) {
       `{yellow-fg}${escBl(L.agentRateLimit(resetStr))}{/yellow-fg}`,
       true,
     );
+    writeNotifyFile(L.notifyRateLimit(timestamp(), task.id, agentName, resetStr, retries, maxRetries));
   } else {
     log("FAIL", L.logFail(agentName, task.id, code, retries, maxRetries));
     appendToAgent(
@@ -1622,6 +1644,7 @@ function failTask(task, agentName, code) {
           : L.reasonPersistent;
     if (tryFallbackToAlternative(task, agentName, reason)) {
       writeInboxFailureNotification(task, agentName, task.agent, reason);
+      writeNotifyFile(L.notifyFailed(timestamp(), task.id, agentName, task.agent, reason));
       setTimeout(() => {
         scheduleNext();
         safeRenderDashboard();
@@ -1634,6 +1657,7 @@ function failTask(task, agentName, code) {
     task.status = "failed";
     ag.lastLine = L.lastFailed(task.id);
     log("ERROR", L.logPermanentFail(task.id, retries));
+    writeNotifyFile(L.notifyPermanentFail(timestamp(), task.id, agentName));
   } else {
     task.status = "pending";
     let retryDelay = rl.isRateLimit
@@ -1817,7 +1841,6 @@ function getClaudeFallbackAgent(task) {
 }
 
 function getAlternativeSupportAgent(failedAgentName) {
-  if (failedAgentName === "Codex") return "OpenCode";
   if (failedAgentName === "OpenCode") return "Codex";
   return null;
 }
@@ -1825,7 +1848,7 @@ function getAlternativeSupportAgent(failedAgentName) {
 function tryFallbackToAlternative(task, failedAgentName, reason) {
   if (!["Codex", "OpenCode"].includes(failedAgentName)) return false;
 
-  // Step 1: try sibling support agent (Codex → OpenCode, OpenCode → Codex)
+  // Step 1: try sibling support agent (OpenCode → Codex only; Codex falls through directly)
   const siblingAgent = getAlternativeSupportAgent(failedAgentName);
   const siblingAvailable =
     siblingAgent &&
@@ -1931,16 +1954,18 @@ setInterval(() => {
   if (command) applyControlCommand(command);
 }, 1000);
 
-// Real-time queue detection via fs.watch — fires immediately when QUEUE.md changes
-// (e.g. Claude writes a new task). No more 30s delay.
+// Real-time queue detection — watches WORKSPACE directory (not the file directly)
+// because on Windows fs.watch on a file is unreliable; watching the parent dir
+// and filtering by filename is the stable pattern (same as AWAY MODE watcher).
 let _queueWatchDebounce = null;
 function startQueueWatcher() {
-  if (!fs.existsSync(QUEUE_FILE)) return;
   try {
-    const watcher = fs.watch(QUEUE_FILE, {persistent: false}, (eventType) => {
-      if (eventType !== 'change') return;
+    const watchName = path.basename(QUEUE_FILE);
+    const watcher = fs.watch(WORKSPACE, {persistent: false}, (eventType, filename) => {
+      if (filename !== watchName) return;
       if (_queueWatchDebounce) clearTimeout(_queueWatchDebounce);
       _queueWatchDebounce = setTimeout(() => {
+        if (!fs.existsSync(QUEUE_FILE)) return;
         const prevCount = state.queue.length;
         reloadQueue();
         if (!state.paused) scheduleNext();
@@ -2042,8 +2067,9 @@ function startInboxWatcher() {
     try { fs.writeFileSync(INBOX_FILE, '', 'utf-8'); } catch {}
   }
   try {
-    const watcher = fs.watch(INBOX_FILE, {persistent: false}, (eventType) => {
-      if (eventType !== 'change') return;
+    const watchName = path.basename(INBOX_FILE);
+    const watcher = fs.watch(WORKSPACE, {persistent: false}, (eventType, filename) => {
+      if (filename !== watchName) return;
       if (_inboxDebounce) clearTimeout(_inboxDebounce);
       _inboxDebounce = setTimeout(dispatchInboxClaude, 100);
     });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@liriraid/agentflow-ai",
-  "version": "1.0.18",
+  "version": "1.0.20",
   "description": "Multi-agent workspace orchestrator with TUI. Coordinates AI coding agents over your real frontend and backend projects.",
   "author": "LiriRaid",
   "homepage": "https://github.com/LiriRaid/agentflow-ai#readme",

package/src/ink/index.mjs

@@ -393,11 +393,16 @@ function shutdown() {
 }
 
 // Reactivo: dispara un refresh inmediato cuando el engine escribe el STATE_FILE.
-// Esto elimina el lag de polling para cambios de cola y estado de agentes.
+// Vigila el directorio logs/ (no el archivo directamente) porque en Windows
+// fs.watch sobre un archivo es poco confiable — el patrón estable es vigilar
+// el directorio padre y filtrar por nombre de archivo.
 function ensureStateWatcher() {
-	if (stateWatcher || !fs.existsSync(STATE_FILE)) return;
+	const logsDir = path.dirname(STATE_FILE);
+	const stateFileName = path.basename(STATE_FILE);
+	if (stateWatcher || !fs.existsSync(logsDir)) return;
 	try {
-		stateWatcher = fs.watch(STATE_FILE, {persistent: false}, () => {
+		stateWatcher = fs.watch(logsDir, {persistent: false}, (eventType, filename) => {
+			if (filename !== stateFileName) return;
 			if (stateWatchDebounce) clearTimeout(stateWatchDebounce);
 			stateWatchDebounce = setTimeout(() => {
 				if (quitRequested) return;

package/templates/en/.claude/hooks/notify-check.js

@@ -0,0 +1,20 @@
+#!/usr/bin/env node
+'use strict';
+// Reads NOTIFY.md from the workspace and writes its content to stdout so the
+// Claude Code hook injects it into the interactive session.
+// The file is deleted after reading to avoid repeating the notification.
+const fs = require('fs');
+const path = require('path');
+
+const notifyFile = path.join(process.cwd(), 'NOTIFY.md');
+if (!fs.existsSync(notifyFile)) process.exit(0);
+
+const content = fs.readFileSync(notifyFile, 'utf8').trim();
+if (!content) {
+  try { fs.unlinkSync(notifyFile); } catch {}
+  process.exit(0);
+}
+
+try { fs.unlinkSync(notifyFile); } catch {}
+
+process.stdout.write('\n' + content + '\n');

package/templates/en/.claude/settings.json

@@ -0,0 +1,24 @@
+{
+  "hooks": {
+    "Stop": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node .claude/hooks/notify-check.js"
+          }
+        ]
+      }
+    ],
+    "UserPromptSubmit": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node .claude/hooks/notify-check.js"
+          }
+        ]
+      }
+    ]
+  }
+}

package/templates/en/.claude/skills/orchestrator-explore/SKILL.md

@@ -1,29 +1,31 @@
----
-name: orchestrator-explore
-description: >
-  Explore, analyze, or investigate the project before proposing or delegating implementation.
-license: MIT
-metadata:
-  owner: agentflow
-  version: "1.0"
----
-
-# Skill: orchestrator-explore
-
-## Purpose
-
-Gather useful context before creating TASKs or OpenSpec artifacts.
-
-## Critical Rules
-
-- Understand the user's exact scope first.
-- Prefer exploration before implementation when context is unclear.
-- Use OpenCode as the first support worker for broad reading, audits, and structured findings when appropriate.
-- Do not fill `QUEUE.md` with implementation tasks until enough context exists.
-- Summarize findings in actionable terms: what exists, what is missing, what risks exist, and what tasks follow.
-- If the change is large or multi-phase, move toward OpenSpec.
-- If work is clear, convert findings into concrete TASKs.
-
-## Expected Result
-
-The orchestrator can decide whether to plan TASKs or continue investigation.
+---
+name: orchestrator-explore
+description: >
+  Explore, analyze, or investigate the project before proposing or delegating implementation.
+license: MIT
+metadata:
+  owner: agentflow
+  version: "1.1"
+---
+
+# Skill: orchestrator-explore
+
+## Purpose
+
+Gather useful context before creating TASKs or OpenSpec artifacts.
+
+## Critical Rules
+
+- Understand the user's exact scope first.
+- Prefer exploration before implementation when context is unclear.
+- Use `OpenCode` as the exploration agent when deep codebase analysis is needed — its role is **analysis only**, not implementation.
+- When delegating exploration to OpenCode, include in the brief exactly what it must report: flows, dependencies, architecture findings, inconsistencies, etc.
+- Do not fill `QUEUE.md` with implementation tasks until enough context exists.
+- Summarize findings in actionable terms: what exists, what is missing, what risks exist, and what tasks follow.
+- If the change is large or multi-phase, move toward OpenSpec.
+- If work is clear, convert findings into concrete TASKs using `orchestrator-queue-planning`.
+- When OpenCode delivers its report in INBOX.md, use those findings to create implementation TASKs (assigned to Codex or Claude-Worker — never back to OpenCode).
+
+## Expected Result
+
+The orchestrator can decide whether to plan TASKs or continue investigation.

package/templates/en/.claude/skills/orchestrator-queue-planning/SKILL.md

@@ -1,31 +1,50 @@
----
-name: orchestrator-queue-planning
-description: >
-  Convert user requests, specs, or findings into concrete TASK entries for QUEUE.md.
-license: MIT
-metadata:
-  owner: agentflow
-  version: "1.0"
----
-
-# Skill: orchestrator-queue-planning
-
-## Purpose
-
-Turn the user's request into executable queue work for the TUI.
-
-## Critical Rules
-
-- Create small, concrete, executable TASKs.
-- Every TASK must include agent, priority, repo, and a clear description.
-- Use `> after:TASK-NNN` for dependencies.
-- Do not implement the task directly as Claude-Orchestrator.
-- Prefer assigning first executable work to `Codex` or `OpenCode` when they are suitable.
-- Use Claude-Worker only for fallback, extra capacity, sensitive work, broad implementation, or when explicitly requested.
-- Codex can work in `repo=frontend`, but only for narrow, clear, verifiable tasks.
-- Broad frontend work should go to `Frontend`/Claude-Worker.
-- Keep `QUEUE.md` aligned with the user's current objective.
-
-## Expected Result
-
-`QUEUE.md` contains clear TASKs ready for the TUI to run.
+---
+name: orchestrator-queue-planning
+description: >
+  Convert user requests, specs, or findings into concrete TASK entries for QUEUE.md.
+license: MIT
+metadata:
+  owner: agentflow
+  version: "1.1"
+---
+
+# Skill: orchestrator-queue-planning
+
+## Purpose
+
+Turn the user's request into executable queue work for the TUI.
+
+## Agent Assignment Rules
+
+### OpenCode — analysis only
+- Use for exploration, audits, context reading, and structured reports.
+- **Do not assign implementation** — OpenCode does not modify project files.
+- If work needs prior analysis, create an OpenCode TASK first, then a Codex TASK with `> after:TASK-NNN`.
+
+### Codex — primary implementation
+- Use for implementation, code changes, tests, and docs when the spec is clear.
+- It is the primary execution agent.
+- If Codex fails persistently, the TUI automatically reassigns to Claude-Worker (Frontend/Backend).
+
+### Claude-Worker (Frontend / Backend)
+- Automatic fallback when Codex fails.
+- Also takes overflow work when both Codex and OpenCode are busy and more tasks are pending.
+- Frontend-only projects: always use `Frontend`; backend work: use `Backend`.
+
+## Critical Rules
+
+- Create small, concrete, executable TASKs.
+- Every TASK must include agent, priority, repo, and a clear description.
+- Use `> after:TASK-NNN` for dependencies.
+- Do not implement the task directly as Claude-Orchestrator.
+- Distribution by task count:
+  - **1 analysis task**: OpenCode
+  - **1 implementation task**: Codex
+  - **2 parallel tasks**: OpenCode (analysis) + Codex (implementation when spec is clear)
+  - **3+ tasks** with Codex busy: overflow goes to `Frontend` (FE repo) or `Backend` (BE repo)
+- Keep `QUEUE.md` aligned with the user's current objective.
+- **Never assign implementation to OpenCode.**
+
+## Expected Result
+
+`QUEUE.md` contains clear TASKs ready for the TUI to run.

package/templates/en/ORCHESTRATOR.md

@@ -36,12 +36,14 @@ When the user requests work after startup:
 
 1. Do not implement the work in the interactive Claude session.
 2. Convert the request into one or more TASKs in `QUEUE.md`.
-3. Always assign first to `OpenCode` (exploration) and `Codex` (implementation).
+3. Assign by role:
+   - `OpenCode` → **analysis only** (exploration, audits, reports — does NOT modify code)
+   - `Codex` → **primary implementation** (code changes, tests, docs)
 4. Assign a Claude-Worker (`Frontend` or `Backend`) **only** when:
-   - **Multiple independent tasks exist** AND Codex + OpenCode are both already occupied, OR
-   - A task has **permanently failed** in Codex AND OpenCode — then Claude-Worker takes it as last resort.
+   - **Multiple independent tasks exist** AND Codex is already occupied, OR
+   - A task has **permanently failed** in Codex — then Claude-Worker takes it as last resort.
 
-The TUI handles automatic fallback: Codex fails → tries OpenCode → tries Claude-Worker. You only need to manually assign Claude-Workers for load balancing (case a) or when the TUI marks a task as permanently `failed` (case b).
+The TUI handles automatic fallback: Codex fails → Claude-Worker directly. You only need to manually assign Claude-Workers for load balancing (case a) or when the TUI marks a task as permanently `failed` (case b).
 
 The `repo` field determines the working directory: `frontend` for UI/client work, `backend` for API/server work. Codex and OpenCode can work in either repo depending on the task.
 
@@ -120,9 +122,7 @@ del .away-mode
 The TUI handles fallback automatically following this chain:
 
 ```
-Codex fails  →  tries OpenCode (if idle and not rate-limited)
-                    ↓ (if OpenCode also fails or is blocked)
-             →  Frontend (frontend repo) or Backend (backend repo) as last resort
+Codex fails  →  Frontend (frontend repo) or Backend (backend repo) directly
 ```
 
 As Orchestrator you do **not** need to manually reassign on failure — the TUI does it. Your role is:
@@ -147,7 +147,7 @@ Default agent summary:
 | Backend | claude | Backend code through Claude-Worker |
 | Frontend | claude | Broad frontend work through Claude-Worker |
 | Codex | codex | Structured implementation, tests, docs, narrow frontend support |
-| OpenCode | opencode | Exploration, audits, structured reports, scoped implementation |
+| OpenCode | opencode | Exploration, audits, structured reports — analysis only, does not implement code |
 | Gemini | gemini | Optional audits and reviews only when explicitly enabled |
 | Cursor | cursor | Optional mechanical bulk edits only when explicitly enabled |
 | Abacus | abacusai | Optional small focused tasks only when explicitly enabled |
@@ -155,10 +155,11 @@ Default agent summary:
 ## How To Assign Work
 
 1. **When the user asks for a change or new task** → **NEVER analyze directly yourself**
-   - **First**: Create a TASK in `QUEUE.md` assigned to **OpenCode** to analyze the context
-   - **Second**: Wait for OpenCode to finish its analysis (check INBOX.md or progress/)
-   - **Third**: You receive the analysis → create new TASK to implement (Codex or OpenCode)
-   - **Never analyze the project code yourself** - that's OpenCode's job
+   - **If prior analysis is needed**: Create a TASK in `QUEUE.md` assigned to **OpenCode** to explore the context
+   - **Wait for the report**: OpenCode writes findings in INBOX.md or progress/
+   - **Then implement**: Create a new TASK assigned to **Codex** (or Claude-Worker if Codex is unavailable)
+   - **OpenCode does not implement** — its TASKs are always analysis; implementation goes to Codex or Claude-Worker
+   - **Never analyze the project code yourself** — that is OpenCode's job
 
 2. Write TASKs in `QUEUE.md` with this format:
 
@@ -177,10 +178,10 @@ Rules:
 
 Routing preferences:
 
-1. Start with Codex/OpenCode when a task is clear enough for them.
-2. Keep Claude-Worker available as fallback or extra capacity.
-3. For frontend, use Codex for narrow tasks and Frontend/Claude-Worker for broad UI or complex interaction work.
-4. Use OpenCode for exploration, audits, and scoped implementation.
+1. Use OpenCode for exploration, audits, and analysis. Never for implementation.
+2. Use Codex as the primary implementation agent when the spec is clear.
+3. Keep Claude-Worker available as automatic fallback for Codex and for overflow tasks.
+4. For frontend, use Codex for narrow tasks and Frontend/Claude-Worker for broad UI work.
 5. Do not assign all tasks to Claude just because Claude is the orchestrator.
 
 ## Hard Rules
@@ -200,11 +201,10 @@ Routing preferences:
 
 ```bash
 cd <workspace-path>
-node orchestrator.js
+agentflow ink
 ```
 
-- `R`: reload `QUEUE.md`
-- `S`: start or resume
+- `S`: resume (Paused → Running)
 - `P`: pause
 - `Q`: quit and stop agents
 

package/templates/en/agents/OPENCODE.md

@@ -1,41 +1,42 @@
-# OpenCode Agent
-
-## Role
-
-OpenCode is used for exploration, context reading, audits, structured reports, and scoped implementation.
-
-It is not only an auditor. If the TASK asks for implementation and the scope is clear, make concrete code changes.
-
-## Scope
-
-- codebase audits
-- context exploration
-- smoke tests
-- endpoint verification
-- structured Markdown reports
-- scoped implementation
-- small or medium refactors
-- tests and technical docs
-
-## Rules
-
-1. Do not commit or push.
-2. Keep findings structured and actionable.
-3. Use Markdown tables for audit findings when useful.
-4. If implementing, leave the result ready for Claude-Orchestrator review.
-5. Do not stay in analysis mode when the TASK explicitly asks for implementation.
-
-## Completion Report
-
-Always finish with:
-
-```text
-TASK_REPORT
-status: completed | failed | blocked
-files_modified: list or "none"
-files_created: list or "none"
-files_deleted: list or "none"
-summary: 1-3 sentences
-issues: problems or "none"
-TASK_REPORT_END
-```
+# OpenCode Agent
+
+## Role
+
+OpenCode is an **analysis and exploration only** agent. It reads code, generates structured reports, and delivers findings to `INBOX.md` so the Orchestrator can decide next steps. It does not implement code changes.
+
+## Scope
+
+- Codebase audits
+- Flow and architecture exploration
+- Context reading before implementation
+- Read-only smoke tests (no modifications)
+- Structured Markdown reports
+- Identifying dead code, missing dependencies, inconsistencies
+
+## Out of Scope
+
+- Modifying project files
+- Implementing features or refactors
+- Writing new tests
+- Creating or deleting files
+
+## Rules
+
+1. Do not commit or push.
+2. Do not modify real project files.
+3. Always deliver findings in Markdown tables when listing multiple items.
+4. Write the completion report in `progress/PROGRESS-OpenCode.md`.
+5. If the TASK requests implementation, report in TASK_REPORT: `status: blocked`, `issues: "OpenCode is analysis-only — reassign to Codex or Claude-Worker"`
+
+## Completion Report (REQUIRED)
+
+```
+TASK_REPORT
+status: completed | failed | blocked
+files_modified: none
+files_created: none
+files_deleted: none
+summary: 1-3 sentences describing findings
+issues: problems or "none"
+TASK_REPORT_END
+```

package/templates/es/.claude/hooks/notify-check.js

@@ -0,0 +1,20 @@
+#!/usr/bin/env node
+'use strict';
+// Lee NOTIFY.md del workspace y vuelca el contenido a stdout para que
+// el hook de Claude Code lo inyecte en la sesión interactiva.
+// El archivo se elimina después de leerse para no repetir la notificación.
+const fs = require('fs');
+const path = require('path');
+
+const notifyFile = path.join(process.cwd(), 'NOTIFY.md');
+if (!fs.existsSync(notifyFile)) process.exit(0);
+
+const content = fs.readFileSync(notifyFile, 'utf8').trim();
+if (!content) {
+  try { fs.unlinkSync(notifyFile); } catch {}
+  process.exit(0);
+}
+
+try { fs.unlinkSync(notifyFile); } catch {}
+
+process.stdout.write('\n' + content + '\n');

package/templates/es/.claude/settings.json

@@ -0,0 +1,24 @@
+{
+  "hooks": {
+    "Stop": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node .claude/hooks/notify-check.js"
+          }
+        ]
+      }
+    ],
+    "UserPromptSubmit": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node .claude/hooks/notify-check.js"
+          }
+        ]
+      }
+    ]
+  }
+}

package/templates/es/.claude/skills/orchestrator-explore/SKILL.md

@@ -1,31 +1,33 @@
----
-name: orchestrator-explore
-description: >
-  Explora, analiza o investiga el proyecto antes de proponer cambios. Ideal cuando el usuario pide entender archivos, flujos o arquitectura antes de delegar implementación.
-  Trigger: "explora", "analiza", "investiga", "revisa este proyecto", "revisa estos archivos"
-license: MIT
-metadata:
-  owner: agentflow
-  version: "0.1"
----
-
-# Skill: orchestrator-explore
-
-## Propósito
-
-Guiar la fase de exploración del orquestador para reunir contexto útil antes de crear o delegar tareas.
-
-## Reglas críticas
-
-- Empieza por entender el alcance exacto del pedido del usuario.
-- Si hace falta lectura amplia, prioriza exploración y análisis antes de planear implementación.
-- Usa `OpenCode` como primer apoyo para lectura, contexto y hallazgos estructurados cuando aplique.
-- No llenes `QUEUE.md` con implementación hasta tener suficiente contexto.
-- Resume hallazgos en términos accionables: qué existe, qué falta, qué riesgo hay y qué tareas salen de eso.
-- Si la exploración revela un cambio grande o multifase, el siguiente paso natural es abrir o actualizar un change en `openspec/`.
-- Si descubres una línea clara de trabajo, el siguiente paso natural es convertir hallazgos en TASKs concretas.
-- Mantén el foco dentro del alcance pedido; explorar no es rediseñar todo el sistema.
-
-## Resultado esperado
-
-Una exploración útil que permita al orquestador decidir si ya puede crear TASKs o si necesita una investigación adicional.
+---
+name: orchestrator-explore
+description: >
+  Explora, analiza o investiga el proyecto antes de proponer cambios. Ideal cuando el usuario pide entender archivos, flujos o arquitectura antes de delegar implementación.
+  Trigger: "explora", "analiza", "investiga", "revisa este proyecto", "revisa estos archivos"
+license: MIT
+metadata:
+  owner: agentflow
+  version: "0.2"
+---
+
+# Skill: orchestrator-explore
+
+## Propósito
+
+Guiar la fase de exploración del orquestador para reunir contexto útil antes de crear o delegar tareas.
+
+## Reglas críticas
+
+- Empieza por entender el alcance exacto del pedido del usuario.
+- Si hace falta lectura amplia, prioriza exploración y análisis antes de planear implementación.
+- Usa `OpenCode` como agente de exploración cuando necesites análisis profundo del codebase — su rol es **solo análisis**, no implementación.
+- Al delegar exploración a OpenCode, incluye en el brief exactamente qué debe reportar: flujos, dependencias, hallazgos de arquitectura, inconsistencias, etc.
+- No llenes `QUEUE.md` con implementación hasta tener suficiente contexto.
+- Resume hallazgos en términos accionables: qué existe, qué falta, qué riesgo hay y qué tareas salen de eso.
+- Si la exploración revela un cambio grande o multifase, el siguiente paso natural es abrir o actualizar un change en `openspec/`.
+- Si descubres una línea clara de trabajo, el siguiente paso natural es convertir hallazgos en TASKs concretas con `orchestrator-queue-planning`.
+- Mantén el foco dentro del alcance pedido; explorar no es rediseñar todo el sistema.
+- Cuando OpenCode entregue su reporte en INBOX.md, usa esos hallazgos para crear las TASKs de implementación (asignadas a Codex o Claude-Worker, nunca de vuelta a OpenCode).
+
+## Resultado esperado
+
+Una exploración útil que permita al orquestador decidir si ya puede crear TASKs o si necesita una investigación adicional.

package/templates/es/.claude/skills/orchestrator-queue-planning/SKILL.md

@@ -1,35 +1,52 @@
----
-name: orchestrator-queue-planning
-description: >
-  Convierte contexto y hallazgos en tareas concretas para QUEUE.md, con prioridades, agente objetivo y dependencias claras.
-  Trigger: "crea tareas", "planifica en queue", "divide el trabajo", "delegar tareas", "llenar queue"
-license: MIT
-metadata:
-  owner: agentflow
-  version: "0.1"
----
-
-# Orchestrator Queue Planning
-
-## Propósito
-
-Traducir una necesidad del usuario o hallazgos de exploración en tareas concretas para el motor del orquestador.
-
-## Reglas críticas
-
-- Escribe TASKs pequeñas, concretas y ejecutables.
-- Cada tarea debe tener agente, prioridad, repo y descripción clara.
-- Usa dependencias `> after:TASK-NNN` cuando una tarea no pueda arrancar todavía.
-- Prioriza mantener ocupados los agentes permitidos por defecto sin inventar trabajo fuera del alcance.
-- Si el trabajo es exploratorio, usa primero `OpenCode`; si es ejecución estructurada, reparte según el dominio.
-- Cuando haya 3 o más tareas independientes, intenta crear una primera tanda con al menos una TASK para un Claude-Worker (`Backend` o `Frontend`), una para `Codex` y una para `OpenCode`.
-- `OpenCode` puede implementar código cuando la tarea esté clara; no lo limites a lectura o auditoría si la cola necesita ejecución.
-- Codex puede trabajar en `repo=frontend`, pero con menor permisividad: úsalo para apoyo acotado y verificable; deja los cambios amplios de FE al agente `Frontend` de Claude.
-- Si Codex u OpenCode fallan por cuota, tokens, rate limit o indisponibilidad persistente, crea o reasigna una TASK de fallback a un Claude-Worker.
-- Si existe un `openspec/changes/<change-name>/tasks.md`, usa ese archivo como fuente de verdad para traducirlo a `QUEUE.md`.
-- No sobrecargues una sola IA con demasiadas tareas si puedes paralelizar sin riesgo.
-- Mantén `QUEUE.md` coherente con el objetivo actual del usuario.
-
-## Resultado esperado
-
-Una cola clara y accionable que el motor pueda despachar de inmediato.
+---
+name: orchestrator-queue-planning
+description: >
+  Convierte contexto y hallazgos en tareas concretas para QUEUE.md, con prioridades, agente objetivo y dependencias claras.
+  Trigger: "crea tareas", "planifica en queue", "divide el trabajo", "delegar tareas", "llenar queue"
+license: MIT
+metadata:
+  owner: agentflow
+  version: "0.2"
+---
+
+# Orchestrator Queue Planning
+
+## Propósito
+
+Traducir una necesidad del usuario o hallazgos de exploración en tareas concretas para el motor del orquestador.
+
+## Reglas de asignación de agentes
+
+### OpenCode — análisis solamente
+- Úsalo para exploración, auditorías, lectura de contexto y reportes estructurados
+- **No le asignes implementación** — OpenCode no modifica archivos del proyecto
+- Si el trabajo necesita análisis previo, crea primero una TASK de OpenCode y luego una de Codex con dependencia `> after:TASK-NNN`
+
+### Codex — implementación principal
+- Úsalo para implementación, cambios de código, tests y docs técnicas cuando la spec esté clara
+- Es el agente primario de ejecución
+- Si Codex falla persistentemente, la TUI reasigna automáticamente a Claude-Worker (Frontend/Backend)
+
+### Claude-Worker (Frontend / Backend)
+- Es el fallback automático cuando Codex falla
+- También puede tomar trabajo cuando Codex y OpenCode están ambos ocupados y hay más tareas pendientes
+- Para proyectos solo frontend: usar siempre `Frontend`; para backend: `Backend`
+
+## Reglas críticas
+
+- Escribe TASKs pequeñas, concretas y ejecutables.
+- Cada tarea debe tener agente, prioridad, repo y descripción clara.
+- Usa dependencias `> after:TASK-NNN` cuando una tarea no pueda arrancar todavía.
+- No sobrecargues una sola IA con demasiadas tareas si puedes paralelizar sin riesgo.
+- Distribución según cantidad de TASKs independientes:
+  - **1 tarea de análisis**: OpenCode
+  - **1 tarea de implementación**: Codex
+  - **2 tareas paralelas**: OpenCode (análisis) + Codex (implementación si la spec ya es clara)
+  - **3+ tareas** y Codex ocupado: el excedente va a `Frontend` (repo FE) o `Backend` (repo BE)
+- Si existe un `openspec/changes/<change-name>/tasks.md`, úsalo como fuente de verdad.
+- Mantén `QUEUE.md` coherente con el objetivo actual del usuario.
+- **No asignes implementación a OpenCode** bajo ninguna circunstancia.
+
+## Resultado esperado
+
+Una cola clara y accionable que el motor pueda despachar de inmediato.

package/templates/es/ORCHESTRATOR.md

@@ -19,13 +19,14 @@ Hay dos roles distintos que no deben confundirse:
 **Prioridad de asignación de trabajo:**
 
 ```
-OpenCode / Codex  →  primera opción siempre (exploración e implementación)
-Claude-Worker     →  último recurso, solo en estos dos casos:
-  a) Múltiples TASKs independientes Y Codex + OpenCode ambos ocupados → Claude-Worker toma 1
-  b) Codex falló persistentemente Y OpenCode también falló → Claude-Worker toma la tarea
+OpenCode   →  análisis y exploración (NO implementa código)
+Codex      →  implementación principal (primera opción para ejecución)
+Claude-Worker → fallback automático cuando Codex falla, o cuando hay más tareas que agentes disponibles
+  a) Múltiples TASKs independientes Y Codex ocupado → Claude-Worker toma el excedente
+  b) Codex falló persistentemente → la TUI reasigna automáticamente a Claude-Worker
 ```
 
-El Orquestador NO asigna a Claude-Worker en la primera tanda si solo hay 1 tarea o si Codex/OpenCode están disponibles. La TUI gestiona el fallback automático al fallar un agente.
+El Orquestador NO asigna implementación a OpenCode. OpenCode solo analiza y reporta hallazgos. La TUI gestiona el fallback automático al fallar Codex.
 
 ## El workspace NO es el proyecto real
 
@@ -134,9 +135,7 @@ del .away-mode
 La TUI gestiona el fallback automáticamente siguiendo esta cadena:
 
 ```
-Codex falla  →  intenta OpenCode (si está libre y sin rate limit)
-                    ↓ (si OpenCode también falla o está bloqueado)
-             →  Frontend (repo FE) o Backend (repo BE) como último recurso
+Codex falla  →  Frontend (repo FE) o Backend (repo BE) directamente
 ```
 
 Como Orquestador, **no necesitas reasignar manualmente** cuando hay un fallo — la TUI lo hace sola. Tu rol en este caso es:
@@ -169,17 +168,18 @@ Revisa `orchestrator.config.json` → `agents`. Cada entrada tiene:
 | Frontend | claude (sonnet) | Código UI: componentes, páginas y estilos |
 | Codex | codex | Docs, migraciones y tareas estructuradas con spec clara; puede apoyar frontend en tareas acotadas |
 | Gemini | gemini | Auditorías, code review; suele sufrir con `node_modules` muy grandes |
-| OpenCode | opencode | Exploración, auditorías, reportes y también implementación cuando la task lo requiera |
+| OpenCode | opencode | Exploración, auditorías y reportes estructurados — solo análisis, no implementa código |
 | Cursor | cursor | Tareas mecánicas de alto volumen: find-and-replace y cleanup |
 | Abacus | abacusai | Tareas pequeñas y enfocadas, con alcance bien acotado |
 
 ## Cómo asignar trabajo
 
 1. **Cuando el usuario pide un cambio o nueva tarea** → **NUNCA analices directamente**
-   - **Primero**: Crea una TASK en `QUEUE.md` asignada a **OpenCode** para que analice el contexto
-   - **Segundo**: Espera a que OpenCode termine su análisis (revisa INBOX.md o progress/)
-   - **Tercero**: Recibes el análisis → creas nueva TASK para implementar (Codex o OpenCode)
-   - **Nunca analices el código del proyecto directamente tu mismo** - eso lo hace OpenCode
+   - **Si necesita análisis previo**: Crea una TASK en `QUEUE.md` asignada a **OpenCode** para que explore el contexto
+   - **Espera el reporte**: OpenCode escribe hallazgos en INBOX.md o progress/
+   - **Luego implementa**: Crea nueva TASK asignada a **Codex** (o Claude-Worker si Codex no está disponible)
+   - **OpenCode no implementa** — sus TASKs son siempre de análisis; la implementación va a Codex o Claude-Worker
+   - **Nunca analices el código del proyecto directamente tú mismo** - eso lo hace OpenCode
 
 2. Escribe TASKs en `QUEUE.md` (formato pipe; la TUI lo lee):
     ```
@@ -191,11 +191,12 @@ Revisa `orchestrator.config.json` → `agents`. Cada entrada tiene:
 4. (Opcional) Para un brief muy detallado, crea `briefs/TASK-NNN-BRIEF.md`; también se inyecta.
 5. Dependencias: agrega `> after:TASK-NNN` al final de la descripción para bloquear la tarea.
 6. **La TUI inicia automáticamente** - NO necesitas presionar R ni S. La TUI detecta nuevas tasks y las lanza.
-7. **Prioriza Codex y OpenCode** para toda implementación y exploración. Claude-Workers solo cuando hay saturación o fallo total de agentes de soporte.
+7. **OpenCode es solo análisis; Codex es la implementación principal.** Claude-Worker es el fallback automático de Codex y también toma trabajo cuando hay más tareas que agentes disponibles.
 7. Distribución según cantidad de TASKs independientes:
-   - **1 tarea**: OpenCode (exploración) o Codex (implementación). Nunca Claude-Worker en primera instancia.
-   - **2 tareas**: OpenCode + Codex, una cada uno.
-   - **3+ tareas** y Codex+OpenCode ambos ocupados: el excedente puede ir a `Frontend` (repo FE) o `Backend` (repo BE) según corresponda.
+   - **1 tarea de análisis**: OpenCode.
+   - **1 tarea de implementación**: Codex. Nunca Claude-Worker en primera instancia.
+   - **2 tareas paralelas**: OpenCode (análisis) + Codex (implementación si la spec está clara).
+   - **3+ tareas** y Codex ocupado: el excedente va a `Frontend` (repo FE) o `Backend` (repo BE) según corresponda.
 8. Si hay más TASKs que agentes disponibles, deja el resto en cola con dependencias claras o prioridad menor; no uses Gemini, Cursor ni Abacus salvo permiso explícito.
 9. El campo `repo` determina en qué directorio trabaja el agente. Usa siempre el valor correcto: `frontend` para trabajo de UI/cliente, `backend` para trabajo de API/servidor. Codex y OpenCode pueden trabajar en ambos repos según lo que indique la task.
 
@@ -209,7 +210,7 @@ Revisa `orchestrator.config.json` → `agents`. Cada entrada tiene:
 6. Al terminar la sesión, escribe un `handoffs/HANDOFF-<fecha>.md` resumiendo qué se hizo y qué sigue.
 7. **Por defecto solo usa Claude, Codex y OpenCode**. No uses Gemini, Cursor ni Abacus salvo instrucción explícita del usuario.
 8. Si el usuario activa **Modo Ausencia**, revisa progreso cada 5 minutos y reasigna nuevas TASKs razonables dentro del alcance actual sin esperar confirmación intermedia.
-9. La TUI gestiona el fallback automáticamente: Codex falla → OpenCode → Claude-Worker (Frontend/Backend según repo). Solo intervén manualmente si la tarea queda marcada `failed`.
+9. La TUI gestiona el fallback automáticamente: Codex falla → Claude-Worker (Frontend/Backend según repo). Solo intervén manualmente si la tarea queda marcada `failed`.
 10. Usa Engram para guardar decisiones, hallazgos, bugs y resúmenes de sesión; no dependas solo del contexto corto de la conversación.
 11. Para cambios grandes, usa `openspec/changes/<change-name>/` para proposal, spec, design, tasks y verify; no dejes todo solo en la conversación.
 12. No asumas bypass total o autoaceptación de cambios en los agentes. Claude debe seguir siendo la autoridad final para validar el resultado esperado antes de que el usuario dé la aprobación definitiva.
@@ -218,11 +219,10 @@ Revisa `orchestrator.config.json` → `agents`. Cada entrada tiene:
 
 ```bash
 cd <ruta-del-workspace>
-node orchestrator.js
+agentflow ink
 ```
 
-- **R** = recargar `QUEUE.md`
-- **S** = iniciar / reanudar
+- **S** = reanudar (Paused → Running)
 - **P** = pausar
 - **Q** = salir (mata todos los agentes)
 

package/templates/es/README.md

@@ -298,23 +298,8 @@ Si en una sesión concreta quieres permitir modo agresivo para entornos de confi
 agentflow ink --yolo
 ```
 
-o:
-
-```bash
-node orchestrator.js --yolo
-```
-
 Ese modo no es el default y debe usarse solo cuando realmente lo decidas.
 
-### Blessed
-
-Sigue existiendo como runtime base histórico:
-
-```bash
-node orchestrator.js
-node orchestrator.js --paused
-```
-
 ## Skills locales del proyecto
 
 Las skills viven en:

package/templates/es/agents/OPENCODE.md

@@ -1,32 +1,42 @@
-# OpenCode Agent
-
-## Rol
-Agente OpenCode. Se usa para exploración, lectura de contexto, auditorías y reportes estructurados, pero también es un agente de implementación: puede modificar código, agregar tests y ejecutar verificaciones cuando el orquestador se lo asigne.
-
-## Alcance
-- Auditorías del codebase: residuos de Bootstrap, MySQL-isms, foreign keys faltantes, etc.
-- Smoke tests y verificación de endpoints
-- Reportes estructurados en Markdown
-- Implementación de cambios cuando la tarea ya está clara y el orquestador lo delega
-- Cambios acotados de código, tests, docs técnicas y refactors pequeños o medianos
-- Exploración previa a implementación cuando el contexto todavía no esté suficientemente claro
-
-## Reglas
-1. Nunca hagas `git commit` ni `git push`
-2. El control de git lo maneja manualmente el usuario
-3. Actualiza `progress/PROGRESS-OpenCode.md` al terminar
-4. Cuando listes hallazgos, entrega los reportes en tablas Markdown
-5. Si implementas cambios, deja el estado listo para que Claude pueda revisar si el resultado coincide con la task
-6. No te limites a auditar si la TASK pide implementación; entrega cambios concretos y verificables dentro del alcance asignado
-
-## Reporte de finalización (OBLIGATORIO)
-```
-TASK_REPORT
-status: completed | failed | blocked
-files_modified: list or "none"
-files_created: list or "none"
-files_deleted: list or "none"
-summary: 1-3 sentences
-issues: problems or "none"
-TASK_REPORT_END
-```
+# Agente OpenCode
+
+## Rol
+
+OpenCode es un agente de **análisis y exploración exclusivamente**. Lee código, genera reportes estructurados y entrega hallazgos a `INBOX.md` para que el Orquestador decida los siguientes pasos. No implementa cambios de código.
+
+## Alcance
+
+- Auditorías del codebase
+- Exploración de flujos y arquitectura
+- Lectura de contexto antes de implementación
+- Smoke tests de lectura (sin modificar nada)
+- Reportes estructurados en Markdown
+- Identificación de residuos, dependencias faltantes, inconsistencias
+
+## Fuera de alcance
+
+- Modificar archivos del proyecto
+- Implementar features o refactors
+- Escribir tests nuevos
+- Crear o borrar archivos
+
+## Reglas
+
+1. Nunca hagas `git commit` ni `git push`
+2. Nunca modifiques archivos del proyecto real
+3. Entrega siempre los hallazgos en tablas Markdown cuando listes varios ítems
+4. Escribe el reporte de finalización en `progress/PROGRESS-OpenCode.md`
+5. Si la TASK pide implementación, reporta en TASK_REPORT: `status: blocked`, `issues: "OpenCode es solo análisis — reasignar a Codex o Claude-Worker"`
+
+## Reporte de finalización (OBLIGATORIO)
+
+```
+TASK_REPORT
+status: completed | failed | blocked
+files_modified: none
+files_created: none
+files_deleted: none
+summary: 1-3 sentences describing findings
+issues: problems or "none"
+TASK_REPORT_END
+```