theus-cli-linux-x64 1.2.2 → 1.4.0

package/vendor/theus-arsenal/commands/actualizar-docs.md

@@ -1,88 +0,0 @@
----
-description: Sincroniza la documentación desde los archivos fuente de verdad, como scripts, esquemas, rutas y exports.
----
-
-# Actualizar documentación
-
-Sincroniza la documentación con el código, generándola desde los archivos que son fuente de verdad.
-
-## Paso 1: Identificar las fuentes de verdad
-
-| Fuente | Genera |
-|--------|--------|
-| Scripts de `package.json` | Referencia de comandos disponibles |
-| `.env.example` | Documentación de variables de entorno |
-| `openapi.yaml` / archivos de rutas | Referencia de endpoints de la API |
-| Exports del código fuente | Documentación de la API pública |
-| `Dockerfile` / `docker-compose.yml` | Documentación de infraestructura |
-
-## Paso 2: Generar la referencia de scripts
-
-1. Lee `package.json` (o `Makefile`, `Cargo.toml`, `pyproject.toml`)
-2. Extrae todos los scripts/comandos con sus descripciones
-3. Genera una tabla de referencia:
-
-```markdown
-| Comando | Descripción |
-|---------|-------------|
-| `npm run dev` | Inicia el servidor de desarrollo con recarga en caliente |
-| `npm run build` | Build de producción con verificación de tipos |
-| `npm test` | Ejecuta la suite de tests con cobertura |
-```
-
-## Paso 3: Generar la documentación de entorno
-
-1. Lee `.env.example` (o `.env.template`, `.env.sample`)
-2. Extrae todas las variables con su propósito
-3. Clasifícalas como requeridas u opcionales
-4. Documenta el formato esperado y los valores válidos
-
-```markdown
-| Variable | Requerida | Descripción | Ejemplo |
-|----------|-----------|-------------|---------|
-| `DATABASE_URL` | Sí | Cadena de conexión de PostgreSQL | `postgres://user:pass@host:5432/db` |
-| `LOG_LEVEL` | No | Verbosidad del logging (por defecto: info) | `debug`, `info`, `warn`, `error` |
-```
-
-## Paso 4: Actualizar la guía de contribución
-
-Genera o actualiza `docs/CONTRIBUTING.md` con:
-- Configuración del entorno de desarrollo (prerrequisitos, pasos de instalación)
-- Scripts disponibles y su propósito
-- Procedimientos de testing (cómo ejecutarlos, cómo escribir tests nuevos)
-- Aplicación del estilo de código (linter, formateador, hooks de pre-commit)
-- Lista de verificación para enviar un PR
-
-## Paso 5: Actualizar el runbook
-
-Genera o actualiza `docs/RUNBOOK.md` con:
-- Procedimientos de despliegue (paso a paso)
-- Endpoints de health check y monitoreo
-- Problemas comunes y sus soluciones
-- Procedimientos de rollback
-- Rutas de alertas y escalamiento
-
-## Paso 6: Verificación de obsolescencia
-
-1. Encuentra archivos de documentación sin modificar en más de 90 días
-2. Contrástalos con los cambios recientes del código fuente
-3. Marca los documentos potencialmente desactualizados para revisión manual
-
-## Paso 7: Mostrar el resumen
-
-```
-Actualización de documentación
-──────────────────────────────
-Actualizado:  docs/CONTRIBUTING.md (tabla de scripts)
-Actualizado:  docs/ENV.md (3 variables nuevas)
-Marcado:      docs/DEPLOY.md (142 días sin actualizar)
-Omitido:      docs/API.md (sin cambios detectados)
-──────────────────────────────
-```
-
-## Reglas
-
-- **Una sola fuente de verdad**: genera siempre desde el código; nunca edites a mano las secciones generadas
-- **Preserva las secciones manuales**: actualiza solo las secciones generadas; deja intacta la prosa escrita a mano
-- **Marca el contenido generado**: usa marcadores `<!-- AUTO-GENERATED -->` alrededor de las secciones generadas
-- **No crees documentación sin que se pida**: crea archivos de documentación nuevos solo si el comando lo solicita explícitamente

package/vendor/theus-arsenal/commands/actualizar-mapas-codigo.md

@@ -1,78 +0,0 @@
----
-description: Escanea la estructura del proyecto y genera mapas de código de arquitectura optimizados en tokens.
----
-
-# Actualizar mapas de código
-
-Analiza la estructura del código y genera documentación de arquitectura optimizada en tokens.
-
-## Paso 1: Escanear la estructura del proyecto
-
-1. Identificar el tipo de proyecto (monorepo, app única, librería, microservicio)
-2. Encontrar todos los directorios de código fuente (src/, lib/, app/, packages/)
-3. Mapear los puntos de entrada (main.ts, index.ts, app.py, main.go, etc.)
-
-Si el motor de inteligencia de código Ñaupa está disponible como MCP, aprovecha sus herramientas (arquitectura, búsqueda en el grafo) para acelerar el escaneo en lugar de recorrer archivos a mano.
-
-## Paso 2: Generar los mapas de código
-
-Crea o actualiza los mapas en `docs/CODEMAPS/` (o `.reports/codemaps/`):
-
-| Archivo | Contenido |
-|---------|-----------|
-| `architecture.md` | Diagrama de alto nivel del sistema, fronteras de servicios, flujo de datos |
-| `backend.md` | Rutas de API, cadena de middleware, mapeo servicio → repositorio |
-| `frontend.md` | Árbol de páginas, jerarquía de componentes, flujo de gestión de estado |
-| `data.md` | Tablas de base de datos, relaciones, historial de migraciones |
-| `dependencies.md` | Servicios externos, integraciones de terceros, librerías compartidas |
-
-### Formato de los mapas
-
-Cada mapa debe ser austero en tokens — optimizado para consumo como contexto del modelo:
-
-```markdown
-# Arquitectura del backend
-
-## Rutas
-POST /api/users → UserController.create → UserService.create → UserRepo.insert
-GET  /api/users/:id → UserController.get → UserService.findById → UserRepo.findById
-
-## Archivos clave
-src/services/user.ts (lógica de negocio, 120 líneas)
-src/repos/user.ts (acceso a datos, 80 líneas)
-
-## Dependencias
-- PostgreSQL (almacén de datos principal)
-- Redis (caché de sesiones, rate limiting)
-- Stripe (procesamiento de pagos)
-```
-
-## Paso 3: Detección de diferencias
-
-1. Si existen mapas previos, calcula el porcentaje de diferencia
-2. Si los cambios superan el 30%, muestra el diff y pide aprobación del usuario antes de sobrescribir
-3. Si los cambios son <= 30%, actualiza en el lugar
-
-## Paso 4: Añadir metadatos
-
-Añade una cabecera de frescura a cada mapa:
-
-```markdown
-<!-- Generado: 2026-02-11 | Archivos escaneados: 142 | Estimación de tokens: ~800 -->
-```
-
-## Paso 5: Guardar el informe de análisis
-
-Escribe un resumen en `.reports/codemap-diff.txt`:
-- Archivos añadidos/eliminados/modificados desde el último escaneo
-- Nuevas dependencias detectadas
-- Cambios de arquitectura (nuevas rutas, nuevos servicios, etc.)
-- Avisos de obsolescencia para docs sin actualizar en 90+ días
-
-## Consejos
-
-- Céntrate en la **estructura de alto nivel**, no en detalles de implementación
-- Prefiere **rutas de archivo y firmas de funciones** sobre bloques de código completos
-- Mantén cada mapa por debajo de **1000 tokens** para una carga de contexto eficiente
-- Usa diagramas ASCII para el flujo de datos en lugar de descripciones extensas
-- Ejecútalo tras incorporar funcionalidades grandes o sesiones de refactorización

package/vendor/theus-arsenal/commands/aprender-evaluar.md

@@ -1,109 +0,0 @@
----
-description: Extrae patrones reutilizables de la sesión, autoevalúa su calidad antes de guardar y decide la ubicación correcta (global o de proyecto).
----
-
-# /aprender-evaluar - Extraer, evaluar y luego guardar
-
-Extiende `/aprender` con una puerta de calidad, una decisión de ubicación de guardado y conciencia de dónde ya vive el conocimiento, antes de escribir cualquier archivo de skill.
-
-## Qué extraer
-
-Busca:
-
-1. **Patrones de resolución de errores** — causa raíz + arreglo + reutilizabilidad
-2. **Técnicas de depuración** — pasos no obvios, combinaciones de herramientas
-3. **Soluciones alternativas (workarounds)** — peculiaridades de librerías, limitaciones de APIs, arreglos específicos de una versión
-4. **Patrones específicos del proyecto** — convenciones, decisiones de arquitectura, patrones de integración
-
-## Proceso
-
-1. Revisa la sesión en busca de patrones extraíbles
-2. Identifica el hallazgo más valioso/reutilizable
-
-3. **Decide la ubicación de guardado:**
-   - Pregúntate: "¿Este patrón sería útil en un proyecto distinto?"
-   - **Global** (`~/.theus/arsenal/skills/learned/`): patrones genéricos aplicables en 2+ proyectos (compatibilidad de bash, comportamiento de APIs de modelos, técnicas de depuración, etc.)
-   - **Proyecto** (`.theus/skills/learned/` en el proyecto actual): conocimiento específico del proyecto (peculiaridades de un archivo de configuración concreto, decisiones de arquitectura propias del proyecto, etc.)
-   - Ante la duda, elige Global (mover de Global → Proyecto es más fácil que lo inverso)
-
-4. Redacta el borrador del archivo de skill con este formato:
-
-```markdown
-# [Nombre descriptivo del patrón]
-
-**Extraído:** [Fecha]
-**Contexto:** [Descripción breve de cuándo aplica]
-
-## Problema
-[Qué problema resuelve — sé específico]
-
-## Solución
-[El patrón / la técnica / el workaround — con ejemplos de código]
-
-## Cuándo usarlo
-[Condiciones de activación]
-```
-
-5. **Puerta de calidad — checklist + veredicto holístico**
-
-   ### 5a. Checklist obligatorio (verifica leyendo los archivos de verdad)
-
-   Ejecuta **todos** estos pasos antes de evaluar el borrador:
-
-   - [ ] Busca por palabras clave (grep) en `~/.theus/arsenal/skills/` y en las skills del proyecto (`.theus/skills/`) para detectar solapamiento de contenido
-   - [ ] Revisa la memoria persistente (el `AGENTS.md` del proyecto y las notas de memoria globales del agente) por solapamiento
-   - [ ] Considera si bastaría con anexar el patrón a una skill existente
-   - [ ] Confirma que es un patrón reutilizable, no un arreglo puntual
-
-   ### 5b. Veredicto holístico
-
-   Sintetiza los resultados del checklist y la calidad del borrador, y elige **uno** de los siguientes (el paso 6 define la acción de cada veredicto):
-
-   | Veredicto | Significado |
-   |-----------|-------------|
-   | **Guardar** | Único, específico, bien acotado |
-   | **Mejorar y guardar** | Valioso pero necesita refinamiento |
-   | **Absorber en [X]** | Debería anexarse a una skill existente |
-   | **Descartar** | Trivial, redundante o demasiado abstracto |
-
-**Dimensiones orientativas** (informan el veredicto, no se puntúan):
-
-- **Especificidad y accionabilidad**: contiene ejemplos de código o comandos usables de inmediato
-- **Ajuste de alcance**: nombre, condiciones de activación y contenido están alineados y centrados en un solo patrón
-- **Unicidad**: aporta valor no cubierto por las skills existentes (informado por el checklist)
-- **Reutilizabilidad**: existen escenarios de activación realistas en sesiones futuras
-
-6. **Flujo de confirmación según el veredicto**
-
-- **Mejorar y guardar**: presenta las mejoras requeridas + el borrador revisado + checklist/veredicto actualizados tras una re-evaluación; si el veredicto revisado es **Guardar**, guarda tras la confirmación del usuario; en caso contrario, sigue el nuevo veredicto
-- **Guardar**: presenta la ruta de guardado + los resultados del checklist + una línea de justificación del veredicto + el borrador completo → guarda tras la confirmación del usuario
-- **Absorber en [X]**: presenta la ruta destino + los añadidos (en formato diff) + resultados del checklist + justificación del veredicto → anexa tras la confirmación del usuario
-- **Descartar**: muestra los resultados del checklist + el razonamiento, nada más (no requiere confirmación)
-
-7. Guarda / absorbe en la ubicación decidida
-
-## Formato de salida del paso 5
-
-```
-### Checklist
-- [x] grep de skills/: sin solapamiento (o: solapamiento encontrado → detalles)
-- [x] Memoria persistente: sin solapamiento (o: solapamiento encontrado → detalles)
-- [x] Anexar a skill existente: archivo nuevo apropiado (o: debería anexarse a [X])
-- [x] Reutilizabilidad: confirmada (o: caso puntual → Descartar)
-
-### Veredicto: Guardar / Mejorar y guardar / Absorber en [X] / Descartar
-
-**Justificación:** (1-2 frases explicando el veredicto)
-```
-
-## Racionalidad del diseño
-
-Esta versión reemplaza la rúbrica anterior de puntuación numérica en 5 dimensiones (Especificidad, Accionabilidad, Ajuste de alcance, No redundancia y Cobertura puntuadas de 1 a 5) por un sistema de checklist + veredicto holístico. Los modelos frontier actuales tienen un juicio contextual sólido — forzar señales cualitativas ricas a puntuaciones numéricas pierde matices y puede producir totales engañosos. El enfoque holístico permite que el modelo pondere todos los factores con naturalidad, produciendo decisiones de guardar/descartar más acertadas, mientras el checklist explícito garantiza que ningún control crítico se omita.
-
-## Notas
-
-- No extraigas arreglos triviales (errores de tipeo, errores simples de sintaxis)
-- No extraigas incidentes puntuales (caídas específicas de una API, etc.)
-- Céntrate en patrones que ahorren tiempo en sesiones futuras
-- Mantén las skills enfocadas — un patrón por skill
-- Cuando el veredicto sea Absorber, anexa a la skill existente en lugar de crear un archivo nuevo

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

@@ -1,74 +0,0 @@
----
-description: Extrae patrones reutilizables de la sesión actual y guárdalos como skills candidatas o guías.
----
-
-# /aprender - Extraer patrones reutilizables
-
-Analiza la sesión actual y extrae los patrones que valga la pena guardar como skills.
-
-## Cuándo ejecutarlo
-
-Ejecuta `/aprender` en cualquier momento de una sesión cuando hayas resuelto un problema no trivial.
-
-## Qué extraer
-
-Busca:
-
-1. **Patrones de resolución de errores**
-   - ¿Qué error ocurrió?
-   - ¿Cuál fue la causa raíz?
-   - ¿Qué lo arregló?
-   - ¿Es reutilizable para errores similares?
-
-2. **Técnicas de depuración**
-   - Pasos de depuración no obvios
-   - Combinaciones de herramientas que funcionaron
-   - Patrones de diagnóstico
-
-3. **Soluciones alternativas (workarounds)**
-   - Peculiaridades de librerías
-   - Limitaciones de APIs
-   - Arreglos específicos de una versión
-
-4. **Patrones específicos del proyecto**
-   - Convenciones del código base descubiertas
-   - Decisiones de arquitectura tomadas
-   - Patrones de integración
-
-## Formato de salida
-
-Crea un archivo de skill en `~/.theus/arsenal/skills/learned/[nombre-del-patron].md`:
-
-```markdown
-# [Nombre descriptivo del patrón]
-
-**Extraído:** [Fecha]
-**Contexto:** [Descripción breve de cuándo aplica]
-
-## Problema
-[Qué problema resuelve — sé específico]
-
-## Solución
-[El patrón / la técnica / el workaround]
-
-## Ejemplo
-[Ejemplo de código si aplica]
-
-## Cuándo usarlo
-[Condiciones de activación — qué debería activar esta skill]
-```
-
-## Proceso
-
-1. Revisa la sesión en busca de patrones extraíbles
-2. Identifica el hallazgo más valioso/reutilizable
-3. Redacta el borrador del archivo de skill
-4. Pide confirmación al usuario antes de guardar
-5. Guarda en `~/.theus/arsenal/skills/learned/`
-
-## Notas
-
-- No extraigas arreglos triviales (errores de tipeo, errores simples de sintaxis)
-- No extraigas incidentes puntuales (caídas específicas de una API, etc.)
-- Céntrate en patrones que ahorren tiempo en sesiones futuras
-- Mantén las skills enfocadas — un patrón por skill

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

@@ -1,66 +0,0 @@
----
-description: Detecta el sistema de build del proyecto y corrige incrementalmente errores de build/tipos con cambios mínimos y seguros.
----
-
-# Arreglar el build
-
-Corrige incrementalmente errores de build y de tipos con cambios mínimos y seguros.
-
-## Paso 1: Detectar el sistema de build
-
-Identifica la herramienta de build del proyecto y ejecuta el build:
-
-| Indicador | Comando de build |
-|-----------|------------------|
-| `package.json` con script `build` | `npm run build` o `pnpm build` |
-| `tsconfig.json` (solo TypeScript) | `npx tsc --noEmit` |
-| `Cargo.toml` | `cargo build 2>&1` |
-| `pom.xml` | `mvn compile` |
-| `build.gradle` | `./gradlew compileJava` |
-| `go.mod` | `go build ./...` |
-| `pyproject.toml` | `python -m compileall -q .` o `mypy .` |
-
-## Paso 2: Analizar y agrupar los errores
-
-1. Ejecuta el comando de build y captura stderr
-2. Agrupa los errores por ruta de archivo
-3. Ordénalos por orden de dependencia (corrige imports/tipos antes que errores de lógica)
-4. Cuenta el total de errores para hacer seguimiento del progreso
-
-## Paso 3: Bucle de corrección (un error a la vez)
-
-Para cada error:
-
-1. **Lee el archivo** — Usa la herramienta Read para ver el contexto del error (10 líneas alrededor)
-2. **Diagnostica** — Identifica la causa raíz (import faltante, tipo incorrecto, error de sintaxis)
-3. **Corrige mínimamente** — Usa la herramienta Edit para el cambio más pequeño que resuelva el error
-4. **Vuelve a ejecutar el build** — Verifica que el error desapareció y que no se introdujeron errores nuevos
-5. **Pasa al siguiente** — Continúa con los errores restantes
-
-## Paso 4: Salvaguardas
-
-Detente y pregunta al usuario si:
-- Una corrección introduce **más errores de los que resuelve**
-- El **mismo error persiste tras 3 intentos** (probablemente hay un problema más profundo)
-- La corrección requiere **cambios de arquitectura** (no es solo un arreglo de build)
-- Los errores de build provienen de **dependencias faltantes** (hace falta `npm install`, `cargo add`, etc.)
-
-## Paso 5: Resumen
-
-Muestra los resultados:
-- Errores corregidos (con rutas de archivo)
-- Errores restantes (si los hay)
-- Errores nuevos introducidos (debería ser cero)
-- Próximos pasos sugeridos para los problemas sin resolver
-
-## Estrategias de recuperación
-
-| Situación | Acción |
-|-----------|--------|
-| Módulo/import faltante | Verifica si el paquete está instalado; sugiere el comando de instalación |
-| Discrepancia de tipos | Lee ambas definiciones de tipo; corrige el tipo más estrecho |
-| Dependencia circular | Identifica el ciclo con el grafo de imports; sugiere extracción |
-| Conflicto de versiones | Revisa `package.json` / `Cargo.toml` en busca de restricciones de versión |
-| Herramienta de build mal configurada | Lee el archivo de configuración; compáralo con los valores por defecto que funcionan |
-
-Corrige un error a la vez por seguridad. Prefiere diffs mínimos antes que refactorizar.

package/vendor/theus-arsenal/commands/bucle-multiperspectiva.md

@@ -1,153 +0,0 @@
----
-description: Bucle de convergencia con doble revisión adversarial — dos revisores independientes deben aprobar antes de publicar el código.
-argument-hint: [archivo-o-glob | descripción del alcance]
----
-
-# Bucle multiperspectiva
-
-Bucle de convergencia con doble revisión adversarial, basado en la skill `revision-multiperspectiva`. Dos revisores independientes — sin contexto compartido y, cuando el enrutado multimodelo de Theus lo permita, con modelos distintos — deben devolver APTO antes de publicar el código.
-
-## Propósito
-
-Ejecutar dos revisores independientes contra la salida de la tarea actual. Ambos deben devolver APTO antes de hacer push. Si cualquiera devuelve NO APTO, se corrigen todos los hallazgos, se hace commit y se relanzan revisores frescos — hasta 3 rondas.
-
-## Uso
-
-```
-/bucle-multiperspectiva [archivo-o-glob | descripción]
-```
-
-## Flujo de trabajo
-
-### Paso 1: Identificar qué revisar
-
-Determina el alcance desde `$ARGUMENTS` o, en su defecto, usa los cambios sin commitear:
-
-```bash
-git diff --name-only HEAD
-```
-
-Lee todos los archivos modificados para construir el contexto completo de revisión. Si `$ARGUMENTS` especifica una ruta, archivo o descripción, usa eso como alcance.
-
-### Paso 2: Construir la rúbrica
-
-Construye una rúbrica adecuada a los tipos de archivo bajo revisión. Cada criterio debe tener una condición PASA/FALLA objetiva. Incluye como mínimo:
-
-| Criterio | Condición para pasar |
-|----------|----------------------|
-| Corrección | La lógica es sólida, sin bugs, maneja casos límite |
-| Seguridad | Sin secretos, inyección, XSS ni problemas del OWASP Top 10 |
-| Manejo de errores | Errores manejados explícitamente, sin tragarse fallos en silencio |
-| Completitud | Todos los requisitos cubiertos, sin casos faltantes |
-| Consistencia interna | Sin contradicciones entre archivos o secciones |
-| Sin regresiones | Los cambios no rompen el comportamiento existente |
-
-Añade criterios específicos del dominio según los tipos de archivo (p. ej., seguridad de tipos para TS, seguridad de memoria para Rust, seguridad de migraciones para SQL).
-
-### Paso 3: Doble revisión independiente
-
-Lanza dos revisores **en paralelo** con la herramienta de subagentes (ambos en un solo mensaje para ejecución concurrente). Los dos deben terminar antes de pasar a la compuerta de veredicto.
-
-Cada revisor evalúa cada criterio de la rúbrica como PASA o FALLA, y devuelve un JSON estructurado:
-
-```json
-{
-  "verdict": "PASS" | "FAIL",
-  "checks": [
-    {"criterion": "...", "result": "PASS|FAIL", "detail": "..."}
-  ],
-  "critical_issues": ["..."],
-  "suggestions": ["..."]
-}
-```
-
-La compuerta de veredicto (Paso 4) mapea estos resultados a APTO/NO APTO: ambos PASS → APTO, cualquier FAIL → NO APTO.
-
-#### Revisor A
-
-Lanza un subagente `revisor-codigo` con la rúbrica completa + todos los archivos bajo revisión. El prompt debe incluir:
-- La rúbrica completa
-- El contenido íntegro de los archivos bajo revisión
-- "Eres un revisor de calidad independiente. NO has visto ninguna otra revisión. Tu trabajo es encontrar problemas, no aprobar."
-- Devolver el veredicto JSON estructurado de arriba
-
-#### Revisor B
-
-Lanza un segundo subagente `revisor-codigo` con la misma rúbrica e instrucciones, pero **sin ningún contexto compartido** con el Revisor A (no le pases hallazgos, notas ni conversación previa).
-
-Theus es multimodelo nativo: cuando el enrutado del CLI permita asignar un modelo distinto al segundo revisor, hazlo — la diversidad de modelos aporta sesgos, datos de entrenamiento y puntos ciegos diferentes. Si ambos revisores acaban ejecutándose con el mismo modelo, registra una advertencia: no se logró diversidad de modelos, pero el aislamiento de contexto sigue vigente y ya rompe el modo de fallo de auto-revisión.
-
-En todos los casos, el Revisor B debe devolver el mismo veredicto JSON estructurado que el Revisor A.
-
-### Paso 4: Compuerta de veredicto
-
-- **Ambos PASS** → **APTO** — continúa al Paso 6 (push)
-- **Cualquier FAIL** → **NO APTO** — fusiona todos los hallazgos críticos de ambos revisores, deduplica y continúa al Paso 5
-
-### Paso 5: Ciclo de corrección (ruta NO APTO)
-
-1. Muestra todos los hallazgos críticos de ambos revisores
-2. Corrige cada hallazgo señalado — cambia solo lo señalado, sin refactors de paso
-3. Haz commit de todas las correcciones en un solo commit:
-   ```
-   fix: atender hallazgos del bucle multiperspectiva (ronda N)
-   ```
-4. Vuelve a ejecutar el Paso 3 con **revisores frescos** (sin memoria de rondas anteriores)
-5. Repite hasta que ambos devuelvan PASS
-
-**Máximo 3 iteraciones.** Si sigue NO APTO tras 3 rondas, detente y presenta los problemas restantes:
-
-```
-ESCALADA DEL BUCLE MULTIPERSPECTIVA (se excedieron 3 iteraciones)
-
-Problemas restantes tras 3 rondas:
-- [lista de todos los hallazgos críticos sin resolver de ambos revisores]
-
-Se requiere revisión manual antes de continuar.
-```
-
-NO hagas push.
-
-### Paso 6: Push (ruta APTO)
-
-Cuando ambos revisores devuelvan PASS:
-
-```bash
-git push -u origin HEAD
-```
-
-### Paso 7: Informe final
-
-Imprime el informe de salida (ver sección Salida).
-
-## Salida
-
-```
-VEREDICTO: [APTO / NO APTO (escalado)]
-
-Revisor A ([modelo usado]):  [PASS/FAIL]
-Revisor B ([modelo usado]):  [PASS/FAIL]
-
-Acuerdo:
-  Señalado por ambos:   [problemas detectados por los dos]
-  Solo Revisor A:       [problemas que solo detectó A]
-  Solo Revisor B:       [problemas que solo detectó B]
-
-Iteraciones: [N]/3
-Resultado:   [PUBLICADO / ESCALADO AL USUARIO]
-```
-
-## Notas
-
-- El Revisor A siempre se ejecuta — garantiza al menos un revisor fuerte independientemente de la configuración.
-- La diversidad de modelos es la meta para el Revisor B: modelos distintos tienen datos de entrenamiento, sesgos y puntos ciegos distintos. Con Theus multimodelo suele ser alcanzable; si no, el aislamiento de contexto sigue aportando valor.
-- Los revisores solo leen: no deben mutar el repositorio durante la revisión.
-- Revisores frescos en cada ronda evitan el sesgo de anclaje sobre hallazgos previos.
-- La rúbrica es el insumo más importante. Endurécela si los revisores aprueban sin criterio o señalan cuestiones subjetivas de estilo.
-- Los commits ocurren en las rondas NO APTO para preservar las correcciones aunque el bucle se interrumpa.
-- El push solo ocurre tras APTO — nunca a mitad del bucle.
-
-## Relacionados
-
-- Skill: `skills/revision-multiperspectiva/`
-- Agente: `agents/revisor-codigo.md`