@liriraid/agentflow-ai 1.0.20 → 1.0.22

package/templates/en/agents/OPENCODE.md

@@ -1,42 +1,62 @@
-# 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
-```
+# OpenCode Agent
+
+## Role
+
+OpenCode is a **multi-purpose agent** capable of **analysis, exploration, and code implementation**.
+Its capabilities depend on the model you have configured in your OpenCode installation.
+
+## Scope
+
+### Analysis (Always available)
+- Codebase audits
+- Flow and architecture exploration
+- Context reading before implementation
+- Read-only smoke tests
+- Structured Markdown reports
+- Identifying dead code, missing dependencies, inconsistencies
+
+### Implementation
+- Implementing new features
+- Modifying project files
+- Writing new tests
+- Refactoring code
+- Fixing bugs
+
+## General Rules
+
+1. Do not commit or push.
+2. If the task is **analysis**: deliver findings in Markdown tables and write the report in `progress/PROGRESS-OpenCode.md`
+3. If the task is **implementation**: modify the necessary files and document the changes
+4. Always deliver a TASK_REPORT at the end
+
+## Assignment Priority
+
+- **First choice for implementation**: Codex (when available)
+- **Second choice for implementation**: OpenCode
+- **Third choice**: Claude-Worker (Backend/Frontend)
+
+## Completion Report (REQUIRED)
+
+### For analysis tasks:
+```
+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
+```
+
+### For implementation tasks:
+```
+TASK_REPORT
+status: completed | failed | blocked
+files_modified: ["src/file1.js", "src/file2.ts"]
+files_created: ["src/new-file.js"]
+files_deleted: ["src/old-file.js"]
+summary: 1-3 sentences describing the changes made
+issues: problems or "none"
+TASK_REPORT_END
+```

package/templates/en/docs/usage.md

@@ -5,7 +5,7 @@
 ### 1. Install the CLI
 
 ```bash
-npm i -g @liriraid/agentflow-ai
+pnpm add -g @liriraid/agentflow-ai
 ```
 
 ### 2. Create a sibling orchestrator workspace

package/templates/en/orchestrator.config.json

@@ -50,49 +50,42 @@
       "cli": "claude",
       "profile": "claude",
       "defaultRepo": "backend",
-      "model": "sonnet",
       "instructionsFile": "agents/BACKEND.md"
     },
     "Frontend": {
       "cli": "claude",
       "profile": "claude",
       "defaultRepo": "frontend",
-      "model": "sonnet",
       "instructionsFile": "agents/FRONTEND.md"
     },
     "Codex": {
       "cli": "codex",
       "profile": "codex",
       "defaultRepo": "frontend",
-      "model": "gpt-5.5",
       "instructionsFile": "agents/CODEX.md"
     },
     "Gemini": {
       "cli": "gemini",
       "profile": "gemini",
       "defaultRepo": "frontend",
-      "model": "auto",
       "instructionsFile": "agents/GEMINI.md"
     },
     "OpenCode": {
       "cli": "opencode",
       "profile": "opencode",
       "defaultRepo": "frontend",
-      "model": "auto",
       "instructionsFile": "agents/OPENCODE.md"
     },
     "Cursor": {
       "cli": "cursor",
       "profile": "cursor",
       "defaultRepo": "backend",
-      "model": "auto",
       "instructionsFile": "agents/CURSOR.md"
     },
     "Abacus": {
       "cli": "abacusai",
       "profile": "abacusai",
       "defaultRepo": "backend",
-      "model": "auto",
       "instructionsFile": "agents/ABACUS.md"
     }
   }

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

@@ -1,20 +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');
+#!/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

@@ -1,24 +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"
-          }
-        ]
-      }
-    ]
-  }
-}
+{
+  "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,33 +1,34 @@
----
-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.
+---
+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 **SOLO OpenCode** como agente de exploración cuando necesites análisis profundo del codebase — su rol es **EXCLUSIVAMENTE análisis**, **NUNCA 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.
+- **REGLA ESTRICTA: 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, bajo ninguna circunstancia, vuelvas a analizar el código tú mismo (Claude-Orquestador) si OpenCode ya lo hizo. Lee el reporte en `progress/PROGRESS-OpenCode.md` o el INBOX.md y basa tus decisiones en ese análisis.**
+- Si el reporte de OpenCode es insuficiente, pide a OpenCode que profundice en un área específica con una nueva TASK de análisis, pero NO lo hagas tú directamente.
+
+## Resultado esperado
+
+Una exploración útil que permita al orquestador decidir si ya puede crear TASKs o si necesita una investigación adicional. **El resultado final DEBE ser una o más TASKs en QUEUE.md asignadas a Codex o Claude-Worker para implementación, NO más análisis por parte de Claude-Orquestador.**

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

@@ -1,52 +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.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.
+---
+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/AGENT-CONFIG.md

@@ -58,7 +58,8 @@ Cuando haya varias tareas independientes, el reparto recomendado es mantener ocu
 Para este proyecto reusable:
 
 - `claude` es el profile principal
-- `codex` y `opencode` son profiles de apoyo
+- `codex` es el profile de implementación primaria
+- `opencode` es el profile de apoyo que **puede implementar código** dependiendo del modelo configurado en tu instalación de OpenCode
 - otros profiles pueden existir, aunque no estén habilitados por defecto
 
 ## Directorios locales sugeridos
@@ -79,5 +80,5 @@ Si existe configuración global del agente en el home del usuario y también una
 
 - `Claude` usa `.claude/skills/` como base principal del proyecto
 - `Codex` y `OpenCode` pueden tener configuración local propia aunque hoy no usen el mismo modelo de skills
-- `OpenCode` no es solo auditor: puede explorar, auditar e implementar cuando la TASK esté clara
+- `OpenCode` no es solo auditor: puede explorar, auditar e **implementar código** — las capacidades dependen del modelo configurado en tu instalación de OpenCode
 - el diseño debe permitir que mañana también tengan una capa local más rica

package/templates/es/ORCHESTRATOR.md

@@ -134,6 +134,8 @@ del .away-mode
 
 La TUI gestiona el fallback automáticamente siguiendo esta cadena:
 
+```
+Codex falla → OpenCode → Frontend (repo FE) o Backend (repo BE)
 ```
 Codex falla  →  Frontend (repo FE) o Backend (repo BE) directamente
 ```
@@ -164,22 +166,25 @@ Revisa `orchestrator.config.json` → `agents`. Cada entrada tiene:
 **Agentes por defecto en esta plantilla:**
 | Nombre | CLI | Mejor para |
 |--------|-----|------------|
-| Backend | claude (sonnet) | Código server-side: controllers, models, migrations y tests |
-| 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 |
+| Backend | claude | Código server-side: controllers, models, migrations y tests |
+| Frontend | claude | Código UI: componentes, páginas y estilos |
+| Codex | codex | **Primera opción para implementación**; docs, migraciones y tareas estructuradas con spec clara |
+| OpenCode | opencode | **Segunda opción para implementación**; exploración, auditorías y reportes estructurados |
 | Gemini | gemini | Auditorías, code review; suele sufrir con `node_modules` muy grandes |
-| 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 |
 
+**Notas sobre OpenCode:**
+- OpenCode puede realizar tanto análisis como implementación — las capacidades dependen del modelo que tengas configurado en tu instalación de OpenCode.
+
 ## Cómo asignar trabajo
 
 1. **Cuando el usuario pide un cambio o nueva tarea** → **NUNCA analices directamente**
-   - **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
+- **Si necesita análisis previo**: Crea una TASK en `QUEUE.md` asignada **EXCLUSIVAMENTE** a **OpenCode** para que explore el contexto
+- **Espera el reporte**: OpenCode escribe hallazgos en `progress/PROGRESS-OpenCode.md` y notifica en `INBOX.md`
+- **Luego implementa**: **LEE EL REPORTE DE OPENCODE** en `progress/PROGRESS-OpenCode.md` o `INBOX.md` y crea nueva TASK asignada a **Codex** (o Claude-Worker si Codex no está disponible)
+- **OpenCode NO implementa** — sus TASKs son **SOLO de análisis**; la implementación **SIEMPRE** va a Codex o Claude-Worker
+- **NUNCA, bajo ninguna circunstancia, analices el código del proyecto directamente tú mismo (Claude-Orquestador)** — **ESO ES TRABAJO EXCLUSIVO DE OPENCODE**. Si ya existe un reporte de OpenCode, **USA ESE CONTEXTO** para crear tareas de implementación.
 
 2. Escribe TASKs en `QUEUE.md` (formato pipe; la TUI lo lee):
     ```
@@ -191,8 +196,9 @@ 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. **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:
+7. **Codex es la primera opción para implementación; OpenCode es la segunda opción.** Claude-Worker es el fallback automático de Codex/OpenCode y también toma trabajo cuando hay más tareas que agentes disponibles.
+8. **REGLA CRÍTICA SOBRE ANÁLISIS:** Si OpenCode ya analizó algo y escribió su reporte en `INBOX.md` o `progress/PROGRESS-OpenCode.md`, **TÚ (Claude-Orquestador) NO DEBES VOLVER A ANALIZAR EL MISMO CÓDIGO**. Usa el reporte existente para crear tareas de implementación. Si necesitas más detalles, pide a OpenCode que haga un análisis adicional con una nueva TASK, pero **NUNCA lo hagas tú directamente**.
+9. Distribución según cantidad de TASKs independientes:
    - **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).
@@ -210,8 +216,12 @@ 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 → 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 → OpenCode → 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. **VERIFICACIÓN OBLIGATORIA:** Antes de crear cualquier TASK de implementación, **LEE Y CONFIRMA QUE:**
+   - Existe un reporte de OpenCode en `INBOX.md` o `progress/PROGRESS-OpenCode.md` para el análisis solicitado.
+   - La TASK de implementación se basa **EXCLUSIVAMENTE** en el reporte de OpenCode.
+   - **NO** has analizado el código tú mismo (Claude-Orquestador).
 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.
 

package/templates/es/PROJECT.md

@@ -44,7 +44,7 @@ Esto evita ensuciar el repo del producto con:
 La instalación recomendada para usuarios finales es:
 
 ```bash
-npm i -g @liriraid/agentflow-ai
+pnpm add -g @liriraid/agentflow-ai
 ```
 
 Después, por cada proyecto real:
@@ -61,7 +61,7 @@ La variante con `npx` sigue siendo válida:
 npx @liriraid/agentflow-ai-ai init-workspace C:/code/mi-proyecto
 ```
 
-No se recomienda `npm install @liriraid/agentflow-ai-ai  dentro del repo del producto, porque eso lo vuelve una dependencia local del proyecto en vez de una herramienta global del entorno.
+No se recomienda `pnpm add @liriraid/agentflow-ai` dentro del repo del producto, porque eso lo vuelve una dependencia local del proyecto en vez de una herramienta global del entorno.
 
 ## Regla de permisos