openprompt-lang 1.3.0 → 1.4.0

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`

package/docs/02-STANDARDS/ticket-driven-development.md

@@ -0,0 +1,99 @@
+# Ticket-Driven Development con openPrompt-Lang
+
+> **Propósito:** Documentar el proceso de trabajo que combina tickets ágiles, sprints y anotaciones `@learn-error` de OPL. Este documento sirve como referencia obligatoria y como input para mejorar el workflow de OPL en siguientes versiones.
+
+---
+
+## El Workflow: Bug → Ticket → Fix → Learn-Error
+
+### Regla de Oro
+> **No se fixea nada sin un ticket primero.**
+> Todo bug, por mínimo que sea, debe generar un TICKET-NNN antes de escribir código.
+
+### Ciclo Completo
+```
+1. DETECTAR → 2. TICKET → 3. FIX → 4. QA → 5. LEARN → 6. ARCHIVAR
+```
+
+#### Paso 1: Detectar
+- Puede venir de: `npx tsc --noEmit`, `npx openprompt-lang validate`, auditoría manual, QA tests
+
+#### Paso 2: Crear Ticket
+- Ubicación: `docs/04-TICKETS/TICKET-NNN-descripcion.md`
+- Numeración correlativa global
+
+#### Paso 3: Fix
+- Hacer cambios en el código
+- Si se descubre otro bug durante el fix, crear **nuevo ticket**
+
+#### Paso 4: QA
+- `npx tsc --noEmit` — debe pasar sin errores
+- `npx openprompt-lang validate` — debe pasar sin errores
+
+#### Paso 5: Learn-Error
+```typescript
+// @learn-error id=MODULO-NNN
+// input='qué se hizo mal'
+// expected='qué debería pasar'
+// actual='qué pasó realmente'
+// fix='cómo se corrigió'
+// category=dominio
+```
+
+#### Paso 6: Archivar (Opcional)
+- Sprint cerrado = tickets referenciados y archivados
+
+---
+
+## Estructura de Tickets
+
+```markdown
+# TICKET-NNN: Título Descriptivo
+
+> **Sprint:** Sprint-N
+> **Prioridad:** 🔴 Crítica | 🟠 Alta | 🟡 Media | 🟢 Baja
+> **Esfuerzo:** Xh
+
+## Contexto
+[2-3 párrafos explicando el problema]
+
+## Acceptance Criteria
+- [ ] CRITERIO-1: Descripción verificable
+- [ ] CRITERIO-2: Incluye edge cases
+
+## QA Tests
+```bash
+# Test: comando para verificar
+```
+```
+
+---
+
+## Mejoras Propuestas para OPL v2
+
+### 1. Nuevo Workflow "bug → ticket"
+Paso obligatorio `create_ticket` antes de fix en el default workflow.
+
+### 2. Integración de TODO List
+Auto-creación de TODO list al comenzar tarea >3 pasos.
+
+### 3. Anchored Summary Automático
+Al cerrar sesión, generar resumen desde TODOs completados.
+
+### 4. QA Tests Como Comandos
+```yaml
+acceptance:
+  - cmd: "npx tsc --noEmit"
+    expect: "exit code 0"
+```
+
+### 5. Categorías Controladas para @learn-error
+Enum validado por el validador (no strings libres).
+
+### 6. Archivo de Tickets como Formato Reconocido
+OPL debería reconocer `docs/04-TICKETS/TICKET-NNN-*.md` y validar su estructura.
+
+### 7. Cross-Reference entre Tickets y Código
+```typescript
+// @ref-ticket(TICKET-023)
+```

package/docs/04-TICKETS/BOOST-001-profile-registry.md

@@ -0,0 +1,66 @@
+# BOOST-001 — Profile Registry + Config Base
+
+## Metadatos
+
+| Campo | Valor |
+|-------|-------|
+| **ID** | BOOST-001 |
+| **Título** | Profile Registry + Config Base |
+| **Épica** | Módulo OPL Boost |
+| **Prioridad** | Alta |
+| **Estado** | ✅ Completado |
+| **Depende de** | — |
+| **Archivos** | `src/boost/profile-registry.js`, `prompt-lang.json` |
+
+## Descripción
+
+Crear el sistema de perfiles de modelo que permite a OPL detectar automáticamente la capacidad del modelo activo (small/medium/large) y configurar las estrategias de boost según el perfil.
+
+Este es el cimiento del módulo Boost — sin esto, ningún otro componente sabe cómo comportarse.
+
+## Criterios de Aceptación
+
+### CA-1: Perfiles definidos
+- [x] Existen 3 perfiles: `small` (8K contexto), `medium` (32K), `large` (128K+)
+- [x] Cada perfil define: `compressionLevel`, `validationLoops`, `microTasks`, `templateHydration`, `fewShot`, `contextWindow`
+- [x] Los valores por defecto son razonables (small: alta compresión, 3 loops; large: sin compresión, 1 loop)
+
+### CA-2: Detección automática
+- [x] Detecta perfil desde `process.env.OPL_BOOST_PROFILE`
+- [x] Detecta perfil desde `process.env.OPL_MODEL` (mapeo por nombre conocido: deepseek-coder → small, qwen2.5-coder → medium, gpt-4 → large)
+- [x] Detecta perfil desde configuración en `prompt-lang.json`
+- [x] Si no hay indicación, default: `medium` (seguro)
+
+### CA-3: API exportable
+- [x] `getProfile()` → devuelve el perfil activo con todos sus valores
+- [x] `setProfile(name)` → fuerza un perfil
+- [x] `listProfiles()` → lista los perfiles disponibles
+- [x] `detectProfile()` → lógica de detección automática
+
+### CA-4: Config en prompt-lang.json
+- [x] Sección `boost` agregada a `prompt-lang.json`
+- [x] `boost.enabled: true/false`
+- [x] `boost.defaultProfile: "auto" | "small" | "medium" | "large"`
+- [x] `boost.profiles` con la configuración de cada perfil
+
+### CA-5: CLI check
+- [x] `opl boost check` muestra diagnóstico: perfil detectado, valores activos, modo
+
+### CA-6: Tests
+- [ ] Tests unitarios para detección de perfil (con variables de entorno mock)
+- [ ] Tests para valores por defecto
+- [ ] Tests para forzar perfil
+
+## Archivos a crear/modificar
+
+| Archivo | Acción |
+|---------|--------|
+| `src/boost/profile-registry.js` | ➕ Crear |
+| `prompt-lang.json` | ✏️ Modificar (sección boost) |
+| `src/cli/commands-boost.js` | ➕ Crear (registro inicial con `opl boost check`) |
+
+## Notas técnicas
+
+- No debe tener dependencias externas más allá de `fs` y `path`
+- El perfil se cachea en memoria para no re-detectar en cada llamada
+- El CLI `opl boost check` debe funcionar incluso si el resto del módulo Boost no está implementado