@liriraid/agentflow-ai 1.0.10

package/templates/es/agents/GEMINI.md

@@ -0,0 +1,26 @@
+# Gemini Agent
+
+## Rol
+Agente Google Gemini CLI. Fuerte para auditorías, code review y detección de patrones. Suele sufrir con `node_modules` muy grandes, así que es mejor usarlo en tareas backend/API.
+
+## Alcance
+- Auditorías: seguridad, cumplimiento de branch, compatibilidad de migraciones, etc.
+- Tareas de code review y verificación
+- Trabajo backend enfocado
+
+## Reglas
+1. Nunca hagas `git commit` ni `git push`
+2. El control de git lo maneja manualmente el usuario
+3. Actualiza `progress/PROGRESS-Gemini.md` al terminar
+
+## 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
+```

package/templates/es/agents/OPENCODE.md

@@ -0,0 +1,32 @@
+# 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
+```

package/templates/es/docs/README.md

@@ -0,0 +1,12 @@
+# Documentación
+
+Este directorio contiene la capa reusable de documentación del workspace del orquestador.
+
+Documentos disponibles:
+
+- `architecture.md` — capas del sistema y flujo de datos
+- `components.md` — componentes implementados y su estado actual
+- `agents.md` — cómo se modelan las familias de agentes
+- `engram.md` — rol y uso de la memoria
+- `openspec.md` — modelo de artefactos y flujo de cambios
+- `usage.md` — flujo recomendado de uso end-to-end

package/templates/es/docs/agents.md

@@ -0,0 +1,57 @@
+# Agentes
+
+## Familias operativas
+
+El runtime soporta varias familias de agentes, pero el modelo operativo por defecto hoy es:
+
+- **Claude** — orquestador principal y revisor final
+- **OpenCode** — exploración, lectura de contexto y también implementación cuando se le asigne
+- **Codex** — implementación estructurada y apoyo técnico; puede apoyar frontend en tareas acotadas
+
+Otros perfiles pueden permanecer configurados para uso futuro sin estar activos por defecto.
+
+## Claude como orquestador y worker
+
+Claude tiene dos papeles:
+
+- **Claude-Orquestador**: sesión interactiva que divide trabajo, mantiene `QUEUE.md`, revisa resultados y decide próximos pasos.
+- **Claude-Worker**: agentes `Backend` y `Frontend` lanzados por la TUI con CLI `claude`, capaces de modificar código.
+
+La sesión orquestadora no debe editar el proyecto real directamente. Para que Claude también trabaje en código, el orquestador asigna una TASK a `Backend` o `Frontend`.
+
+Cuando haya varias tareas independientes, la primera tanda debe intentar ocupar a `Claude-Worker`, `Codex` y `OpenCode` en paralelo. Claude también toma tareas como fallback si Codex u OpenCode quedan bloqueados por cuota, tokens, rate limit o fallo persistente.
+
+## Preferencia para frontend
+
+El trabajo frontend lo lidera preferentemente `Frontend`/Claude. Codex puede recibir TASKs con `repo=frontend`, pero como apoyo menos permisivo: tests, documentación técnica, fixes puntuales, refactors mecánicos o cambios con archivos bien delimitados. Para cambios visuales amplios, arquitectura de componentes o flujos interactivos, usa `Frontend` como dueño principal.
+
+## Capas de agentes
+
+### `agentProfiles`
+
+Configuración reusable por familia de agente, por ejemplo:
+
+- `claude`
+- `codex`
+- `opencode`
+- `gemini`
+- `cursor`
+- `abacusai`
+
+### `agents`
+
+Instancias operativas visibles en el runtime y en la TUI, por ejemplo:
+
+- `Backend`
+- `Frontend`
+- `Codex`
+- `OpenCode`
+
+## Autoridad de revisión
+
+Aunque OpenCode o Codex implementen código, Claude debe seguir siendo la autoridad principal para:
+
+- revisión final
+- consistencia contra la task
+- decidir si el resultado coincide con la intención pedida
+- tomar tareas como fallback cuando otro agente falla

package/templates/es/docs/architecture.md

@@ -0,0 +1,41 @@
+# Arquitectura
+
+## Modelo general
+
+El orquestador se divide en:
+
+1. **Paquete CLI global**
+   - se instala una sola vez con npm
+   - expone `agentflow`
+2. **Workspace del orquestador por proyecto**
+   - se crea como carpeta hermana del proyecto real
+   - contiene cola, estado runtime, docs, skills y artefactos
+3. **Repositorio real del proyecto**
+   - permanece limpio
+   - es referenciado desde `orchestrator.config.json`
+
+## Capas principales
+
+- **Runtime** — `orchestrator.js`, parser de cola, scheduler y lanzador de agentes
+- **UI** — TUI en Ink y TUI histórica en Blessed
+- **Routing** — `ORCHESTRATOR.md`, `CLAUDE.md` y skill registry local
+- **Skills** — skills locales del proyecto en `.claude/skills/`
+- **Memoria** — Engram y sus convenciones de uso
+- **Artefactos** — ciclo de vida de cambios en OpenSpec
+- **Installer** — CLI global + creación de workspace
+
+## Modelo operativo por defecto
+
+- Claude es el orquestador principal
+- Claude también puede trabajar como agente ejecutor mediante los workers `Backend` y `Frontend`
+- OpenCode explora, lee contexto, audita y también puede implementar código
+- Codex implementa trabajo estructurado en backend y también puede apoyar frontend en tareas acotadas
+- Claude sigue siendo el revisor final y el filtro principal de calidad
+
+El rol interactivo de Claude no edita el proyecto real directamente; coordina y revisa. La ejecución de código por Claude ocurre a través de una TASK asignada a un agente Claude-Worker en la cola.
+
+## Modelo de permisos
+
+- Seguro por defecto
+- Sin bypass / YOLO por defecto
+- Bypass explícito solo si el usuario inicia una sesión con `--yolo`

package/templates/es/docs/components.md

@@ -0,0 +1,33 @@
+# Componentes
+
+Este documento describe los componentes reales del orquestador y cómo se organizan dentro del sistema.
+
+| Componente | ID | Estado | Descripción |
+|---|---|---|---|
+| Engram | `engram` | Implementado | Memoria persistente entre sesiones |
+| SDD | `sdd` | Implementado | Flujo guiado por OpenSpec y skills del orquestador |
+| Skills | `skills` | Implementado | Skills locales en `.claude/skills/` con registry propio |
+| Context7 | `context7` | Soportado | Se usa cuando se necesitan docs actuales de librerías |
+| Persona | `persona` | Implementado | Claude como orquestador principal con reglas locales |
+| Permissions | `permissions` | Implementado | Seguro por defecto, bypass solo explícito |
+| GGA | `gga` | No incluido | Fuera de alcance para este orquestador |
+| Theme | `theme` | No incluido | No forma parte del alcance de este orquestador |
+
+## Skills de flujo del orquestador
+
+- `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`
+
+## Decisión de diseño
+
+Este repo organiza sus skills alrededor del flujo real del orquestador con TUI, `QUEUE.md`, OpenSpec, Engram y Claude como coordinador.

package/templates/es/docs/engram.md

@@ -0,0 +1,30 @@
+# Engram
+
+Engram is the persistent memory layer for this orchestrator.
+
+## What it stores
+
+- decisions
+- discoveries
+- bug fixes
+- project conventions
+- session summaries
+- important user preferences
+
+## What it does not replace
+
+- `QUEUE.md`
+- the TUI
+- OpenSpec change artifacts
+- progress files
+
+## Role in the workflow
+
+- gives continuity across sessions
+- prevents re-discovering the same facts repeatedly
+- supports Claude as orchestrator when context grows
+
+## Local references
+
+- `ENGRAM.md`
+- `.claude/skills/orchestrator-memory/SKILL.md`

package/templates/es/docs/openspec.md

@@ -0,0 +1,34 @@
+# OpenSpec
+
+OpenSpec is the persistent artifact layer for larger or multi-phase changes.
+
+## Canonical flow
+
+`explore -> proposal -> spec -> design -> tasks -> queue -> apply -> verify -> archive`
+
+## Main location
+
+```text
+openspec/
+```
+
+## Typical change layout
+
+```text
+openspec/changes/<change-name>/
+```
+
+Artifacts typically include:
+
+- `proposal.md`
+- `specs/spec.md`
+- `design.md`
+- `tasks.md`
+- `verify-report.md`
+- `archive-report.md`
+
+## Relationship to the runtime
+
+- OpenSpec defines the planning and artifact trail
+- `QUEUE.md` defines the live execution queue
+- `tasks.md` should be translated into `QUEUE.md` when execution begins

package/templates/es/docs/usage.md

@@ -0,0 +1,54 @@
+# Uso
+
+## Flujo recomendado
+
+### 1. Instalar el CLI globalmente
+
+```bash
+npm i -g @liriraid/agentflow-ai
+```
+
+### 2. Crear un workspace hermano para un proyecto
+
+```bash
+agentflow init-workspace C:/code/mi-proyecto
+```
+
+Si no pasas idioma, el CLI preguntará si quieres `EN` o `ES`. También puedes elegirlo directo:
+
+```bash
+agentflow init-workspace C:/code/mi-proyecto --lang en
+agentflow init-workspace C:/code/mi-proyecto --lang es
+```
+
+### 3. Abrir el workspace del orquestador
+
+Usa dos terminales:
+
+- una para la TUI
+- otra para Claude Code
+
+### 4. Iniciar la TUI
+
+```bash
+agentflow ink --paused
+```
+
+### 5. Iniciar Claude en el workspace del orquestador
+
+Luego dile:
+
+```text
+Lee ORCHESTRATOR.md, asume el rol de orquestador y arranca.
+```
+
+### 6. Pedir trabajo
+
+Ejemplos:
+
+- `explora esta carpeta de componentes`
+- `analiza este flujo`
+- `prepara proposal, spec y tasks`
+- `verifica que la implementación cumpla la spec`
+
+Claude debe rutear naturalmente a las skills locales correctas del orquestador y reflejar ese flujo en la TUI.

package/templates/es/openspec/FLOW.md

@@ -0,0 +1,139 @@
+# OpenSpec Flow
+
+Este archivo define el flujo real de artefactos para cambios grandes dentro del orquestador.
+
+## Orden de fases
+
+```text
+explore -> proposal -> spec -> design -> tasks -> queue -> apply -> verify -> archive
+```
+
+## Regla general
+
+- Si el cambio es pequeño y directo, puede ir solo por `QUEUE.md`.
+- Si el cambio tiene varias fases, varios agentes o riesgo no trivial, debe pasar por `openspec/`.
+
+## Cuándo nace un change
+
+Crea `openspec/changes/<change-name>/` cuando ocurra cualquiera de estas:
+
+- el usuario pide proposal, spec, design o tasks
+- la exploración revela varias fases o varios agentes
+- el cambio necesita trazabilidad durable
+- el cambio afecta arquitectura, flujo o estructura del proyecto
+
+## Responsabilidad de cada artefacto
+
+### `proposal.md`
+
+Se usa para fijar:
+
+- objetivo del cambio
+- alcance
+- riesgos
+- rollback
+
+Debe existir antes de escribir `specs/spec.md`.
+
+### `specs/spec.md`
+
+Se usa para fijar:
+
+- requisitos verificables
+- escenarios
+- expectativas observables
+
+No debe contener detalles de implementación.
+
+### `design.md`
+
+Se usa para fijar:
+
+- enfoque técnico
+- componentes afectados
+- decisiones
+- tradeoffs
+
+Puede omitirse si el cambio es suficientemente pequeño y la spec ya deja clara la implementación.
+
+### `tasks.md`
+
+Se usa para convertir proposal/spec/design en trabajo ejecutable.
+
+Debe contener:
+
+- tareas pequeñas
+- orden sugerido
+- dependencias
+- bloques listos para pasar a `QUEUE.md`
+
+### `verify-report.md`
+
+Se llena después de ejecutar o revisar implementación.
+
+Debe responder:
+
+- qué quedó hecho
+- si coincide con spec y design
+- qué riesgos o dudas quedan
+- veredicto final
+
+### `archive-report.md`
+
+Se usa cuando el cambio ya no seguirá activo.
+
+Debe dejar:
+
+- resumen final
+- estado
+- decisiones clave
+- follow-ups
+
+## Paso de `tasks.md` a `QUEUE.md`
+
+`tasks.md` es la fuente de verdad para descomposición del cambio.
+
+`QUEUE.md` es la fuente de verdad para ejecución viva del motor.
+
+La regla es:
+
+1. primero se escribe o actualiza `tasks.md`
+2. luego solo las tareas listas para ejecución pasan a `QUEUE.md`
+3. al completarse en el motor, el estado se refleja de vuelta en `tasks.md` y/o `verify-report.md` cuando haga falta
+
+No debe aparecer implementación grande en `QUEUE.md` si antes no está aterrizada en `tasks.md`.
+
+## Estados sugeridos del change
+
+Usa estos estados en `.openspec.yaml`:
+
+- `draft`
+- `exploring`
+- `proposed`
+- `specified`
+- `designed`
+- `planned`
+- `in-progress`
+- `verifying`
+- `archived`
+
+## Criterio de avance
+
+- `proposal -> spec`: cuando el alcance ya está claro
+- `spec -> design`: cuando hace falta decisión técnica
+- `design -> tasks`: cuando ya hay enfoque suficiente para ejecutar
+- `tasks -> queue`: cuando ya existen tareas concretas, pequeñas y asignables
+- `queue -> verify`: cuando las tareas relevantes terminaron
+- `verify -> archive`: cuando el cambio ya no requiere ejecución activa
+
+## Relación con Engram
+
+- Usa Engram para decisiones, descubrimientos y continuidad de sesión
+- Usa OpenSpec para artefactos del cambio
+- No mezcles ambos roles
+
+## Relación con la TUI
+
+- La TUI muestra ejecución viva
+- OpenSpec muestra razonamiento, estructura y trazabilidad
+- `QUEUE.md` sigue siendo el puente entre ambos

package/templates/es/openspec/README.md

@@ -0,0 +1,77 @@
+# OpenSpec Workspace
+
+Esta carpeta guarda los artefactos SDD del proyecto.
+
+## Estructura
+
+```text
+openspec/
+├── changes/
+│   ├── archive/
+│   └── <change-name>/
+├── FLOW.md
+├── specs/
+└── templates/
+```
+
+## Objetivo
+
+Usar `openspec/` como capa persistente para cambios importantes, sin depender solo de conversación, `QUEUE.md` o memoria corta.
+
+## Flujo recomendado
+
+1. **Explorar** una idea o problema
+2. Crear un **change** en `openspec/changes/<change-name>/`
+3. Escribir:
+   - `proposal.md`
+   - `specs/spec.md`
+   - `design.md`
+   - `tasks.md`
+   - `verify-report.md`
+   - `archive-report.md`
+4. Guardar specs delta dentro de:
+   - `openspec/changes/<change-name>/specs/`
+5. Cuando el cambio termine:
+   - moverlo a `openspec/changes/archive/`
+   - reflejar aprendizaje útil en Engram
+
+## Flujo canónico
+
+Consulta también:
+
+- `openspec/FLOW.md`
+
+Ese archivo define:
+
+- cuándo nace un change
+- cuándo proposal pasa a spec
+- cuándo tasks baja a `QUEUE.md`
+- cómo verificar y archivar
+
+## Regla de diseño
+
+- `openspec/` complementa `QUEUE.md`; no lo reemplaza.
+- `QUEUE.md` sigue siendo la cola operativa del motor.
+- `openspec/` guarda la intención, la spec delta, el diseño, el checklist y la verificación de cambios relevantes.
+
+## Nombres de changes
+
+Usa nombres claros, por ejemplo:
+
+- `add-orchestrator-installer`
+- `integrate-openspec-routing`
+- `add-agent-config-sync`
+- `improve-open-code-exploration`
+
+Evita:
+
+- `test`
+- `wip`
+- `change-1`
+
+## Relación con el orquestador
+
+- Claude puede usar `openspec/` para pensar y persistir cambios más grandes.
+- `QUEUE.md` puede derivarse de `tasks.md`.
+- Engram guarda continuidad y decisiones.
+- La TUI sigue mostrando ejecución viva; `openspec/` guarda el razonamiento y la estructura.

package/templates/es/openspec/changes/.gitkeep

@@ -0,0 +1 @@
+

package/templates/es/openspec/changes/archive/.gitkeep

@@ -0,0 +1 @@
+

package/templates/es/openspec/specs/.gitkeep

@@ -0,0 +1 @@
+

package/templates/es/openspec/templates/archive-report.md

@@ -0,0 +1,23 @@
+# Archive Report
+
+## Change
+
+`<change-name>`
+
+## Summary
+
+Resumen corto del cambio archivado.
+
+## Final Status
+
+`completed | partial | archived-with-risks`
+
+## Key Decisions
+
+- Decisión 1
+- Decisión 2
+
+## Follow-ups
+
+- Seguimiento 1
+- Seguimiento 2

package/templates/es/openspec/templates/change-metadata.yaml

@@ -0,0 +1,9 @@
+name: <change-name>
+status: draft
+current_phase: proposal
+owner: claude-orchestrator
+created_at: YYYY-MM-DD
+related_queue_tasks: []
+related_specs: []
+queue_synced: false
+notes: ""

package/templates/es/openspec/templates/design.md

@@ -0,0 +1,33 @@
+# Design
+
+## Context
+
+Describe el contexto técnico del cambio.
+
+## Approach
+
+Explica cómo se implementará el cambio.
+
+## Components Affected
+
+- Archivo / módulo
+- Archivo / módulo
+
+## Data Flow
+
+Describe el flujo importante entre piezas del sistema.
+
+## Decisions
+
+- Decisión 1
+- Decisión 2
+
+## Tradeoffs
+
+- Tradeoff 1
+- Tradeoff 2
+
+## Open Questions
+
+- Pregunta 1
+- Pregunta 2

package/templates/es/openspec/templates/proposal.md

@@ -0,0 +1,36 @@
+# Proposal
+
+## Change Name
+
+`<change-name>`
+
+## Why
+
+Explica por qué este cambio existe y qué problema resuelve.
+
+## What Changes
+
+- Cambio 1
+- Cambio 2
+- Cambio 3
+
+## Scope
+
+### In Scope
+
+- Ítem 1
+- Ítem 2
+
+### Out of Scope
+
+- Ítem 1
+- Ítem 2
+
+## Risks
+
+- Riesgo 1
+- Riesgo 2
+
+## Rollback
+
+Cómo revertir o detener este cambio si genera problemas.

package/templates/es/openspec/templates/spec.md

@@ -0,0 +1,33 @@
+# Spec Delta
+
+## Change
+
+`<change-name>`
+
+## Requirements
+
+### Requirement 1
+
+Describe un requisito verificable.
+
+#### Scenario: Happy path
+
+- **Given** una condición inicial
+- **When** ocurre una acción
+- **Then** el sistema produce el resultado esperado
+
+### Requirement 2
+
+Describe otro requisito verificable.
+
+#### Scenario: Edge case
+
+- **Given** una condición límite
+- **When** ocurre una acción relevante
+- **Then** el sistema responde de forma correcta
+
+## Notes
+
+- Escribe requisitos observables, no implementación
+- Usa escenarios concretos
+- Esta spec debe vivir dentro de `openspec/changes/<change-name>/specs/`