npm - theus-cli-linux-arm64 - Versions diffs - 1.2.2 → 1.3.0 - Mend

theus-cli-linux-arm64 1.2.2 → 1.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (758) hide show

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

@@ -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 DELETED Viewed

@@ -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 DELETED Viewed

@@ -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 DELETED Viewed

@@ -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 DELETED Viewed

@@ -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 DELETED Viewed

@@ -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/`