openprompt-lang 1.2.7 → 1.4.0

package/README.md

@@ -30,6 +30,25 @@ Guarda conceptos visuales o técnicos para que la IA los entienda como tú los e
 ### Repositorio de Conocimiento (Knowledge)
 Almacena, indexa y procesa documentos PDF y fuentes web técnicas. Detecta capítulos automáticamente y los divide en secciones de lectura rápida para que la IA los use. Incluye **33 libros y guías pre-empaquetados** (JavaScript, TypeScript, Rust, React, Node.js, Python, Scrum, accesibilidad, algoritmos, API de pagos, etc.) accesibles sin configuración previa vía MCP (`knowledge_search`, `knowledge_list`, `knowledge_read`, `knowledge_concept`) o CLI (`knowledge search`, `knowledge sync --all`). Genera automáticamente `.openprompt/FRAMEWORK.md` con el manual operativo restrictivo para la IA.
 
+### Búsqueda Semántica por Embeddings (Vector Search)
+Reemplaza el mapa semántico manual con vectores numéricos generados por IA local. Divide documentos en chunks semánticos, los convierte en vectores (768d con Ollama o 384d con Transformers.js), y busca por similitud de coseno. Incluye un pipeline completo: chunker (3 estrategias), embedder (Ollama + Transformers.js con auto-fallback), vector store (SQLite + FTS5), y soporte de búsqueda híbrida (FTS5 + reordenamiento semántico). Se integra con `opl search --mode vector` y el indexado automático tras la ingesta de PDFs.
+
+**Requisitos:**
+- **Primario**: [Ollama](https://ollama.com) con `ollama pull nomic-embed-text` (recomendado)
+- **Fallback**: `@xenova/transformers` (incluido como dependencia opcional, se activa automáticamente si Ollama no está disponible)
+
+**Comandos:**
+```bash
+opl embeddings status                    # Ver estado del índice vectorial
+opl embeddings index <docId>             # Indexar un documento
+opl embeddings remove <docId>            # Eliminar embeddings
+opl embeddings config                    # Ver/configurar proveedor
+opl search "consulta" --mode vector      # Búsqueda semántica
+opl search "consulta" --mode hybrid      # Híbrido (incluye vectorial)
+opl webscrape <url> --domain frontend    # Scrapear web e indexar
+knowledge ingest doc.pdf                 # Ingesta PDF + auto-embedding
+```
+
 ### IA Local (Local Setup)
 Configura un entorno de desarrollo completamente local y desconectado. Prepara la integración con modelos locales en Ollama (como Llama 3 o Qwen 2.5 Coder) y la suite de herramientas OpenCode, permitiendo trabajar sin internet ni costos de API, pero manteniendo el 100% de la precisión del framework.
 
@@ -582,6 +601,25 @@ openPrompt-Lang component list --validated
 | `openPrompt-Lang knowledge rebuild` | Reconstruye el índice general desde metadatos individuales |
 | `openPrompt-Lang knowledge sync [--all]` | Sincroniza libros de la biblioteca empaquetada al proyecto local |
 | `openPrompt-Lang local-setup` | Configura integración con IA local (Ollama + OpenCode) |
+| `opl workflow select <desc>` | Selecciona workflow óptimo según descripción de la tarea (usar SIEMPRE primero) |
+| `opl workflow delivery` | Inicia desarrollo por tickets (E.3) |
+| `opl workflow close` | Cierra sesión activa y genera reporte (E.4) |
+| `opl epic create --title "..." --desc "..."` | Crea épica con tickets generados automáticamente |
+| `opl epic list` | Lista épicas con métricas de progreso |
+| `opl epic show <id>` | Muestra detalle de épica y sus tickets |
+| `opl epic close <id>` | Cierra épica |
+| `opl sprint create <name> --goal "..."` | Crea sprint con duración configurable |
+| `opl sprint list` | Lista sprints con métricas |
+| `opl sprint plan <id> --capacity N` | Planifica sprint automáticamente desde épicas activas |
+| `opl sprint close <id>` | Cierra sprint |
+| `opl ticket create --title "..." --severity ...` | Crea ticket de bug/tarea |
+| `opl ticket list` | Lista tickets del proyecto |
+| `opl ticket close <id>` | Cierra ticket como fixed |
+| `opl embeddings status` | Ver estado del índice vectorial semántico |
+| `opl embeddings index <docId>` | Indexa un documento en el vector store |
+| `opl embeddings remove <docId>` | Elimina embeddings de un documento |
+| `opl embeddings config` | Ver/configurar proveedor de embeddings |
+| `opl webscrape <url>` | Extrae contenido web y lo indexa en knowledge + embeddings |
 
 ### Base de Conocimiento Empaquetada
 
@@ -1128,17 +1166,33 @@ El **Work Context** es un sistema integrado de trazabilidad obligatoria que regi
 | `openPrompt-Lang work-context check` | Verifica consistencia del work-context: valida que `SESSION.json` exista y tenga estructura correcta, detecta sesiones activas olvidadas (>24h), confirma que los planes referenciados existen en disco, valida que `LOG.json` sea un array válido |
 | `validate --work-context` | Incluye la verificación de work-context dentro del pipeline de validación estándar |
 
-### Flujo de trabajo obligatorio
+### Flujo de trabajo obligatorio (v1.3.0)
 
-La IA debe seguir este ciclo en **cada sesión de trabajo**:
+La IA debe seguir este ciclo en **cada sesión de trabajo**. No hay excepciones:
 
 ```
-1. CONTEXT.md + SESSION.json  → restaurar estado o iniciar nuevo
-2. ANALYZE request            → clasificar tipo de tarea
-3. PLAN → `work-context plan new <name> --task "<desc>"` → PLANS/, log en LOG
-4. VALIDATE plan              → contra @kind, @contract, @limit
-5. IMPLEMENT                  → codificar, log cada acción
-6. VALIDATE código            → validate + validate --work-context
+1. → workflow_select          → "opl workflow select <descripción>"
+                               La IA describe su tarea, el sistema selecciona workflow óptimo
+2. → create_ticket             → "opl ticket create --title ... --severity ..."
+                               TODO cambio requiere ticket ANTES de implementar
+3. → check_gates               → workflow_selected ✓, ticket_created ✓, plan_approved ✓
+4. → work_context_plan         → Planificar usando work-context con búsqueda de conocimiento
+5. → implement                 → Codificar con anotaciones OPL primero (@kind → @contract → @limit)
+6. → validate                  → "opl validate" antes de cerrar
+7. → docs_updated              → Actualizar documentación (OBLIGATORIO antes de cerrar)
+8. → work_context_close        → Cerrar sesión y generar reporte
+```
+
+**Reglas inquebrantables:**
+- **Regla #1**: `workflow select` primero — Sin workflow seleccionado no hay implementación
+- **Regla #2**: `ticket create` antes de código — Sin ticket no se escribe código
+- **Regla #3**: `docs_updated` antes de cerrar — Sin documentación actualizada no se cierra sesión
+
+El sistema de gates (`workflow_selected`, `ticket_created`, `plan_approved`, `docs_updated`)
+bloquea herramientas automáticamente si no se cumplen los prerrequisitos (configurable en
+`prompt-lang.json` → `workflow.enforcement`).
+
+Ver también: `AGENTS.md` para instrucciones detalladas de cada paso.
 7. INTEGRATE                  → actualizar AGENTS.md si toca
 8. LEARN + REFERENCES.md      → checklist de referencias seguras
 9. CLOSE                      → reporte, métricas finales

package/bin/cli.js

@@ -21,6 +21,7 @@ import { register as registerOpl } from "../src/cli/commands-opl.js"
 import { register as registerMisc } from "../src/cli/commands-misc.js"
 import { register as registerWorkflow } from "../src/cli/commands-workflow.js"
 import { register as registerTeach } from "../src/cli/commands-teach.js"
+import { register as registerBoost } from "../src/cli/commands-boost.js"
 
 import { handleUncaughtErrors, EXIT_CODES } from "../src/utils/errors.js"
 
@@ -67,6 +68,7 @@ registerLearning(program)
 registerMisc(program)
 registerWorkflow(program)
 registerTeach(program)
+registerBoost(program)
 
 try {
   await program.parseAsync(process.argv)

package/docs/00-ARCHITECTURE/OPL-BOOST-MULTI-AGENT.md

@@ -0,0 +1,406 @@
+# OPL Boost — Arquitectura Multi-Agente (MoA)
+
+> **Documento de diseño** — Versión borrador para discusión
+> Última actualización: 2026-05-26
+
+---
+
+## 1. Concepto Central
+
+**Modelos pequeños colaborando pueden superar a uno grande.** Es el principio de **Mixture of Agents (MoA)** validado por Together AI (2024): tres modelos de 7B especializados y coordinados pueden igualar o superar a GPT-4 en tareas específicas de generación de código.
+
+La clave está en que **cada modelo solo necesita resolver la parte del problema que cabe en su ventana de contexto**.
+
+### Analogía: Fábrica de código
+
+```
+[ Modelo Grande ] → Un artesano que lo hace todo, pero caro y escaso
+[ Boost Multi-Agente ] → Una línea de ensamblaje con 5 operarios baratos, cada uno especializado
+```
+
+| Aspecto | Modelo grande único | Boost Multi-Agente |
+|---------|-------------------|-------------------|
+| RAM requerida | ~20-40 GB | ~4-12 GB |
+| Velocidad | Secuencial, un paso a la vez | Paralelo, varios pasos simultáneos |
+| Costo operativo | Alto (GPU grande) | Bajo (varias GPUs chicas o una sola con cola) |
+| Especialización | Generalista | Agentes especializados por rol |
+| Respaldo científico | — | MoA (Together AI, 2024) |
+| Degradación | Si falla, todo falla | Si un agente falla, se reasigna |
+
+---
+
+## 2. Arquitectura
+
+```
+┌─────────────────────────────────────────────────────────────────────┐
+│                       Boost Orchestrator                             │
+│                 (src/boost/index.js + orchestrator.js)                │
+│                                                                       │
+│  1. Recibe tarea → "crea hook useAuth"                                │
+│  2. Descompone en DAG de pasos                                       │
+│  3. Asigna agentes según dependencias                                │
+│  4. Ejecuta en paralelo o secuencial según DAG                       │
+│  5. Recolecta resultados parciales                                   │
+│  6. Ensambla resultado final                                         │
+│  7. Pasa por validation loop                                         │
+└──────┬────────────────────────────────────┬──────────────────────────┘
+       │                                    │
+       │  Fase 1: Paralela                  │  Fase 2: Secuencial
+       │  (tareas independientes)           │  (tareas con dependencias)
+       ▼                                    ▼
+┌─────────────┐  ┌─────────────┐     ┌─────────────┐
+│ Agent A     │  │ Agent B     │     │ Agent D     │
+│ Tipos       │  │ Estado      │     │ Lógica      │
+│ "Define     │  │ "Diseña el  │     │ "Implementa │
+│  interfaces"│  │  estado y   │     │  la función"│
+└──────┬──────┘  │  efectos"   │     └──────┬──────┘
+       │         └──────┬──────┘            │
+       │                │                   │
+       └────────┬───────┘                   │
+                │                           │
+                ▼                           ▼
+        ┌──────────────┐            ┌──────────────┐
+        │ Agent C      │            │ Agent E      │
+        │ Props/Contract│           │ Validación   │
+        │ (paralelo a  │            │ (último paso)│
+        │  A y B)      │            │              │
+        └──────────────┘            └──────────────┘
+```
+
+### 2.1 Componentes del Sistema
+
+```
+src/boost/
+├── index.js                 → Punto de entrada (orquestador general)
+├── orchestrator.js          → Motor de planificación + scheduling de agentes
+├── agent-pool.js            → Pool de agentes: gestión, cola, paralelismo
+├── task-dispatcher.js       → Descompone tarea en DAG + asigna
+├── agents/                  → Agentes especializados
+│   ├── agent-types.js       → Prompt + validator por rol
+│   ├── agent-types.js       → Define interfaces de tipos/tipado
+│   ├── agent-state.js       → Diseña estado y efectos
+│   ├── agent-logic.js       → Implementa lógica de negocio
+│   ├── agent-validate.js    → Corre validación + retroalimentación
+│   └── agent-cleaner.js     → Comprime/pule contexto (AI Cleaner)
+├── context-cache/           → Contexto limpio cacheado por tipo de tarea
+├── profile-registry.js      → ✅ Ya existe (Ticket 1)
+├── context-compressor.js    → Capa 1: determinística (Ticket 2)
+├── hydrator.js              → Hidratación de skeletons (Ticket 3)
+├── fewshot-retriever.js     → Búsqueda de ejemplos (Ticket 4)
+└── validation-loop.js       → Feedback loop post-generación (Ticket 6)
+```
+
+### 2.2 Pool de Agentes vs Instancias de Modelo
+
+El pool de agentes es **lógico**, no necesariamente físico:
+
+```
+┌──────────────────────────────────┐
+│         Agent Pool                │
+│  (gestiona tareas vs instancias)  │
+│                                   │
+│  ┌──────────┐  ┌──────────┐      │
+│  │ Agent A  │  │ Agent B  │      │  ← Agentes lógicos (roles)
+│  │ (Tipos)  │  │ (Estado) │      │
+│  └────┬─────┘  └────┬─────┘      │
+│       │              │            │
+│       ▼              ▼            │
+│  ┌──────────────────────────┐     │
+│  │   Instancia de modelo    │     │  ← Física (Ollama, API)
+│  │   deepseek-coder-7b      │     │     Se reusa entre agentes
+│  └──────────────────────────┘     │
+└──────────────────────────────────┘
+```
+
+Un solo modelo físico puede servir múltiples agentes lógicos en serie (no en paralelo real si no hay GPU suficiente):
+
+- **Modo paralelo real**: varias instancias del modelo en GPUs diferentes (o misma con batching)
+- **Modo cola**: una sola instancia atiende agentes en secuencia, como si fuera un solo núcleo compartido
+
+---
+
+## 3. Agentes Especializados
+
+Cada agente tiene:
+
+| Rol | Nombre | Input | Output | Prompt característico |
+|-----|--------|-------|--------|----------------------|
+| **Tipos** | `agent-types` | Descripción de la tarea | Interfaces, types, DTOs | _"Define solo los tipos. Sin implementación."_ |
+| **Estado** | `agent-state` | Descripción de la tarea + tipos | Estado, hooks, efectos | _"Diseña el estado y efectos. Sin JSX."_ |
+| **Contrato** | `agent-contract` | Descripción de la tarea + tipos | Props, anotaciones @contract | _"Define el contrato del componente."_ |
+| **Lógica** | `agent-logic` | tipos + estado + contrato | Lógica de negocio completa | _"Implementa la función usando tipos y estado ya definidos."_ |
+| **Validación** | `agent-validate` | Código completo | Versión corregida o reporte | _"Este código falló en X línea. Corrígelo."_ |
+| **Cleaner** | `agent-cleaner` | Contexto completo | Contexto comprimido minimal | _"Comprime este contexto a solo lo esencial para generar un hook."_ |
+
+**Cada prompt es 3-5 líneas máximo.** Un modelo de 8K procesa esto sin saturarse.
+
+### 3.1 Prompt de ejemplo para Agent-Cleaner
+
+```
+Eres un compresor de contexto para un asistente de código.
+Recibe estas reglas y devuélvelas en su forma más compacta.
+
+Reglas críticas a preservar:
+- @kind limits (hook:80, component:120, page:200)
+- @limit NO es sugerencia, bloquea commit
+- @use() obligatorio al inicio
+- Named exports sobre default exports
+- NUNCA: any types, modificar *.template.*, eliminar @use
+
+Tarea actual: generar un hook useDebounce
+Contexto a comprimir:
+[CONTEXTO AQUÍ]
+
+Output: solo las reglas relevantes para hooks, en formato minimal.
+```
+
+---
+
+## 4. Modos de Ejecución
+
+### 4.1 Modo Paralelo (múltiples GPUs/instancias)
+
+```
+Tiempo: 0s ─────────────────────────────────────►
+
+Agent A (Tipos):    ████████░░░░░░░░░░░░░░░░░░░░  2s
+Agent B (Estado):   ██████████░░░░░░░░░░░░░░░░░░  2.5s
+Agent C (Contrato): ██████░░░░░░░░░░░░░░░░░░░░░░  1.5s
+                                              │ paralelo
+                                              ▼
+Agent D (Lógica):   ░░░░░░░░░░░████████░░░░░░░░░░  2s
+                                              │ secuencial
+                                              ▼
+Agent E (Validar):  ░░░░░░░░░░░░░░░░░░████████░░  2s
+
+Total: ~6.5s (vs ~10s secuencial, vs ~8s un modelo grande)
+```
+
+### 4.2 Modo Cola (una sola instancia de modelo)
+
+```
+Agent A → B → C → (paralelo lógico) → D → E
+
+Tiempo: ~10s pero con ~4GB RAM en lugar de ~24GB
+Vs un modelo grande: 8s pero necesita 24GB de RAM
+```
+
+### 4.3 Comparación de costos
+
+| Config | RAM | VRAM | Tiempo | Tokens/s | Puede correr en |
+|--------|-----|------|--------|----------|-----------------|
+| 1× Qwen 32B | 24 GB | 20 GB | 8s | ~15 tok/s | RTX 4090, Mac M2 Ultra |
+| 3× DeepSeek 7B (cola) | 12 GB | 8 GB | 10s | ~25 tok/s (compartido) | RTX 3060, Mac M1 Pro |
+| 3× DeepSeek 7B (paralelo) | 12 GB | 24 GB | 6s | ~75 tok/s (3 instancias) | RTX 4090, 2× RTX 3060 |
+| 5× DeepSeek 7B (cola, con cache) | 8 GB | 4 GB | 12s | ~35 tok/s (cuantizado) | Laptop con GPU modesta |
+
+La conclusión: **3 modelos chicos en cola en una RTX 3060 dan resultados competitivos vs un modelo grande en RTX 4090**, con un costo de hardware 3-4× menor.
+
+---
+
+## 5. DAG de Tareas (Task Dispatcher)
+
+El dispatcher convierte una descripción tipo _"crea hook useAuth"_ en un grafo dirigido:
+
+```json
+{
+  "task": "crea hook useAuth con Supabase y Zustand",
+  "kind": "hook",
+  "dag": {
+    "nodes": [
+      { "id": "types",   "agent": "agent-types",   "deps": [] },
+      { "id": "state",   "agent": "agent-state",   "deps": [] },
+      { "id": "effects", "agent": "agent-logic",   "deps": ["types", "state"] },
+      { "id": "final",   "agent": "agent-validate", "deps": ["effects"] }
+    ]
+  }
+}
+```
+
+Reglas del DAG:
+- **Nodos sin dependencias** → se ejecutan en paralelo
+- **Nodos con dependencias** → esperan a que sus predecesores terminen
+- **Si un nodo falla** → se reintenta (según perfil) o se reasigna a otro agente
+- **El DAG es serializable** → se puede cachear y re-ejecutar
+
+El DAG se puede representar como Mermaid para visualización:
+
+```mermaid
+graph TD
+    Task["hook useAuth"] --> Types[Agent: Tipos]
+    Task --> State[Agent: Estado]
+    Types --> Logic[Agent: Lógica]
+    State --> Logic
+    Logic --> Validate[Agent: Validación]
+```
+
+---
+
+## 6. Integración con el Pipeline Existente
+
+Boost no reemplaza el flujo actual de OPL — lo envuelve:
+
+```
+Flujo normal OPL:
+  workflow select → ticket → plan → implement → validate → close
+
+Con Boost Multi-Agente:
+  boost generate "hook useAuth"
+    │
+    ├── 1. Profile Registry → detecta small (activa Boost)
+    ├── 2. Context Compressor → reduce AGENTS.md
+    ├── 3. FewShot Retriever → busca ejemplos
+    ├── 4. Task Dispatcher → DAG de agentes
+    ├── 5. Agent Pool → ejecuta DAG (paralelo/cola)
+    ├── 6. Hydrator → ensambla código final con anotaciones
+    ├── 7. Validation Loop → corrige errores
+    └── 8. Output → archivo listo para validar
+```
+
+El `opl boost generate` se convierte en el **punto de entrada único** que dispara todo el pipeline multi-agente. Funciona igual para MCP vía `OPL_Boost_microtask`.
+
+---
+
+## 7. Modelo de Datos
+
+### Profile → define capacidades
+```json
+{
+  "name": "small",
+  "agentPool": {
+    "mode": "queue",           // "parallel" | "queue"
+    "maxConcurrency": 3,       // paralelo máximo
+    "modelName": "deepseek-coder-7b",
+    "modelProvider": "ollama",
+    "modelEndpoint": "http://localhost:11434",
+    "contextWindow": 8000,
+    "temperature": 0.2,
+    "cacheEnabled": true
+  },
+  "features": {
+    "compress": true,
+    "fewShot": true,
+    "agents": true,
+    "hydration": true,
+    "validation": true
+  }
+}
+```
+
+### Agent → define un worker
+```json
+{
+  "id": "agent-types",
+  "role": "types",
+  "modelName": "deepseek-coder-7b",
+  "systemPrompt": "Define solo tipos e interfaces. Sin implementación.",
+  "inputSchema": { "description": "string" },
+  "outputSchema": { "types": "string", "interfaces": "string" },
+  "timeoutMs": 30000,
+  "retries": 2,
+  "cacheTtl": 3600
+}
+```
+
+### Task → instancia de trabajo
+```json
+{
+  "id": "task_001",
+  "description": "crea hook useAuth con Supabase",
+  "kind": "hook",
+  "dag": { "nodes": [...] },
+  "profile": "small",
+  "status": "running",
+  "startedAt": "2026-05-26T14:00:00Z",
+  "agents": {
+    "agent-types":   { "status": "completed", "output": "..." },
+    "agent-state":   { "status": "running",   "output": null },
+    "agent-logic":   { "status": "pending",   "output": null },
+    "agent-validate":{ "status": "pending",   "output": null }
+  },
+  "metadata": {
+    "totalTime": 0,
+    "tokenCount": 0,
+    "retries": 0
+  }
+}
+```
+
+---
+
+## 8. Cache Inteligente
+
+Resultados de agentes se cachean para reúso:
+
+| Clave de caché | Se cachea | TTL | Beneficio |
+|---------------|-----------|-----|-----------|
+| `compress:{task.kind}` | Contexto comprimido | 1 hora | No re-comprimir por cada generate |
+| `fewshot:{kind}:{domain}` | Ejemplos encontrados | 1 día | No re-buscar en knowledge-repo |
+| `agent:{role}:{input_hash}` | Output del agente | 5 min | No re-ejecutar idéntico input |
+| `dag:{task_hash}` | Plan de tareas | 5 min | No re-planificar tarea idéntica |
+
+La caché vive en `.opencode/boost/cache/` y se limpia automáticamente.
+
+---
+
+## 9. Comparación: Plan Original vs Multi-Agente
+
+| Aspecto | Plan original (micro-tasking) | Multi-agente |
+|---------|------------------------------|--------------|
+| Modelo subyacente | 1 modelo principal | Múltiples modelos pequeños |
+| Paralelismo | Solo secuencial | Paralelo + secuencial |
+| Especialización | El mismo modelo hace todo | Agentes especializados |
+| Tolerancia a fallos | Si falla, reinicia | Reasigna agente |
+| Cache | No | Sí, por agente |
+| Costo hardware | GPU grande (24GB+) | GPU modesta (8-12GB) |
+| DAG | Lineal | Grafo dirigido con dependencias |
+| AI Cleaner | No | Sí (agente dedicado) |
+
+---
+
+## 10. Tickets Actualizados (versión Multi-Agente)
+
+| ID | Título | Depende de |
+|----|--------|------------|
+| BOOST-001 | ✅ Profile Registry + Config Base | — |
+| BOOST-002 | Context Compressor (Capa 1 + AI Cleaner) | BOOST-001 |
+| BOOST-003 | Template Hydration System | BOOST-001 |
+| BOOST-004 | Few-Shot Engine | BOOST-001 |
+| BOOST-005 | Agent Pool + Task Dispatcher | BOOST-001 |
+| BOOST-006 | Agentes Especializados (types, state, logic) | BOOST-005 |
+| BOOST-007 | Validation Loop + Agent Validate | BOOST-006 |
+| BOOST-008 | Orchestrator (index.js + progressive pipeline) | BOOST-007 |
+| BOOST-009 | Cache System | BOOST-008 |
+| BOOST-010 | CLI + MCP Integration | BOOST-009 |
+| BOOST-011 | Auto-aprendizaje: feedback entre sesiones | BOOST-010 |
+
+---
+
+## 11. Preguntas Abiertas para Discutir
+
+1. **¿Paralelismo real o cola?** — ¿Vale la pena tener múltiples instancias del modelo, o basta una en cola (más lento pero menos RAM)?
+
+2. **¿Cuántos agentes simultáneos?** — 3 en paralelo? 5? ¿El usuario configura?
+
+3. **¿Soporte para diferentes providers?** — Solo Ollama? ¿O también OpenAI API, Anthropic? Podríamos mezclar: un agente barato (local) + otro caro (API) solo para validación.
+
+4. **¿Cache por sesión o persistente?** — TTL de 1 hora parece razonable, pero ¿el usuario puede limpiar manualmente?
+
+5. **¿Cuándo activar Boost automáticamente?** — ¿Solo cuando el perfil es "small"? ¿O también como opción voluntaria en "medium"?
+
+6. **¿El AI Cleaner debe ser obligatorio?** — ¿O el usuario decide si quiere usar un modelo para comprimir contexto (más preciso) o la capa determinística (más rápido)?
+
+7. **¿Cómo exponer el DAG al usuario?** — Un `opl boost microtask --dag` que muestre el grafo antes de ejecutar, para que el usuario entienda qué va a pasar.
+
+---
+
+## 12. Recursos Relacionados
+
+- **Paper**: Mixture-of-Agents Enhances Large Language Model Capabilities (Together AI, 2024)
+- **Tecnología base**: Ollama (`ollama run deepseek-coder-7b`)
+- **Proyecto OPL existente**: `src/boost/` (en construcción), `src/cli/commands-boost.js`
+- **Tickets activos**: `docs/04-TICKETS/INDEX.md`
+
+---
+
+*Este documento es un diseño vivo. Se actualiza a medida que evoluciona el módulo Boost.*

package/docs/02-STANDARDS/AGENTS.template.md

@@ -0,0 +1,89 @@
+# AGENTS.template.md — Plantilla Universal para Proyectos
+
+> **Versión:** 1.0
+> **Uso:** La IA debe ejecutar el Protocolo de Inicialización al detectar un proyecto sin AGENTS.md o con AGENTS.md incompleto.
+
+---
+
+## Protocolo de Inicialización — EJECUTAR AUTOMÁTICAMENTE
+
+Cuando la IA detecte un proyecto NUEVO o un proyecto EXISTENTE sin AGENTS.md completo, DEBE ejecutar los siguientes pasos EN ORDEN:
+
+### Paso 1: Detectar el stack del proyecto
+```
+Leer package.json:
+- Buscar en dependencies/devDependencies: react, vue, angular, next, svelte, etc.
+- Buscar runtime: node, deno, bun
+- Buscar DB: supabase, firebase, prisma, mongoose, etc.
+- Buscar CSS: tailwind, styled-components, emotion, etc.
+- Buscar lenguaje: typescript (tsconfig.json), javascript
+- Buscar plataforma: ionic, capacitor, tauri, electron, etc.
+```
+
+### Paso 2: Inicializar openPrompt-Lang
+```
+ejecutar: opl init → Crea prompt-lang.json y estructura base docs/
+```
+
+### Paso 3: Generar AGENTS.md con el stack detectado
+```
+Copiar ESTE archivo como AGENTS.md en la raíz del proyecto.
+Reemplazar "## Stack" con las tecnologías detectadas.
+Reemplazar "## Perfil" según nivel (senior por defecto).
+```
+
+### Paso 4: Detectar archivos fuente sin anotaciones
+```
+ejecutar: npx openprompt-lang validate
+Archivos que DEBEN tener @use: service, hook, page, context, component
+```
+
+### Paso 5: Verificar cobertura
+```
+Calcular: (archivos con @use / archivos que deben tener @use) * 100
+Si cobertura < 80% → seguir agregando anotaciones
+```
+
+### Paso 6: Verificar estado del proyecto
+```
+ejecutar: npx tsc --noEmit → 0 errores
+ejecutar: npx openprompt-lang validate → 0 errores
+```
+
+---
+
+## Stack
+<!-- COMPLETAR con tecnologías del proyecto -->
+- react
+- tailwind
+- typescript
+
+## Convenciones
+- Anotaciones OPL con @kind, @contract, @limit
+- NO usar any
+- NO superar límites de líneas sin refactorizar
+- TODO list para tareas >3 pasos
+
+## Enforcement — REGLAS QUE SE CUMPLEN O SE BLOQUEA
+
+```
+PRE-COMMIT HOOK ACTIVO:
+  npx openprompt-lang validate --strict + tsc --noEmit
+  Bloquea commits si hay violaciones @limit
+
+REGLA FUNDAMENTAL:
+  @limit(lines: N) NO es una sugerencia — es un LÍMITE que bloquea el commit.
+  Si un archivo supera su @limit, refactorizar ANTES de committear.
+
+LECCIÓN APRENDIDA (RULES-001):
+  Las reglas sin enforcement son aspiraciones.
+  Las reglas CON enforcement son restricciones. Este proyecto usa enforcement.
+```
+
+## Perfil
+<!-- COMPLETAR: senior, mid, junior -->
+senior
+
+## Referencias
+- Framework: openPrompt-Lang
+- Tickets OPL: `opl ticket list`