theus-cli-linux-arm64 0.2.84

package/vendor/theus-arsenal/commands/epica-sincronizar.md

@@ -0,0 +1,21 @@
+---
+description: Sincronizar cuerpos de issues de épicas, etiquetas e instantáneas locales de coordinación desde GitHub.
+argument-hint: [--repo <owner/repo>]
+---
+
+# /epica-sincronizar
+
+Ejecuta una sincronización determinista de los issues de épicas.
+
+> **Requiere configuración de repositorio:** este comando opera sobre issues de GitHub mediante la CLI `gh` autenticada y con permisos de lectura y escritura sobre el repositorio. Si el repositorio no está configurado, el agente lo indicará y se detendrá.
+
+Qué hace este comando (el agente aplica estos pasos con `gh issue list` / `gh issue view` / `gh issue edit`):
+
+1. Lee los cuerpos de los issues como estado canónico de cada épica.
+2. Reconcilia el bloque de coordinación con las etiquetas del issue.
+3. Escribe una instantánea local fresca de cada épica en `~/.theus/arsenal/`.
+4. Mantiene la caché local alineada con GitHub.
+
+Alias de compatibilidad:
+
+- `/proyectos`

package/vendor/theus-arsenal/commands/epica-validar.md

@@ -0,0 +1,21 @@
+---
+description: Validar la preparación de una épica, sus dependencias y la política de coordinación.
+argument-hint: <numero-de-issue> [--repo <owner/repo>]
+---
+
+# /epica-validar
+
+Valida una única épica antes de publicarla o de entregarla a revisión.
+
+> **Requiere configuración de repositorio:** este comando opera sobre issues de GitHub mediante la CLI `gh` autenticada y con permisos de lectura sobre el repositorio. Si el repositorio no está configurado, el agente lo indicará y se detendrá.
+
+Qué comprueba este comando (el agente aplica estas verificaciones con `gh issue view`):
+
+1. El estado de coordinación existe en el cuerpo del issue y es parseable.
+2. El estado de validación cumple la política definida.
+3. Las dependencias declaradas están cerradas.
+4. La épica está lista para la siguiente etapa del flujo de trabajo.
+
+Alias de compatibilidad:
+
+- `/control-calidad`

package/vendor/theus-arsenal/commands/evolucionar.md

@@ -0,0 +1,176 @@
+---
+description: Analiza los instintos aprendidos y sugiere o genera estructuras evolucionadas (comandos, skills, agentes)
+---
+
+# Comando Evolucionar
+
+## Implementación
+
+Ejecuta la CLI de instintos usando la ruta raíz del plugin:
+
+```bash
+python3 "${THEUS_PLUGIN_ROOT}/skills/aprendizaje-continuo-v2/scripts/instinct-cli.py" evolve [--generate]
+```
+
+O, si `THEUS_PLUGIN_ROOT` no está definido (instalación manual):
+
+```bash
+python3 ~/.theus/skills/aprendizaje-continuo-v2/scripts/instinct-cli.py evolve [--generate]
+```
+
+Analiza los instintos y agrupa los relacionados en estructuras de mayor nivel:
+- **Comandos**: cuando los instintos describen acciones que el usuario invoca explícitamente
+- **Skills**: cuando los instintos describen comportamientos que se activan automáticamente
+- **Agentes**: cuando los instintos describen procesos complejos de varios pasos
+
+## Uso
+
+```
+/evolucionar                    # Analiza todos los instintos y sugiere evoluciones
+/evolucionar --generate         # Además genera archivos en evolved/{skills,commands,agents}
+```
+
+## Reglas de evolución
+
+### → Comando (invocado por el usuario)
+Cuando los instintos describen acciones que un usuario pediría de forma explícita:
+- Varios instintos del tipo "cuando el usuario pida..."
+- Instintos con disparadores como "al crear un nuevo X"
+- Instintos que siguen una secuencia repetible
+
+Ejemplo:
+- `new-table-step1`: "al agregar una tabla de base de datos, crear la migración"
+- `new-table-step2`: "al agregar una tabla de base de datos, actualizar el esquema"
+- `new-table-step3`: "al agregar una tabla de base de datos, regenerar los tipos"
+
+→ Crea: el comando **new-table**
+
+### → Skill (activación automática)
+Cuando los instintos describen comportamientos que deberían ocurrir de forma automática:
+- Disparadores por coincidencia de patrones
+- Respuestas de manejo de errores
+- Aplicación de estilo de código
+
+Ejemplo:
+- `prefer-functional`: "al escribir funciones, preferir estilo funcional"
+- `use-immutable`: "al modificar estado, usar patrones inmutables"
+- `avoid-classes`: "al diseñar módulos, evitar el diseño basado en clases"
+
+→ Crea: la skill `functional-patterns`
+
+### → Agente (necesita profundidad/aislamiento)
+Cuando los instintos describen procesos complejos de varios pasos que se benefician del aislamiento:
+- Flujos de depuración
+- Secuencias de refactorización
+- Tareas de investigación
+
+Ejemplo:
+- `debug-step1`: "al depurar, primero revisar los logs"
+- `debug-step2`: "al depurar, aislar el componente que falla"
+- `debug-step3`: "al depurar, crear una reproducción mínima"
+- `debug-step4`: "al depurar, verificar el arreglo con un test"
+
+→ Crea: el agente **debugger**
+
+## Qué hacer
+
+1. Detectar el contexto del proyecto actual
+2. Leer los instintos del proyecto + los globales (ante conflicto de ID, el proyecto tiene prioridad)
+3. Agrupar los instintos por patrones de disparador/dominio
+4. Identificar:
+   - Candidatos a skill (grupos de disparadores con 2+ instintos)
+   - Candidatos a comando (instintos de flujo de trabajo con confianza alta)
+   - Candidatos a agente (grupos más grandes con confianza alta)
+5. Mostrar candidatos a promoción (proyecto → global) cuando aplique
+6. Si se pasa `--generate`, escribir los archivos en:
+   - Ámbito de proyecto: `~/.theus/arsenal/projects/<project-id>/evolved/`
+   - Alternativa global: `~/.theus/arsenal/evolved/`
+
+## Formato de salida
+
+```
+============================================================
+  ANÁLISIS DE EVOLUCIÓN - 12 instintos
+  Proyecto: my-app (a1b2c3d4e5f6)
+  De proyecto: 8 | Globales: 4
+============================================================
+
+Instintos de alta confianza (>=80%): 5
+
+## CANDIDATOS A SKILL
+1. Grupo: "agregar tests"
+   Instintos: 3
+   Confianza promedio: 82%
+   Dominios: testing
+   Ámbitos: proyecto
+
+## CANDIDATOS A COMANDO (2)
+  /adding-tests
+    Origen: test-first-workflow [proyecto]
+    Confianza: 84%
+
+## CANDIDATOS A AGENTE (1)
+  adding-tests-agent
+    Cubre 3 instintos
+    Confianza promedio: 82%
+```
+
+## Flags
+
+- `--generate`: genera los archivos evolucionados además de la salida de análisis
+
+## Formato de los archivos generados
+
+### Comando
+```markdown
+---
+description: Crear una nueva tabla de base de datos con migración, actualización de esquema y generación de tipos
+evolved_from:
+  - new-table-migration
+  - update-schema
+  - regenerate-types
+---
+
+# Comando New Table
+
+[Contenido generado a partir de los instintos agrupados]
+
+## Pasos
+1. ...
+2. ...
+```
+
+### Skill
+```markdown
+---
+description: Aplicar patrones de programación funcional
+evolved_from:
+  - prefer-functional
+  - use-immutable
+  - avoid-classes
+---
+
+# Skill de Patrones Funcionales
+
+[Contenido generado a partir de los instintos agrupados]
+```
+
+### Agente
+```markdown
+---
+description: Agente de depuración sistemática
+evolved_from:
+  - debug-check-logs
+  - debug-isolate
+  - debug-reproduce
+---
+
+# Agente Debugger
+
+[Contenido generado a partir de los instintos agrupados]
+```
+
+## Relacionados
+
+- Skill: `aprendizaje-continuo-v2`
+- Comandos: `/aprender`, `/instintos-estado`, `/promover`, `/podar`

package/vendor/theus-arsenal/commands/funcionalidad.md

@@ -0,0 +1,49 @@
+---
+description: Desarrollo guiado de funcionalidades con comprensión del código existente y foco en la arquitectura
+---
+
+Un flujo estructurado de desarrollo de funcionalidades que prioriza entender el código existente antes de escribir código nuevo.
+
+## Fases
+
+### 1. Descubrimiento
+
+- lee la solicitud de la funcionalidad con atención
+- identifica requisitos, restricciones y criterios de aceptación
+- haz preguntas aclaratorias si la solicitud es ambigua
+
+### 2. Exploración del código
+
+- usa `explorador-codigo` para analizar el código existente relevante
+- traza rutas de ejecución y capas de arquitectura
+- entiende los puntos de integración y las convenciones
+
+### 3. Preguntas aclaratorias
+
+- presenta los hallazgos de la exploración
+- haz preguntas puntuales de diseño y de casos límite
+- espera la respuesta del usuario antes de continuar
+
+### 4. Diseño de arquitectura
+
+- usa `arquitecto-codigo` para diseñar la funcionalidad
+- entrega el plano de implementación
+- espera la aprobación antes de implementar
+
+### 5. Implementación
+
+- implementa la funcionalidad siguiendo el diseño aprobado
+- prefiere TDD donde sea apropiado
+- mantén commits pequeños y enfocados
+
+### 6. Revisión de calidad
+
+- usa `revisor-codigo` para revisar la implementación
+- atiende los problemas críticos e importantes
+- verifica la cobertura de tests
+
+### 7. Resumen
+
+- resume lo que se construyó
+- lista los pendientes de seguimiento o las limitaciones
+- proporciona instrucciones de prueba

package/vendor/theus-arsenal/commands/guardar-sesion.md

@@ -0,0 +1,278 @@
+---
+description: Guarda el estado de la sesión actual en un archivo fechado dentro de ~/.theus/arsenal/session-data/ para poder retomar el trabajo en una sesión futura con todo el contexto.
+---
+
+# Comando Guardar Sesión
+
+Captura todo lo que ocurrió en esta sesión — qué se construyó, qué funcionó, qué falló, qué queda pendiente — y escríbelo en un archivo fechado para que la siguiente sesión pueda retomar exactamente donde esta se quedó.
+
+## Cuándo usarlo
+
+- Al final de una sesión de trabajo, antes de cerrar Theus
+- Antes de alcanzar los límites de contexto (ejecuta esto primero y luego inicia una sesión nueva)
+- Después de resolver un problema complejo que quieres recordar
+- Cada vez que necesites traspasar contexto a una sesión futura
+
+## Proceso
+
+### Paso 1: Reunir el contexto
+
+Antes de escribir el archivo, recopila:
+
+- Lee todos los archivos modificados durante esta sesión (usa git diff o recuerda de la conversación)
+- Repasa qué se discutió, qué se intentó y qué se decidió
+- Anota los errores encontrados y cómo se resolvieron (o no)
+- Verifica el estado actual de tests/build si es relevante
+
+### Paso 2: Crear la carpeta de sesiones si no existe
+
+Crea la carpeta canónica de sesiones en el directorio home de Theus del usuario:
+
+```bash
+mkdir -p ~/.theus/arsenal/session-data
+```
+
+### Paso 3: Escribir el archivo de sesión
+
+Crea `~/.theus/arsenal/session-data/YYYY-MM-DD-<short-id>-session.tmp`, usando la fecha real de hoy y un short-id que cumpla las reglas impuestas por `SESSION_FILENAME_REGEX` en `session-manager.js`:
+
+- Caracteres de compatibilidad: letras `a-z` / `A-Z`, dígitos `0-9`, guiones `-`, guiones bajos `_`
+- Longitud mínima de compatibilidad: 1 carácter
+- Estilo recomendado para archivos nuevos: letras minúsculas, dígitos y guiones, con 8+ caracteres para evitar colisiones
+
+Ejemplos válidos: `abc123de`, `a1b2c3d4`, `frontend-worktree-1`, `ChezMoi_2`
+Evitar en archivos nuevos: `A`, `test_id1`, `ABC123de`
+
+Ejemplo completo de nombre de archivo válido: `2024-01-15-abc123de-session.tmp`
+
+El nombre heredado `YYYY-MM-DD-session.tmp` sigue siendo válido, pero los archivos de sesión nuevos deben preferir la forma con short-id para evitar colisiones el mismo día.
+
+### Paso 4: Completar el archivo con todas las secciones siguientes
+
+Escribe cada sección con honestidad. No omitas secciones — escribe "Nada aún" o "N/A" si una sección genuinamente no tiene contenido. Un archivo incompleto es peor que una sección vacía honesta.
+
+### Paso 5: Mostrar el archivo al usuario
+
+Después de escribirlo, muestra el contenido completo y pregunta:
+
+```
+Sesión guardada en [ruta real resuelta del archivo de sesión]
+
+¿Se ve correcto? ¿Algo que corregir o agregar antes de cerrar?
+```
+
+Espera confirmación. Haz las ediciones que se pidan.
+
+---
+
+## Formato del archivo de sesión
+
+```markdown
+# Sesión: YYYY-MM-DD
+
+**Inicio:** [hora aproximada si se conoce]
+**Última actualización:** [hora actual]
+**Proyecto:** [nombre o ruta del proyecto]
+**Tema:** [resumen de una línea de qué trató esta sesión]
+
+---
+
+## Qué estamos construyendo
+
+[1-3 párrafos describiendo la funcionalidad, el fix o la tarea. Incluye
+suficiente contexto para que alguien sin ninguna memoria de esta sesión pueda
+entender el objetivo. Incluye: qué hace, por qué se necesita, cómo encaja en
+el sistema más amplio.]
+
+---
+
+## Qué FUNCIONÓ (con evidencia)
+
+[Lista solo cosas confirmadas como funcionando. Para cada ítem incluye POR QUÉ
+sabes que funciona — el test pasó, corrió en el navegador, Postman devolvió 200, etc.
+Sin evidencia, muévelo a "Sin intentar todavía".]
+
+- **[cosa que funciona]** — confirmado por: [evidencia específica]
+- **[cosa que funciona]** — confirmado por: [evidencia específica]
+
+Si aún no hay nada confirmado: "Nada confirmado funcionando todavía — todos los enfoques siguen en curso o sin probar."
+
+---
+
+## Qué NO funcionó (y por qué)
+
+[Esta es la sección más importante. Lista cada enfoque intentado que falló.
+Para cada fallo escribe la razón EXACTA para que la siguiente sesión no lo
+reintente. Sé específico: "lanzó el error X porque Y" es útil. "no funcionó" no lo es.]
+
+- **[enfoque intentado]** — falló porque: [razón exacta / mensaje de error]
+- **[enfoque intentado]** — falló porque: [razón exacta / mensaje de error]
+
+Si nada falló: "Aún no hay enfoques fallidos."
+
+---
+
+## Qué NO se ha intentado todavía
+
+[Enfoques que parecen prometedores pero no se han intentado. Ideas surgidas
+en la conversación. Soluciones alternativas que vale la pena explorar. Sé lo
+bastante específico para que la siguiente sesión sepa exactamente qué probar.]
+
+- [enfoque / idea]
+- [enfoque / idea]
+
+Si no hay nada en cola: "No se identificaron enfoques específicos sin intentar."
+
+---
+
+## Estado actual de los archivos
+
+[Cada archivo tocado en esta sesión. Sé preciso sobre el estado de cada uno.]
+
+| Archivo           | Estado          | Notas                        |
+| ----------------- | --------------- | ---------------------------- |
+| `ruta/a/archivo.ts` | PASA: Completo    | [qué hace]                   |
+| `ruta/a/archivo.ts` |  En progreso    | [qué está hecho, qué falta]  |
+| `ruta/a/archivo.ts` | FALLA: Roto       | [qué está mal]               |
+| `ruta/a/archivo.ts` |  Sin empezar    | [planeado pero no tocado]    |
+
+Si no se tocó ningún archivo: "No se modificaron archivos en esta sesión."
+
+---
+
+## Decisiones tomadas
+
+[Elecciones de arquitectura, tradeoffs aceptados, enfoques elegidos y por qué.
+Evitan que la siguiente sesión relitigue decisiones ya cerradas.]
+
+- **[decisión]** — razón: [por qué se eligió esto sobre las alternativas]
+
+Si no hubo decisiones significativas: "No se tomaron decisiones importantes en esta sesión."
+
+---
+
+## Bloqueantes y preguntas abiertas
+
+[Cualquier cosa sin resolver que la siguiente sesión deba abordar o investigar.
+Preguntas que surgieron pero no se respondieron. Dependencias externas en espera.]
+
+- [bloqueante / pregunta abierta]
+
+Si no hay: "Sin bloqueantes activos."
+
+---
+
+## Siguiente paso exacto
+
+[Si se conoce: la única cosa más importante que hacer al retomar. Sé lo
+bastante preciso para que retomar no requiera pensar por dónde empezar.]
+
+[Si no se conoce: "Siguiente paso sin determinar — revisa las secciones 'Qué NO
+se ha intentado todavía' y 'Bloqueantes' para decidir la dirección antes de empezar."]
+
+---
+
+## Notas de entorno y configuración
+
+[Completa esto solo si es relevante — comandos necesarios para correr el proyecto,
+variables de entorno requeridas, servicios que deben estar corriendo, etc.
+Omite si la configuración es estándar.]
+
+[Si no hay: omite esta sección por completo.]
+```
+
+---
+
+## Ejemplo de salida
+
+```markdown
+# Sesión: 2024-01-15
+
+**Inicio:** ~2pm
+**Última actualización:** 5:30pm
+**Proyecto:** my-app
+**Tema:** Construyendo autenticación JWT con cookies httpOnly
+
+---
+
+## Qué estamos construyendo
+
+Sistema de autenticación de usuarios para la app Next.js. Los usuarios se registran
+con email/contraseña, reciben un JWT almacenado en una cookie httpOnly (no localStorage),
+y las rutas protegidas verifican un token válido vía middleware. El objetivo es la
+persistencia de sesión entre recargas del navegador sin exponer el token a JavaScript.
+
+---
+
+## Qué FUNCIONÓ (con evidencia)
+
+- **Endpoint `/api/auth/register`** — confirmado por: POST en Postman devuelve 200 con
+  el objeto usuario, fila visible en el dashboard de Supabase, hash bcrypt almacenado correctamente
+- **Generación de JWT en `lib/auth.ts`** — confirmado por: el test unitario pasa
+  (`npm test -- auth.test.ts`), el token decodificado en jwt.io muestra el payload correcto
+- **Hashing de contraseñas** — confirmado por: `bcrypt.compare()` devuelve true en el test
+
+---
+
+## Qué NO funcionó (y por qué)
+
+- **Librería Next-Auth** — falló porque: entra en conflicto con nuestro adaptador Prisma
+  personalizado, lanzó "Cannot use adapter with credentials provider in this configuration"
+  en cada request. No vale la pena depurarlo — demasiado opinado para nuestra configuración.
+- **Almacenar el JWT en localStorage** — falló porque: los renders SSR ocurren antes de que
+  localStorage esté disponible, causó un error de hydration mismatch de React en cada carga
+  de página. Este enfoque es fundamentalmente incompatible con SSR en Next.js.
+
+---
+
+## Qué NO se ha intentado todavía
+
+- Guardar el JWT como cookie httpOnly en la respuesta de la ruta de login (la solución más probable)
+- Usar `cookies()` de `next/headers` para leer el token en server components
+- Escribir middleware.ts para proteger rutas verificando la existencia de la cookie
+
+---
+
+## Estado actual de los archivos
+
+| Archivo                          | Estado          | Notas                                              |
+| -------------------------------- | --------------- | -------------------------------------------------- |
+| `app/api/auth/register/route.ts` | PASA: Completo    | Funciona, probado                                   |
+| `app/api/auth/login/route.ts`    |  En progreso    | El token se genera pero aún no se setea la cookie   |
+| `lib/auth.ts`                    | PASA: Completo    | Helpers JWT, todo probado                           |
+| `middleware.ts`                  |  Sin empezar    | Protección de rutas, necesita primero leer la cookie |
+| `app/login/page.tsx`             |  Sin empezar    | UI sin empezar                                      |
+
+---
+
+## Decisiones tomadas
+
+- **Cookie httpOnly sobre localStorage** — razón: evita robo de token por XSS, funciona con SSR
+- **Auth propia sobre Next-Auth** — razón: Next-Auth entra en conflicto con nuestra
+  configuración de Prisma, no vale la pena pelearlo
+
+---
+
+## Bloqueantes y preguntas abiertas
+
+- ¿`cookies().set()` funciona dentro de un Route Handler o solo en Server Actions? Hay que verificar.
+
+---
+
+## Siguiente paso exacto
+
+En `app/api/auth/login/route.ts`, después de generar el JWT, setéalo como cookie httpOnly
+usando `cookies().set('token', jwt, { httpOnly: true, secure: true, sameSite: 'strict' })`.
+Luego prueba con Postman — la respuesta debe incluir una cabecera `Set-Cookie`.
+```
+
+---
+
+## Notas
+
+- Cada sesión tiene su propio archivo — nunca agregues contenido al archivo de una sesión anterior
+- La sección "Qué NO funcionó" es la más crítica — sin ella, las sesiones futuras reintentarán a ciegas los enfoques fallidos
+- Si el usuario pide guardar a mitad de sesión (no solo al final), guarda lo que se sabe hasta el momento y marca con claridad los ítems en progreso
+- El archivo está pensado para que Theus lo lea al inicio de la siguiente sesión vía `/reanudar-sesion`
+- Usa el almacén global canónico de sesiones: `~/.theus/arsenal/session-data/`
+- Prefiere la forma de nombre con short-id (`YYYY-MM-DD-<short-id>-session.tmp`) para cualquier archivo de sesión nuevo

package/vendor/theus-arsenal/commands/harness-build.md

@@ -0,0 +1,111 @@
+---
+description: Ejecuta un bucle de construcción generador/evaluador para tareas de implementación, con iteraciones acotadas y puntuación.
+argument-hint: <brief> [--max-iterations N] [--pass-threshold N] [--skip-planner] [--eval-mode MODE]
+---
+
+Analiza lo siguiente desde $ARGUMENTS:
+1. `brief` — la descripción en una línea de lo que hay que construir
+2. `--max-iterations N` — (opcional, por defecto 15) máximo de ciclos generador-evaluador
+3. `--pass-threshold N` — (opcional, por defecto 7.0) puntuación ponderada para aprobar
+4. `--skip-planner` — (opcional) omite el planificador; asume que spec.md ya existe
+5. `--eval-mode MODE` — (opcional, por defecto "playwright") uno de: playwright, screenshot, code-only
+
+## Harness de construcción generador/evaluador
+
+Este comando orquesta un bucle de construcción de tres agentes, inspirado en diseños recientes de harness de agentes autónomos.
+
+### Fase 0: Preparación
+1. Crea el directorio `harness/` en la raíz del proyecto
+2. Crea los subdirectorios: `harness/feedback/`, `harness/screenshots/`
+3. Inicializa git si aún no está inicializado
+4. Registra la hora de inicio y la configuración
+
+### Fase 1: Planificación (agente planificador)
+Salvo que `--skip-planner` esté activo:
+1. Lanza el agente `planificador-harness` como subagente (herramienta Task) con el brief del usuario
+2. Espera a que produzca `harness/spec.md` y `harness/eval-rubric.md`
+3. Muestra al usuario el resumen de la especificación
+4. Continúa con la Fase 2
+
+### Fase 2: Bucle generador-evaluador
+```
+iteracion = 1
+mientras iteracion <= max_iterations:
+
+    # GENERAR
+    Lanza el agente generador-harness como subagente (herramienta Task):
+    - Lee spec.md
+    - Si iteracion > 1: lee feedback/feedback-{iteracion-1}.md
+    - Construye/mejora la aplicación
+    - Asegura que el servidor de desarrollo esté corriendo
+    - Hace commit de los cambios
+
+    # Espera a que el generador termine
+
+    # EVALUAR
+    Lanza el agente evaluador-harness como subagente (herramienta Task):
+    - Lee eval-rubric.md y spec.md
+    - Prueba la aplicación en vivo (modo: playwright/screenshot/code-only)
+    - Puntúa contra la rúbrica
+    - Escribe el feedback en feedback/feedback-{iteracion}.md
+
+    # Espera a que el evaluador termine
+
+    # COMPROBAR LA PUNTUACIÓN
+    Lee feedback/feedback-{iteracion}.md
+    Extrae la puntuación total ponderada
+
+    si puntuacion >= pass_threshold:
+        Registra "APROBADO en la iteración {iteracion} con puntuación {puntuacion}"
+        Corta el bucle
+
+    si iteracion >= 3 y la puntuación no ha mejorado en las últimas 2 iteraciones:
+        Registra "MESETA detectada — parada temprana"
+        Corta el bucle
+
+    iteracion += 1
+```
+
+### Fase 3: Resumen
+1. Lee todos los archivos de feedback
+2. Muestra las puntuaciones finales y el historial de iteraciones
+3. Muestra la progresión: `iteración 1: 4.2 → iteración 2: 5.8 → ... → iteración N: 7.5`
+4. Lista los problemas restantes de la evaluación final
+5. Reporta el tiempo total y el costo estimado
+
+### Salida
+
+```markdown
+## Informe del harness de construcción
+
+**Brief:** [prompt original]
+**Resultado:** APROBADO/FALLIDO
+**Iteraciones:** N / máximo
+**Puntuación final:** X.X / 10
+
+### Progresión de puntuaciones
+| Iter | Diseño | Originalidad | Factura | Funcionalidad | Total |
+|------|--------|--------------|---------|---------------|-------|
+| 1 | ... | ... | ... | ... | X.X |
+| 2 | ... | ... | ... | ... | X.X |
+| N | ... | ... | ... | ... | X.X |
+
+### Problemas restantes
+- [Cualquier problema de la evaluación final]
+
+### Archivos creados
+- harness/spec.md
+- harness/eval-rubric.md
+- harness/feedback/feedback-001.md hasta feedback-NNN.md
+- harness/generator-state.md
+- harness/build-report.md
+```
+
+Escribe el informe completo en `harness/build-report.md`.
+
+## Relacionados
+
+- Agente: `agents/planificador-harness.md`
+- Agente: `agents/generador-harness.md`
+- Agente: `agents/evaluador-harness.md`
+- Skill: `skills/harness-generador-evaluador/`