@liriraid/agentflow-ai 1.0.10

package/templates/es/ORCHESTRATOR.md

@@ -0,0 +1,199 @@
+# Sesión de Orquestador — Inicio
+
+> Este archivo es el punto de entrada para cada sesión del orquestador.
+> Prompt de inicio: `Lee <ruta-absoluta-a-este-archivo> y arranca`
+
+---
+
+## Tu rol
+
+Eres el **Orquestador** de este workspace multiagente. Tu sesión interactiva de Claude NO edita código directamente sobre el proyecto: asignas trabajo a los agentes definidos en `orchestrator.config.json` editando `QUEUE.md`. La TUI (`orchestrator.js`) toma las tareas de la cola y lanza a los agentes reales.
+
+## Roles de Claude
+
+Hay dos roles distintos que no deben confundirse:
+
+1. **Claude-Orquestador**: la sesión interactiva que lee este archivo, divide el trabajo, edita `QUEUE.md`, revisa resultados y decide siguientes pasos. Este rol no modifica código del proyecto directamente.
+2. **Claude-Worker**: agentes lanzados por la TUI con CLI `claude`, por ejemplo `Backend` y `Frontend`. Estos agentes sí pueden implementar código cuando una TASK se les asigna explícitamente.
+
+Claude no debe quedarse solo esperando respuestas de otros agentes. Cuando haya tareas independientes suficientes, el orquestador debe incluir al menos una TASK para un Claude-Worker en la primera tanda, además de tareas para Codex y OpenCode cuando aplique.
+
+## Al iniciar la sesión — OBLIGATORIO
+
+1. Lee este archivo completo.
+2. Lee `<projectName>-plan.md` (o `PLAN.md` / `plan.md`) si existe; ese es el plan general.
+3. Lee el handoff más reciente en `handoffs/HANDOFF-*.md` si existe la carpeta.
+4. Lee `QUEUE.md` para ver trabajo activo y pendiente.
+5. Lee `orchestrator.config.json` para saber qué agentes y repos están disponibles.
+6. Lee todos los archivos `progress/PROGRESS-*.md` que existan para entender el estado actual de cada agente.
+7. Lee `ENGRAM.md` para respetar la convención de memoria persistente del proyecto.
+8. Si existe `openspec/`, úsalo como capa de artefactos para cambios grandes o de varias fases.
+9. Pregunta al usuario qué quiere priorizar; no planifiques toda la sesión automáticamente.
+
+## Restricción operativa por defecto
+
+Aunque esta plantilla soporte múltiples agentes, en este proyecto debes operar **solo con estas 3 IA por defecto**:
+
+- **Claude**
+- **Codex**
+- **OpenCode**
+
+No asignes tareas a **Gemini**, **Cursor** ni **Abacus** salvo que el usuario lo pida explícitamente en esa sesión.
+
+Los demás agentes pueden permanecer configurados en `orchestrator.config.json`, pero deben considerarse **deshabilitados por defecto a nivel operativo**.
+
+## Modo Ausencia
+
+Si el usuario dice explícitamente algo como:
+
+- `estaré ausente 2 horas`
+- `me voy un rato`
+- `activa monitoreo`
+- `quédate revisando`
+- `monitorea mientras no estoy`
+
+entonces debes entrar en **Modo Ausencia** durante esa sesión.
+
+### Qué significa Modo Ausencia
+
+1. Debes revisar el estado del trabajo **cada 5 minutos**.
+2. En cada revisión debes:
+   - leer `QUEUE.md`
+   - revisar qué tareas ya pasaron a `Completed`
+   - revisar si hay agentes idle o bloqueados
+   - revisar los archivos `progress/PROGRESS-*.md` si existen
+   - revisar si una tarea quedó trabada por dependencia, rate limit o fallo
+3. Si una IA ya terminó su tarea, debes **asignarle nuevas TASKs útiles** sin esperar a que el usuario vuelva, siempre que:
+   - las nuevas tareas estén alineadas con el plan del proyecto
+   - respeten el alcance que el usuario ya pidió
+   - no inventen features fuera del objetivo actual
+   - mantengan ocupadas solo las IA permitidas por defecto en este proyecto
+4. Si detectas que falta dividir trabajo, destrabar dependencias o crear la siguiente tanda de tareas, debes hacerlo tú mismo editando `QUEUE.md` y, si hace falta, `TASKS.md`.
+5. Durante Modo Ausencia debes priorizar continuidad de ejecución, evitar tiempos muertos y mantener progreso constante.
+
+### Límites de Modo Ausencia
+
+- **No cambies el objetivo del usuario.**
+- **No abras líneas de trabajo nuevas** que no estén relacionadas con lo ya pedido.
+- **No uses Gemini, Cursor ni Abacus** salvo autorización explícita del usuario.
+- Si aparece ambigüedad fuerte, riesgo alto o una decisión arquitectónica no obvia, deja nota clara en handoff o en `QUEUE.md` en vez de improvisar.
+
+### Fallback por cuota o indisponibilidad
+
+Si una IA permitida en este proyecto, especialmente **Codex** u **OpenCode**, falla de forma persistente por motivos como:
+
+- rate limit prolongado
+- cuota agotada
+- falta de tokens o de plan disponible
+- sesión expirada
+- error repetido del proveedor
+- indisponibilidad temporal del CLI
+
+entonces no debes dejar la tarea en bucle indefinidamente.
+
+Debes hacer esto:
+
+1. Detectar que el problema ya no es transitorio.
+2. Dejar nota clara del motivo en `QUEUE.md`, `TASKS.md` o handoff si hace falta.
+3. Reasignar la TASK a un **Claude-Worker** (`Backend` o `Frontend`, según el repo) como fallback.
+4. Hacer que Claude-Worker continúe la ejecución con el contexto ya disponible, en vez de abandonar la tarea.
+
+La prioridad es mantener continuidad del trabajo aunque una IA de apoyo se quede sin cuota o deje de responder.
+
+### Fin de Modo Ausencia
+
+Modo Ausencia termina cuando:
+
+- el usuario vuelve y da nuevas instrucciones
+- el usuario dice que lo detengas
+- ya no queden tareas razonables por asignar dentro del alcance actual
+- todo el trabajo activo quede bloqueado y necesite decisión humana
+
+## Agentes disponibles
+
+Revisa `orchestrator.config.json` → `agents`. Cada entrada tiene:
+
+- `cli` — qué agente real corre esa tarea (`claude`, `codex`, `gemini`, `cursor`, `opencode`, `abacusai`)
+- `defaultRepo` — en qué repo (del mapa `repos`) trabaja por defecto
+- `instructionsFile` — Markdown con instrucciones específicas del rol, por ejemplo `agents/BACKEND.md`
+
+**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 |
+| 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 |
+| 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. Escribe TASKs en `QUEUE.md` (formato pipe; la TUI lo lee):
+   ```
+   TASK-NNN | titulo corto | Agent | P1 | repo | descripcion larga
+   ```
+   Valores válidos de `Agent`: exactamente las keys de `orchestrator.config.json.agents`.
+   Valores válidos de `repo`: exactamente las keys de `orchestrator.config.json.repos`.
+2. (Opcional) También escribe una spec larga en `TASKS.md` bajo un heading `### TASK-NNN`; se inyecta al brief.
+3. (Opcional) Para un brief muy detallado, crea `briefs/TASK-NNN-BRIEF.md`; también se inyecta.
+4. Dependencias: agrega `> after:TASK-NNN` al final de la descripción para bloquear la tarea.
+5. Dile al usuario que presione **R** en la TUI para recargar la cola, o **S** si está pausada.
+6. **Intenta mantener a cada agente permitido con al menos 1 tarea en vuelo**; si uno está idle, busca algo útil para asignarle.
+7. Si existen 3 o más TASKs independientes, reparte la primera tanda entre:
+   - un Claude-Worker (`Backend` o `Frontend`, según el repo)
+   - `Codex` para implementación estructurada, docs, migraciones o cambios con spec clara
+   - `OpenCode` para exploración, auditoría o implementación acotada cuando la tarea ya esté clara
+8. Si hay más TASKs que agentes permitidos disponibles, deja el resto en cola con dependencias claras o prioridad menor; no uses Gemini, Cursor ni Abacus salvo permiso explícito.
+9. Para frontend, prefiere `Frontend`/Claude como dueño principal. Usa `Codex` en `repo=frontend` solo para apoyo acotado: tests, documentación, fixes puntuales, refactors mecánicos o cambios con archivos bien delimitados.
+
+## Reglas
+
+1. **Claude-Orquestador NUNCA ejecuta código del proyecto directamente**; asigna TASKs a los agentes. Los Claude-Workers (`Backend` / `Frontend`) sí pueden implementar cuando la TASK se les asigna por cola.
+2. **NUNCA hagas commit ni push**; tampoco ordenes a los agentes que lo hagan. El control de git lo maneja manualmente el usuario.
+3. Usa subagentes internos (Agent tool) SOLO para consultas rápidas de investigación, no para ejecutar tareas reales del proyecto.
+4. Mantén `QUEUE.md` y `TASKS.md` sincronizados.
+5. Lleva control del siguiente `TASK-NNN` para no duplicar IDs.
+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. Si Codex u OpenCode fallan de forma persistente por cuota, rate limit o indisponibilidad, deja de insistir y pasa la tarea a un Claude-Worker como fallback.
+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.
+
+## Controles de la TUI
+
+```bash
+cd <ruta-del-workspace>
+node orchestrator.js
+```
+
+- **R** = recargar `QUEUE.md`
+- **S** = iniciar / reanudar
+- **P** = pausar
+- **Q** = salir (mata todos los agentes)
+
+Los rate limits se reintentan automáticamente al momento de reset (hasta 10×). Las tareas completadas persisten entre reinicios de la TUI.
+
+## Estado actual de la sesión
+
+Actualiza esta sección al inicio y al final de cada sesión:
+
+- **Último handoff:** <rellenar o dejar "ninguno aún">
+- **Siguiente TASK ID:** TASK-001
+- **QUEUE:** <resumen>
+- **Notas:** <cualquier cosa relevante para la siguiente sesión>
+
+## Archivos de referencia
+
+- **Plan del proyecto:** `<projectName>-plan.md`
+- **Protocolo de agentes:** `AGENT-PROTOCOL.md` (reglas compartidas opcionales)
+- **Instrucciones por agente:** `agents/*.md`
+- **Memoria persistente:** `ENGRAM.md`
+- **Artefactos SDD:** `openspec/`
+- **Especificaciones detalladas de tareas:** `TASKS.md` (`### TASK-NNN`)
+- **Progreso por agente:** `progress/PROGRESS-<AgentName>.md`
+- **Handoffs:** `handoffs/HANDOFF-<fecha>.md`
+- **Logs:** `logs/` (eventos del orquestador + salida completa por tarea)

package/templates/es/PROJECT.md

@@ -0,0 +1,237 @@
+# Orquestador Multiagente
+
+Documento interno de estado y arquitectura del repo reusable.
+
+## Propósito actual
+
+Este repo es la **fuente reusable** del orquestador.
+
+No es el repo del producto final del usuario.
+
+Su función es:
+
+- servir como base local que LiriRaid puede seguir modificando
+- producir un paquete instalable
+- montar workspaces sibling para proyectos reales
+
+## Modelo correcto de instalación
+
+La dirección deseada no es copiar este repo dentro de cada proyecto.
+
+La dirección correcta es:
+
+- paquete global o ejecutable por `npx`
+- proyecto real separado
+- workspace sibling del orquestador al lado del proyecto
+
+Ejemplo:
+
+- proyecto:
+  - `C:/code/mi-proyecto`
+- workspace del orquestador:
+  - `C:/code/orchestrator-mi-proyecto`
+
+Esto evita ensuciar el repo del producto con:
+
+- `QUEUE.md`
+- `logs/`
+- `openspec/`
+- `handoffs/`
+- `progress/`
+
+## Regla de instalación
+
+La instalación recomendada para usuarios finales es:
+
+```bash
+npm i -g @liriraid/agentflow-ai
+```
+
+Después, por cada proyecto real:
+
+```bash
+agentflow init-workspace C:/code/mi-proyecto
+```
+
+El comando puede recibir `--lang en` o `--lang es`; si no se pasa, pregunta interactivamente.
+
+La variante con `npx` sigue siendo válida:
+
+```bash
+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.
+
+## Regla de permisos
+
+El comportamiento deseado del sistema no es `YOLO` por defecto.
+
+Meta operativa:
+
+- permitir que los agentes trabajen y propongan cambios
+- evitar autoaceptación ciega en agentes de ejecución
+- mantener a Claude como árbitro principal de calidad y consistencia
+- permitir que OpenCode explore primero, pero también implemente cuando el reparto de tareas lo necesite
+- dejar la aceptación final en manos del usuario
+
+Esto es especialmente importante cuando el agente de apoyo también modifica código y no solo lee contexto.
+
+Si el usuario quiere un modo agresivo para una sesión concreta, debe activarlo explícitamente con `--yolo`. No debe ser el modo base del sistema.
+
+## Capas del sistema
+
+### 1. Runtime
+
+- `orchestrator.js`
+- scheduler
+- parser de `QUEUE.md`
+- integración con CLIs reales
+- retries
+- fallback
+- logs
+
+### 2. UI
+
+- `src/ink/*` como TUI moderna
+- `orchestrator.js` / blessed como base histórica
+
+### 3. Routing local
+
+- `ORCHESTRATOR.md`
+- `CLAUDE.md`
+- `.atl/skill-registry.md`
+
+### 4. Skills locales
+
+Viven en:
+
+```bash
+.claude/skills/
+```
+
+Hoy incluyen:
+
+- `orchestrator-init`
+- `orchestrator-explore`
+- `orchestrator-propose`
+- `orchestrator-spec`
+- `orchestrator-design`
+- `orchestrator-tasks`
+- `orchestrator-queue-planning`
+- `orchestrator-apply`
+- `orchestrator-verify`
+- `orchestrator-archive`
+- `orchestrator-memory`
+- `orchestrator-openspec`
+
+### 5. Memoria
+
+- `ENGRAM.md`
+- Engram como memoria persistente
+
+### 6. Artefactos SDD
+
+- `openspec/`
+- `openspec/FLOW.md`
+- templates
+- scaffolder de changes
+
+### 7. Configuración por agente
+
+- `AGENT-CONFIG.md`
+- `agentProfiles` en `orchestrator.config.json`
+- `.claude/`
+- `.codex/`
+- `.opencode/`
+
+### 8. Installer / ecosystem configurator
+
+- `bin/agentflow.mjs`
+- instalación en workspace sibling
+- base preparada para npm
+
+### 9. Documentation layer
+
+- `docs/architecture.md`
+- `docs/components.md`
+- `docs/agents.md`
+- `docs/engram.md`
+- `docs/openspec.md`
+- `docs/usage.md`
+
+## Estado real de la arquitectura
+
+### Ya está integrado
+
+- skills locales del proyecto
+- registry local
+- routing con `CLAUDE.md`
+- Engram
+- OpenSpec
+- configuración reusable por agente
+- installer base
+- TUI Ink conectada al motor
+
+### Sigue en evolución
+
+- publicación final en npm
+- pulido del installer
+- integración más profunda entre OpenSpec y cola viva
+- posible crecimiento a más skills SDD
+
+## Regla de diseño principal
+
+Este proyecto debe:
+
+- **priorizar configuración local del repo**
+- **no depender de herramientas externas para el flujo base**
+- **no depender de skills globales del usuario**
+- **permitir trabajar con 3 agentes hoy y más mañana**
+- **mantener a Claude como orquestador principal**
+- **permitir que OpenCode y Codex implementen código, con Claude como revisor final y fallback**
+- **permitir que Claude también avance código como Claude-Worker (`Backend` / `Frontend`) cuando haya tareas paralelas o cuando otro agente falle**
+
+## Flujo operativo esperado
+
+1. Instalar o inicializar el workspace sibling del orquestador
+2. Editar `orchestrator.config.json`
+3. Levantar la TUI
+4. Abrir Claude Code en el workspace del orquestador
+5. Decir:
+
+```text
+Lee ORCHESTRATOR.md y arranca.
+```
+
+6. Claude:
+   - usa `CLAUDE.md`
+   - resuelve skills
+   - usa Engram
+   - usa OpenSpec si el cambio es grande
+   - traduce trabajo a `QUEUE.md`
+   - reparte la primera tanda entre Claude-Worker, Codex y OpenCode cuando existan tareas independientes suficientes
+7. El motor ejecuta
+8. La TUI refleja el movimiento real de los agentes
+
+## Regla sobre git
+
+- ningún agente hace commit
+- ningún agente hace push
+- git siempre queda manualmente en manos del usuario
+
+## Regla sobre dependencias del flujo
+
+Meta:
+
+- dejar solo Engram y el orquestador propio como base operativa
+- seguir funcionando con skills locales y config local
+- no depender del bootstrap ni de la estructura de otra herramienta
+
+## Siguiente foco natural
+
+Antes de cerrar esta etapa:
+
+- revisar el checklist final de publicación npm
+- publicar el paquete
+- validar luego la experiencia completa sobre un proyecto real de ejemplo

package/templates/es/QUEUE.md

@@ -0,0 +1,17 @@
+# Cola
+
+> Formato: `id | titulo | agente | prioridad | repo | descripcion`
+> Dependencias: agrega `> after:TASK-NNN` al final de la descripción
+> Comentarios: líneas que empiecen con `#`
+
+## Pendientes
+
+# === Tareas de ejemplo (borra estas y agrega las tuyas) ===
+
+TASK-001 | Estructura inicial del proyecto | Backend | P1 | backend | Crear estructura inicial de carpetas y boilerplate
+TASK-002 | Crear landing page | Frontend | P1 | frontend | Construir sección hero con layout responsive
+TASK-003 | Documentación de API | Codex | P2 | backend | Documentar endpoints REST en docs/api-reference.md > after:TASK-001
+
+## En progreso
+
+## Completadas