openprompt-lang 1.3.0 → 1.4.0

package/docs/04-TICKETS/BOOST-012-prompt-preamble.md

@@ -0,0 +1,109 @@
+# BOOST-012 — Universal Workflow Preamble (System Prompt Injection)
+
+> **Nota:** Este ticket surge de una idea durante la sesión de implementación de Boost.
+> La idea es independiente del módulo Boost pero se integra naturalmente con él.
+
+## Metadatos
+
+| Campo | Valor |
+|-------|-------|
+| **ID** | BOOST-012 |
+| **Título** | Universal Workflow Preamble — System Prompt Injector |
+| **Épica** | OPL Workflow Enforcement |
+| **Prioridad** | Media |
+| **Estado** | ✅ Completado |
+| **Depende de** | — |
+| **Archivos** | `src/workflow/preamble.js`, `prompt-lang.json`, `AGENTS.md` |
+
+## Descripción
+
+Crear un mecanismo que inyecte un **mensaje de sistema** al inicio de cada interacción con la IA, forzando que siga el workflow OPL sin depender de MCP tools.
+
+El problema: actualmente el enforcement MCP solo funciona cuando la IA se conecta mediante el servidor MCP (OpenCode, Cursor). Si alguien usa la IA desde otro cliente (o si MCP no está disponible), no hay garantía de que siga el workflow.
+
+La solución: un **preamble universal** que se antepone a cada solicitud del usuario, instruyendo a la IA sobre el workflow obligatorio.
+
+## Idea Central
+
+```
+[Solicitud del usuario]
+  ↓
+[OPL Preamble Injector]  ← se antepone automáticamente
+  ├── "Debes seguir este workflow obligatorio antes de responder..."
+  ├── "1. workflow_select → 2. ticket_create → 3. check_gates → ..."
+  ├── "Reglas: no implementar sin ticket, no cerrar sin docs..."
+  └── [Solicitud original del usuario]
+  ↓
+[IA recibe el mensaje completo]
+```
+
+## Criterios de Aceptación
+
+### CA-1: Preamble configurable
+- [ ] Archivo `src/workflow/preamble.js` con el mensaje de sistema
+- [ ] El preamble se puede personalizar en `prompt-lang.json` → `preamble.enabled`, `preamble.text`
+- [ ] Por defecto incluye: workflow steps, reglas críticas, prohibiciones
+
+### CA-2: Modos de inyección
+- [ ] **Modo automático**: se inyecta en cada solicitud hecha a través de OPL
+- [ ] **Modo archivo**: se escribe en un archivo que el AI client lee (ej. `.opencode/preamble.md`)
+- [ ] **Modo hook**: se integra con el sistema de templates para que todo `ai-gen` lo incluya
+
+### CA-3: Contenido del preamble
+- [ ] Flujo obligatorio: workflow select → ticket create → check gates → plan → implement → validate → docs → close
+- [ ] Prohibiciones: no implementar sin ticket, no cerrar sin docs, no mutar sin analyze_blast_radius
+- [ ] Referencia a comandos OPL útiles
+- [ ] Máximo 300 palabras (no satura el contexto)
+- [ ] Debe ser markdown válido
+
+### CA-4: Integración con MCP
+- [ ] El preamble se envía como `systemPrompt` en el MCP server
+- [ ] Se incluye en `OPL_analyze_project` como parte del output
+- [ ] Se puede consultar con `OPL_workflow_preamble`
+
+### CA-5: Tests
+- [ ] Test que el preamble no excede 300 palabras
+- [ ] Test que las reglas críticas están presentes
+- [ ] Test de inyección en prompt
+
+## Archivos a crear/modificar
+
+| Archivo | Acción |
+|---------|--------|
+| `src/workflow/preamble.js` | ➕ Crear |
+| `prompt-lang.json` | ✏️ Modificar (sección preamble) |
+| `AGENTS.md` | ✏️ Modificar (referencia al preamble) |
+
+## Ejemplo de Preamble (borrador)
+
+```markdown
+## ⚠️ OPL Workflow Obligatorio
+
+Antes de implementar cualquier cosa, DEBES seguir este orden:
+
+1. `opl workflow select <descripción>` — Seleccionar workflow
+2. `opl ticket create` — Crear ticket (sin ticket no hay código)
+3. `opl check gates` — Verificar prerrequisitos
+4. `work_context_plan` — Planificar (features/refactors)
+5. Implementar con anotaciones OPL primero
+6. `npx openprompt-lang validate` — Validar
+7. Actualizar documentación
+8. `work_context_close` — Cerrar sesión
+
+### ⛔ Prohibido
+- Implementar sin ticket
+- Cerrar sin documentación
+- Mutar código sin analyze_blast_radius
+- Modificar *.template.* archivos
+```
+
+## Notas técnicas
+
+- No debe ser un archivo más que la IA tenga que leer — debe ser INYECTADO activamente
+- Se puede implementar como un wrapper que envuelve la solicitud del usuario
+- Para OpenCode: se puede configurar como `systemPrompt` en `opencode.json`
+- El preamble idealmente se regenera dinámicamente según el estado actual del proyecto (tickets abiertos, perfil activo, etc.)
+
+---
+
+*Idea original: durante sesión de implementación de OPL Boost, mayo 2026*

package/docs/04-TICKETS/BOOST-013-hydrator-duplicate-code.md

@@ -0,0 +1,132 @@
+# BOOST-013 — Hydrator duplica código generado por LLM
+
+## Metadatos
+
+| Campo | Valor |
+|-------|-------|
+| **ID** | BOOST-013 |
+| **Título** | Hydrator duplica código cuando LLM genera output sin @kind |
+| **Épica** | Módulo OPL Boost |
+| **Prioridad** | Alta |
+| **Severidad** | Bug |
+| **Estado** | ✅ Resuelto |
+| **Archivos** | `src/boost/orchestrator.js`, `src/boost/hydrator.js` |
+
+## Descripción
+
+Cuando el LLM (Ollama) genera código completo que **no contiene** `@kind()`, el hydrator lo envuelve dentro de un skeleton template, resultando en código duplicado. El archivo final contiene:
+
+1. El skeleton template con placeholders sin reemplazar
+2. El código crudo del LLM dentro del placeholder `PLACEHOLDER_LOGIC`
+3. Una función `Generated()` que envuelve el código nuevamente
+
+### Ejemplo del output duplicado
+
+```typescript
+// Skeleton template for @kind(hook)
+// Markers: , , , ```typescript
+import { useState } from 'react';     // <-- código del LLM empieza
+
+type CartItem = { ... };
+// ... 58 líneas de código funcional ...
+
+export default useCart;                 // <-- código del LLM termina
+```, default                              // <-- markers del skeleton
+// @use(kind, contract, limit)
+// @kind(hook)
+// @contract(in: unknown -> out: unknown @error: Error)
+
+export function Generated() {            // <-- wrapper del skeleton
+  ```typescript                          // <-- marker literal
+  import { useState } from 'react';    // <-- código del LLM DUPLICADO
+  // ... mismo código重复 ...
+  ```
+}
+export default Generated                // <-- export del skeleton
+```
+
+## Causa Raíz
+
+En `orchestrator.js`, línea 260-292 (`stageHydrate`):
+
+```javascript
+function stageHydrate(kind, code, profile) {
+  if (/@kind\(/.test(code)) {
+    return { ... code, hydrated: false }  // ✅ Si ya tiene @kind, pasa directo
+  }
+  
+  // ❌ Si no tiene @kind, intenta hidratar
+  const hydrated = hydrate(kind, {
+    imports: "",
+    types: "",
+    logic: code,      // <-- Todo el código del LLM va como "logic"
+    name: "Generated",
+    ...
+  })
+}
+```
+
+El hydrator interpola `logic` dentro del skeleton, pero como el LLM ya generó código completo (imports, types, exports), el resultado es un archivo con el código del LLM **más** el skeleton wrapper.
+
+## Solución Propuesta
+
+### Opción A: Smart detection (recomendada)
+Detectar si el código del LLM ya es un archivo completo (tiene imports y exports) y en ese caso:
+1. Agregar anotaciones OPL al inicio del archivo
+2. NO envolverlo en skeleton
+
+```javascript
+function stageHydrate(kind, code, profile) {
+  if (/@kind\(/.test(code)) {
+    return { code, hydrated: false }
+  }
+  
+  // NEW: Detectar código completo del LLM
+  const hasImports = /^import\s/m.test(code)
+  const hasExport = /^export\s/m.test(code)
+  
+  if (hasImports && hasExport) {
+    // Código completo del LLM — solo agregar anotaciones
+    const annotations = generateOPLAnnotations(kind, code)
+    return { 
+      code: annotations + "\n\n" + code, 
+      hydrated: false, 
+      reason: "llm-complete-injection" 
+    }
+  }
+  
+  // Código parcial — hidratar con skeleton
+  const hydrated = hydrate(kind, { logic: code, name: "Generated", ... })
+  return { code: hydrated.code, hydrated: true }
+}
+```
+
+### Opción B: Mejorar prompt del LLM
+Incluir en el system prompt del agente que la salida DEBE incluir `@kind()` para que el hydrator lo detecte y pase directo.
+
+### Opción C (combinada): A + B
+Mejorar el prompt + smart detection como fallback.
+
+## Pasos para Reproducir
+
+1. Ejecutar: `opl boost generate "hook useCart para carrito de compras" --kind hook`
+2. El LLM genera código completo sin @kind
+3. El hydrator envuelve en skeleton → código duplicado
+
+## Impacto
+
+- Archivos generados tienen ~2x más líneas de las necesarias
+- Código duplicado dentro de código funcional
+- Markers del skeleton (`\`\`\`typescript`, `default`) aparecen como texto literal
+- La validación pasa (quickValidate es leniente) pero el código no es utilizable directamente
+
+## @learn-error
+
+```
+// @learn-error id=BOOST-HYDRATE-001
+// input='Hydrator envuelve código completo del LLM en skeleton, creando duplicación'
+// expected='Código completo del LLM se usa directamente con anotaciones OPL inyectadas al inicio'
+// actual='Código del LLM aparece 2 veces: una dentro del skeleton y otra como contenido del placeholder'
+// fix='Implementar smart detection en stageHydrate: si el código tiene imports+exports, inyectar solo anotaciones OPL sin skeleton'
+// category=boost
+```

package/docs/04-TICKETS/BOOST-014-multiagent-missing-parts.md

@@ -0,0 +1,87 @@
+# BOOST-014 — Multi-agent mode falla con "Partes requeridas faltantes"
+
+## Metadatos
+
+| Campo | Valor |
+|-------|-------|
+| **ID** | BOOST-014 |
+| **Título** | Multi-agent mode falla al hidratar resultados del DAG |
+| **Épica** | Módulo OPL Boost |
+| **Prioridad** | Media |
+| **Severidad** | Bug |
+| **Estado** | ✅ Resuelto |
+| **Archivos** | `src/boost/orchestrator.js`, `src/boost/hydrator.js` |
+
+## Descripción
+
+Al ejecutar `opl boost generate` con `--multi-agent`, el pipeline falla con error:
+
+```
+✘ Error inesperado: Partes requeridas faltantes para "hook": name
+✘ Error inesperado: Partes requeridas faltantes para "store": name
+```
+
+El modo multi-agent ejecuta agentes especializados (types, state, logic, cleaner, validate) para cada nodo del DAG, pero los resultados no se mapean correctamente a las partes requeridas por el hydrator.
+
+## Causa Raíz
+
+En `orchestrator.js`, la función `stageGenerateMultiAgent` (línea 179-243):
+
+1. Ejecuta agentes en paralelo para los nodos sin dependencias
+2. Ejecuta agentes en secuencia para los nodos con dependencias
+3. Los resultados se almacenan como `{ types: "código...", state: "código...", logic: "código..." }`
+4. Se pasa a `hydrateFromAgentResults(kind, results)` que mapea `results.types` → `PLACEHOLDER_TYPES`, etc.
+
+Pero el hydrator requiere `name` como parte obligatoria para hook, component, service, store — y ningún agente genera explícitamente el `name`.
+
+```javascript
+// hydrator.js líneas 36-48
+const PLACEHOLDER_MAP = {
+  hook: {
+    required: ["name"],  // ← Falla aquí
+    placeholders: { ... }
+  },
+  ...
+}
+```
+
+## Solución Propuesta
+
+### Opción A: Extraer name del prompt de entrada
+Antes de pasar al hydrator, extraer el nombre del identificador de la tarea:
+
+```javascript
+function extractNameFromTask(task) {
+  // "hook useProducts para ..." → "useProducts"
+  // "service ProductService para ..." → "ProductService"
+  const match = task.match(/\b(use[A-Z]\w+|[A-Z]\w*Service|[A-Z]\w*Store|[A-Z]\w*Page)/)
+  return match ? match[1] : "Generated"
+}
+```
+
+### Opción B: Agente "name" en el DAG
+Añadir un paso de pre-procesamiento que extraiga el nombre del componente antes de los agentes.
+
+### Opción C: Hacer name opcional en hydrator
+Si no se provee `name`, usar "Generated" como default sin error.
+
+## Pasos para Reproducir
+
+1. Ejecutar: `opl boost generate "hook useAuth para autenticación" --kind hook --multi-agent`
+2. Error: `Partes requeridas faltantes para "hook": name`
+
+## Impacto
+
+- Modo `--multi-agent` es completamente no funcional
+- No se puede usar el pipeline multi-agente para ningún @kind
+
+## @learn-error
+
+```
+// @learn-error id=BOOST-MULTIAGENT-001
+// input='Ejecutar boost generate --multi-agent para cualquier @kind'
+// expected='Código generado por múltiples agentes especializados'
+// actual='Error: Partes requeridas faltantes para "kind": name'
+// fix='Extraer name del prompt de entrada antes de hidratar, o hacer name opcional con default "Generated"'
+// category=boost
+```

package/docs/04-TICKETS/BOOST-015-skeleton-type-missing.md

@@ -0,0 +1,76 @@
+# BOOST-015 — Skeleton "type" no soportado
+
+## Metadatos
+
+| Campo | Valor |
+|-------|-------|
+| **ID** | BOOST-015 |
+| **Título** | Skeleton @kind(type) no soportado — solo 5 kinds |
+| **Épica** | Módulo OPL Boost |
+| **Prioridad** | Baja |
+| **Severidad** | Feature |
+| **Estado** | ✅ Resuelto |
+| **Archivos** | `src/boost/skeletons/index.js`, `src/boost/hydrator.js`, `src/boost/task-dispatcher.js` |
+
+## Descripción
+
+Al ejecutar `opl boost generate "tipos TypeScript para ecommerce..." --kind type`, el sistema responde:
+
+```
+✘ Error inesperado: Skeleton desconocido: "type". Tipos: hook, component, page, service, store
+```
+
+Solo existen 5 skeletons: hook, component, page, service, store. Pero OPL define `@kind(type)` como un tipo válido en sus reglas de anotaciones (con `@limit(lines: sin límite)`).
+
+## Causa Raíz
+
+`skeletons/index.js` solo registra 5 tipos:
+
+```javascript
+const skeletons = {
+  hook: () => import("./hook.skeleton.js").then(m => m.default),
+  component: () => import("./component.skeleton.js").then(m => m.default),
+  page: () => import("./page.skeleton.js").then(m => m.default),
+  service: () => import("./service.skeleton.js").then(m => m.default),
+  store: () => import("./store.skeleton.js").then(m => m.default),
+}
+```
+
+Y `task-dispatcher.js` no tiene `type` en `detectKind()`.
+
+## Solución Propuesta
+
+### Crear type.skeleton.js
+Skeleton para archivos de tipos TypeScript:
+
+```typescript
+// @use(kind, limit)
+// @kind(type)
+// @limit(lines: 100)
+
+{{PLACEHOLDER_IMPORTS}}
+
+{{PLACEHOLDER_TYPES}}
+
+{{PLACEHOLDER_EXPORTS}}
+```
+
+### Agregar a detectKind
+```javascript
+if (/\b(type|interface|types|typings|dtype)\b/.test(lower)) return "type"
+```
+
+### Registrar en skeletons/index.js
+```javascript
+type: () => import("./type.skeleton.js").then(m => m.default),
+```
+
+## Pasos para Reproducir
+
+1. `opl boost generate "tipos TypeScript para Product, CartItem, ApiResponse" --kind type`
+2. Error: `Skeleton desconocido: "type"`
+
+## Impacto
+
+- No se pueden generar archivos de tipos con Boost
+- Workaround: generar manualmente o usar `--kind service` como aproximación

package/docs/04-TICKETS/BOOST-016-output-path-duplicate.md

@@ -0,0 +1,68 @@
+# BOOST-016 — --output con ruta relativa crea estructura duplicada
+
+## Metadatos
+
+| Campo | Valor |
+|-------|-------|
+| **ID** | BOOST-016 |
+| **Título** | Flag --output con ruta relativa crea directorios duplicados |
+| **Épica** | Módulo OPL Boost |
+| **Prioridad** | Baja |
+| **Severidad** | Bug |
+| **Estado** | ✅ Resuelto |
+| **Archivos** | `src/boost/orchestrator.js`, `src/cli/commands-boost.js` |
+
+## Descripción
+
+Al ejecutar `opl boost generate "descripcion" --output /ruta/absoluta/archivo.ts`, se crea una estructura de directorios duplicada dentro del directorio de trabajo en lugar de usar la ruta directamente.
+
+### Ejemplo
+
+```bash
+cd /home/nodead/Escritorio/TestOPLBoost
+opl boost generate "hook useCart" --output /home/nodead/Escritorio/TestOPLBoost/useCart.ts
+```
+
+Resultado: el archivo se crea en:
+```
+/home/nodead/Escritorio/TestOPLBoost/home/nodead/Escritorio/TestOPLBoost/useCart.ts
+```
+
+En lugar de:
+```
+/home/nodead/Escritorio/TestOPLBoost/useCart.ts
+```
+
+## Causa Raíz
+
+En `orchestrator.js`, línea 417:
+
+```javascript
+const outputPath = join(process.cwd(), opts.output)
+```
+
+Si `opts.output` ya es una ruta absoluta, `path.join(cwd, '/absolute/path')` en algunos entornos puede comportarse inesperadamente. Además, `path.join` con una ruta absoluta debería mantener la ruta absoluta, pero el comportamiento real muestra que crea una estructura anidada.
+
+El problema real es que `join(process.cwd(), '/home/nodead/...')` en Node.js ignora el primer argumento cuando el segundo es absoluto... PERO si hay un pre-procesamiento del path en commands-boost.js, podría estar causando la duplicación.
+
+## Solución Propuesta
+
+```javascript
+// orchestrator.js línea 417
+const outputPath = path.isAbsolute(opts.output) 
+  ? opts.output 
+  : join(process.cwd(), opts.output)
+```
+
+Y en `commands-boost.js`, no transformar la ruta de output.
+
+## Pasos para Reproducir
+
+1. `cd /home/user/project`
+2. `opl boost generate "hook useCart" --output /home/user/project/src/hooks/useCart.ts`
+3. Archivo se crea en `/home/user/project/home/user/project/src/hooks/useCart.ts`
+
+## Impacto
+
+- Archivos se guardan en ubicaciones incorrectas
+- Workaround: usar rutas relativas (`--output src/hooks/useCart.ts`)

package/docs/04-TICKETS/INDEX.md

@@ -0,0 +1,89 @@
+# Índice de Tickets — Módulo OPL Boost
+
+> **Épica**: Sistema multi-agente para potenciar modelos pequeños de IA
+> **Arquitectura**: MoA (Mixture of Agents) — modelos colaborando como núcleos de CPU
+> **Versión objetivo**: OPL 1.4.0
+> **Documento de diseño**: `docs/00-ARCHITECTURE/OPL-BOOST-MULTI-AGENT.md`
+> **Código fuente**: `src/boost/`
+
+## Tickets
+
+| ID | Título | Prioridad | Estado | Depende de |
+|----|--------|-----------|--------|------------|
+| [BOOST-001](./BOOST-001-profile-registry.md) | Profile Registry + Config Base | Alta | ✅ Completado | — |
+| [BOOST-002](./BOOST-002-context-compression.md) | Context Compressor + AI Cleaner | Alta | ✅ Completado | BOOST-001 |
+| [BOOST-003](./BOOST-003-template-hydration.md) | Template Hydration System | Alta | ✅ Completado | BOOST-001 |
+| [BOOST-004](./BOOST-004-fewshot-engine.md) | Few-Shot Example Engine | Media | ✅ Completado | BOOST-001 |
+| [BOOST-005](./BOOST-005-agent-pool.md) | Agent Pool + Ollama Connector | Alta | ✅ Completado | BOOST-001 |
+| [BOOST-006](./BOOST-006-specialized-agents.md) | Agentes Especializados | Alta | ✅ Completado | BOOST-005 |
+| [BOOST-007](./BOOST-007-validation-loop.md) | Validation Loop + Agent Validate | Alta | ✅ Completado | BOOST-006 |
+| [BOOST-008](./BOOST-008-orchestrator.md) | Orchestrator (pipeline unificado) | Alta | ✅ Completado | BOOST-007 |
+| [BOOST-009](./BOOST-009-cache-system.md) | Cache System | Media | ✅ Completado | BOOST-008 |
+| [BOOST-010](./BOOST-010-cli-mcp.md) | CLI + MCP Integration | Media | ✅ Completado | BOOST-009 |
+| [BOOST-011](./BOOST-011-self-learning.md) | Auto-aprendizaje entre sesiones | Baja | ✅ Completado | BOOST-010 |
+| [BOOST-012](./BOOST-012-prompt-preamble.md) | Universal Workflow Preamble | Media | ✅ Completado | — |
+| [BOOST-013](./BOOST-013-hydrator-duplicate-code.md) | Hydrator duplica código del LLM | Alta | ✅ Resuelto | BOOST-003 |
+| [BOOST-014](./BOOST-014-multiagent-missing-parts.md) | Multi-agent falla con partes faltantes | Media | ✅ Resuelto | BOOST-008 |
+| [BOOST-015](./BOOST-015-skeleton-type-missing.md) | Skeleton @kind(type) no soportado | Baja | ✅ Resuelto | BOOST-003 |
+| [BOOST-016](./BOOST-016-output-path-duplicate.md) | --output con ruta absoluta duplica directorios | Baja | ✅ Resuelto | BOOST-010 |
+
+## Resumen
+
+| Estado | Cantidad |
+|--------|----------|
+| ✅ Completado | 12 |
+| ✅ Resuelto | 4 |
+
+## Archivos implementados
+
+| Archivo | Ticket | Líneas | Descripción |
+|---------|--------|--------|-------------|
+| `src/boost/profile-registry.js` | BOOST-001 | 264 | Perfiles, detección, API |
+| `src/boost/hardware-detector.js` | BOOST-001* | 490 | Detección HW, setup, monitoreo |
+| `src/boost/agent-pool.js` | BOOST-005 | 446 | Pool, Ollama, cola FIFO |
+| `src/boost/agents/index.js` | BOOST-006 | 79 | Registro de 5 agentes |
+| `src/boost/context-compressor.js` | BOOST-002 | 358 | Compresión determinística |
+| `src/boost/hydrator.js` | BOOST-003 | ~300 | Hidratación skeletons + anotaciones |
+| `src/boost/skeletons/*.js` | BOOST-003 | ~110 | 5 skeletons por @kind |
+| `src/boost/fewshot-retriever.js` | BOOST-004 | ~250 | Búsqueda por relevancia |
+| `src/boost/validation-loop.js` | BOOST-007 | ~300 | Feedback loop + validación |
+| `src/boost/task-dispatcher.js` | BOOST-008 | ~135 | DAG planner |
+| `src/boost/orchestrator.js` | BOOST-008 | ~350 | Pipeline single-pass + multi-agent |
+| `src/boost/cache.js` | BOOST-009 | ~245 | Caché en disco con TTL |
+| `src/boost/self-learn.js` | BOOST-011 | ~200 | Métricas y auto-perfilado |
+| `src/boost/preamble.js` | BOOST-012 | ~150 | Preamble de workflow |
+| `src/boost/index.js` | BOOST-008 | ~60 | API pública unificada |
+| `src/cli/commands-boost.js` | BOOST-010 | ~400 | 6 comandos CLI |
+| `src/mcp-refactor/handlers/boost.js` | BOOST-010 | ~250 | 5 tools MCP |
+
+**Total: ~3,700 líneas de código implementadas**
+
+## Comandos CLI disponibles
+
+```
+opl boost check          → Diagnóstico del perfil activo + estado del sistema
+opl boost profile [name] → Ver/forzar perfil (small/medium/large/auto)
+opl boost setup           → Detectar hardware + configurar Boost
+opl boost generate <desc> → Generar código con pipeline completo
+opl boost microtask <task> → Descomponer tarea en DAG de micro-tareas
+opl boost cache [action]  → Gestionar caché (stats, clear, clean)
+```
+
+## Tools MCP disponibles
+
+```
+OPL_Boost_generate    → Genera código usando el pipeline completo
+OPL_Boost_compress   → Comprime contexto según perfil y tarea
+OPL_Boost_profile    → Muestra perfil Boost + estado del sistema
+OPL_Boost_plan       → Planifica DAG de micro-tareas
+OPL_Boost_validate   → Valida código generado con feedback
+```
+
+## Notas
+
+- Todos los tickets completados ✅
+- La arquitectura es MoA (Mixture of Agents) — ver `docs/00-ARCHITECTURE/OPL-BOOST-MULTI-AGENT.md`
+- El pipeline funciona en dos modos: single-pass (default) y multi-agent (opt-in con `--multi-agent`)
+- BOOST-012 (preamble) es un sistema independiente que se puede usar sin el resto de Boost
+- Tickets antiguos (micro-tasking lineal) archivados en `_archive/`
+- **v1.3.0**: Testing con Ollama reveló 4 bugs (BOOST-013 a BOOST-016) — hydrator duplica código, multi-agent falla, skeleton type falta, output path duplica

package/docs/04-TICKETS/_archive/BOOST-005-micro-tasking.md

@@ -0,0 +1,67 @@
+# BOOST-005 — Micro-Tasking Engine
+
+## Metadatos
+
+| Campo | Valor |
+|-------|-------|
+| **ID** | BOOST-005 |
+| **Título** | Micro-Tasking Engine |
+| **Épica** | Módulo OPL Boost |
+| **Prioridad** | Alta |
+| **Estado** | 🔴 Pendiente |
+| **Depende de** | BOOST-003, BOOST-004 |
+| **Archivos** | `src/boost/micro-tasker.js` |
+
+## Descripción
+
+Motor que descompone tareas complejas de generación de código en micro-tareas secuenciales. Cada micro-tarea es una instrucción simple que un modelo pequeño puede seguir sin saturarse. El orquestador ejecuta las micro-tareas en cadena y el ensamblador une los resultados parciales en el archivo final.
+
+## Criterios de Aceptación
+
+### CA-1: Planificador de micro-tareas
+- [ ] `plan(task, kind)` → devuelve array de micro-tareas con: id, instrucción, formato esperado, validator
+- [ ] Para un hook: ["Define tipos/interface", "Define estado y efectos", "Implementa lógica", "Exporta"]
+- [ ] Para un componente: ["Define props", "Define variantes cva", "Implementa JSX", "Exporta"]
+- [ ] Para un page: ["Define imports y tipos", "Implementa layout", "Conecta datos", "Exporta"]
+
+### CA-2: Orquestador secuencial
+- [ ] `execute(task, kind, profile)` → ejecuta micro-tareas una por una
+- [ ] Cada micro-tarea se ejecuta con contexto mínimo (solo instrucción actual + resultado anterior)
+- [ ] Hay un shared state entre micro-tareas para mantener coherencia
+- [ ] Si una micro-tarea falla, el orquestador puede reintentarla (según perfil)
+
+### CA-3: Ensamblador
+- [ ] `assemble(partialResults, kind)` → combina resultados parciales en archivo final
+- [ ] Usa el hydrator (BOOST-003) para generar el código final con anotaciones
+- [ ] Si hay conflictos entre resultados parciales, resuelve con heurísticas (último valor gana)
+
+### CA-4: CLI microtask
+- [ ] `opl boost microtask "crea hook useAuth"` → muestra el plan de micro-tareas sin ejecutar
+- [ ] `opl boost microtask "crea hook useAuth" --execute` → ejecuta el plan
+- [ ] Opción `--verbose` muestra cada paso y su resultado
+- [ ] Opción `--plan-only` solo muestra el plan (alias de sin flag)
+
+### CA-5: Integración con generate
+- [ ] Cuando `opl boost generate` se ejecuta con perfil small, usa micro-tasking automáticamente
+- [ ] Cuando el perfil es medium, decide según complejidad de la tarea
+- [ ] Cuando el perfil es large, no usa micro-tasking
+
+### CA-6: Tests
+- [ ] Test de planificación para cada @kind que soporta
+- [ ] Test de orquestación con respuestas mock
+- [ ] Test de ensamblado con resultados parciales
+- [ ] Test de fallo de micro-tarea y reintento
+
+## Archivos a crear/modificar
+
+| Archivo | Acción |
+|---------|--------|
+| `src/boost/micro-tasker.js` | ➕ Crear |
+
+## Notas técnicas
+
+- El orquestador es el componente más complejo del módulo Boost
+- El shared state es un simple objeto JSON que se pasa entre micro-tareas
+- Cada micro-tarea tiene un `validator` opcional que verifica el output antes de pasar a la siguiente
+- Los validators pueden ser: validate OPL, typecheck básico, o función custom
+- El orquestador debe ser extensible para soportar nuevos tipos de micro-tareas