theus-cli-linux-x64 1.2.2 → 1.3.0

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

@@ -1,21 +0,0 @@
----
-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

@@ -1,21 +0,0 @@
----
-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

@@ -1,176 +0,0 @@
----
-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

@@ -1,49 +0,0 @@
----
-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

@@ -1,278 +0,0 @@
----
-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

@@ -1,111 +0,0 @@
----
-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/`