theus-cli-linux-arm64 1.2.2 → 1.4.0

package/vendor/theus-arsenal/skills/revision-multiperspectiva/SKILL.md

@@ -1,302 +0,0 @@
----
-name: revision-multiperspectiva
-description: Verificación adversarial multi-agente con bucle de convergencia — dos revisores independientes
-  deben aprobar antes de publicar. Úsala cuando la salida se despliegue o publique sin revisión humana,
-  cuando la precisión factual importe o cuando haya riesgo elevado de alucinaciones.
----
-
-# Revisión multiperspectiva
-
-Marco de verificación adversarial multi-agente. Genera la entrega, revísala dos veces con revisores independientes y, si falla, corrígela hasta que ambos aprueben.
-
-La idea central: un único agente revisando su propia salida comparte los mismos sesgos, lagunas de conocimiento y errores sistemáticos que produjeron esa salida. Dos revisores independientes sin contexto compartido rompen ese modo de fallo.
-
-## Cuándo activarla
-
-Invoca esta skill cuando:
-- La salida se va a publicar, desplegar o consumir por usuarios finales.
-- Deben cumplirse restricciones de cumplimiento normativo, regulatorias o de marca.
-- El código llega a producción sin revisión humana.
-- La precisión del contenido importa (documentación técnica, material educativo, textos de cara al cliente).
-- Se genera en lote a gran escala, donde el muestreo manual no detecta patrones sistémicos.
-- El riesgo de alucinación es elevado (afirmaciones, estadísticas, referencias a APIs, lenguaje legal).
-
-NO la uses para borradores internos, investigación exploratoria o tareas con verificación determinista (para esas usa pipelines de build/test/lint).
-
-## Arquitectura
-
-```
-┌─────────────┐
-│  GENERADOR   │  Fase 1: Generar
-│  (Agente A)  │  Produce la entrega
-└──────┬───────┘
-       │ salida
-       ▼
-┌──────────────────────────────┐
-│   DOBLE REVISIÓN INDEPENDIENTE │  Fase 2: Verificar dos veces
-│                                │
-│  ┌───────────┐ ┌───────────┐  │  Dos agentes, misma rúbrica,
-│  │ Revisor B  │ │ Revisor C  │  │  sin contexto compartido
-│  └─────┬─────┘ └─────┬─────┘  │
-│        │              │        │
-└────────┼──────────────┼────────┘
-         │              │
-         ▼              ▼
-┌──────────────────────────────┐
-│    COMPUERTA DE VEREDICTO     │  Fase 3: Apto o no apto
-│                                │
-│  B aprueba Y C aprueba → APTO  │  Ambos deben aprobar.
-│  En otro caso → NO APTO        │  Sin excepciones.
-└──────┬──────────────┬─────────┘
-       │              │
-     APTO          NO APTO
-       │              │
-       ▼              ▼
-  [ PUBLICAR ] ┌──────────────┐
-               │ CICLO DE FIX  │  Fase 4: Corregir hasta aprobar
-               │               │
-               │ iteración++   │  Reúne todos los hallazgos.
-               │ si i > MAX:   │  Corrige todos los problemas.
-               │   escalar     │  Vuelve a pasar ambos revisores.
-               │ si no:        │  Itera hasta converger.
-               │   ir a Fase 2 │
-               └───────────────┘
-```
-
-## Detalle de las fases
-
-### Fase 1: Generar
-
-Ejecuta la tarea principal. Sin cambios en tu flujo de generación normal. Esta skill es una capa de verificación posterior a la generación, no una estrategia de generación.
-
-```python
-# El generador corre con normalidad
-salida = generar(especificacion)
-```
-
-### Fase 2: Doble revisión independiente
-
-Lanza dos agentes revisores en paralelo. Invariantes críticas:
-
-1. **Aislamiento de contexto** — ningún revisor ve la evaluación del otro.
-2. **Rúbrica idéntica** — ambos reciben los mismos criterios de evaluación.
-3. **Mismas entradas** — ambos reciben la especificación original Y la salida generada.
-4. **Salida estructurada** — cada uno devuelve un veredicto tipado, no prosa.
-
-```python
-PROMPT_REVISOR = """
-Eres un revisor de calidad independiente. NO has visto ninguna otra revisión de esta salida.
-
-## Especificación de la tarea
-{especificacion}
-
-## Salida bajo revisión
-{salida}
-
-## Rúbrica de evaluación
-{rubrica}
-
-## Instrucciones
-Evalúa la salida contra CADA criterio de la rúbrica. Para cada uno:
-- PASA: criterio plenamente cumplido, sin problemas
-- FALLA: problema concreto encontrado (cita el problema exacto)
-
-Devuelve tu evaluación como JSON estructurado:
-{
-  "veredicto": "PASA" | "FALLA",
-  "checks": [
-    {"criterio": "...", "resultado": "PASA|FALLA", "detalle": "..."}
-  ],
-  "problemas_criticos": ["..."],   // bloqueantes que deben corregirse
-  "sugerencias": ["..."]            // mejoras no bloqueantes
-}
-
-Sé riguroso. Tu trabajo es encontrar problemas, no aprobar.
-"""
-```
-
-```python
-# Lanza los revisores en paralelo (subagentes de Theus)
-revision_b = Agente(prompt=PROMPT_REVISOR.format(...), descripcion="Revisor independiente B")
-revision_c = Agente(prompt=PROMPT_REVISOR.format(...), descripcion="Revisor independiente C")
-
-# Ambos corren en concurrencia — ninguno ve al otro
-```
-
-### Diseño de la rúbrica
-
-La rúbrica es la entrada más importante. Rúbricas vagas producen revisiones vagas. Cada criterio debe tener una condición objetiva de pasa/falla.
-
-| Criterio | Condición de aprobación | Señal de fallo |
-|-----------|---------------|----------------|
-| Precisión factual | Todas las afirmaciones son verificables contra el material fuente o conocimiento común | Estadísticas inventadas, números de versión erróneos, APIs inexistentes |
-| Sin alucinaciones | Sin entidades, citas, URLs ni referencias fabricadas | Enlaces a páginas que no existen, citas atribuidas sin fuente |
-| Completitud | Cada requisito de la especificación está cubierto | Secciones ausentes, casos borde omitidos, cobertura incompleta |
-| Cumplimiento | Pasa todas las restricciones del proyecto | Términos prohibidos, violaciones de tono, incumplimiento regulatorio |
-| Consistencia interna | Sin contradicciones dentro de la salida | La sección A dice X, la sección B dice no-X |
-| Corrección técnica | El código compila/corre, los algoritmos son sólidos | Errores de sintaxis, bugs de lógica, afirmaciones de complejidad erróneas |
-
-#### Extensiones de rúbrica por dominio
-
-**Contenido/Marketing:**
-- Adherencia a la voz de marca.
-- Requisitos SEO cumplidos (densidad de palabras clave, meta tags, estructura).
-- Sin uso indebido de marcas de la competencia.
-- CTA presente y correctamente enlazado.
-
-**Código:**
-- Seguridad de tipos (sin fugas de `any`, manejo correcto de nulos).
-- Cobertura del manejo de errores.
-- Seguridad (sin secretos en el código, validación de entradas, prevención de inyección).
-- Tests para las rutas nuevas.
-
-**Sensible a cumplimiento (regulado, legal, financiero):**
-- Sin garantías de resultado ni afirmaciones sin sustento.
-- Avisos legales requeridos presentes.
-- Solo terminología aprobada.
-- Lenguaje apropiado a la jurisdicción.
-
-### Fase 3: Compuerta de veredicto
-
-```python
-def veredicto_dual(revision_b, revision_c):
-    """Ambos revisores deben aprobar. Sin crédito parcial."""
-    if revision_b.veredicto == "PASA" and revision_c.veredicto == "PASA":
-        return "APTO"  # Publicar
-
-    # Fusiona los hallazgos de ambos revisores, deduplica
-    problemas = dedupe(revision_b.problemas_criticos + revision_c.problemas_criticos)
-    sugerencias = dedupe(revision_b.sugerencias + revision_c.sugerencias)
-
-    return "NO_APTO", problemas, sugerencias
-```
-
-Por qué ambos deben aprobar: si solo un revisor detecta un problema, ese problema es real. El punto ciego del otro revisor es exactamente el modo de fallo que esta skill existe para eliminar.
-
-### Fase 4: Bucle de convergencia
-
-```python
-MAX_ITERACIONES = 3
-
-for iteracion in range(MAX_ITERACIONES):
-    veredicto, problemas, sugerencias = veredicto_dual(revision_b, revision_c)
-
-    if veredicto == "APTO":
-        registrar_resultado(salida, iteracion, "aprobado")
-        return publicar(salida)
-
-    # Corrige todos los problemas críticos (las sugerencias son opcionales)
-    salida = agente_fix.ejecutar(
-        salida=salida,
-        problemas=problemas,
-        instruccion="Corrige SOLO los problemas señalados. No refactorices ni añadas cambios no pedidos."
-    )
-
-    # Vuelve a pasar AMBOS revisores sobre la salida corregida (agentes frescos, sin memoria de la ronda anterior)
-    revision_b = Agente(prompt=PROMPT_REVISOR.format(salida=salida, ...))
-    revision_c = Agente(prompt=PROMPT_REVISOR.format(salida=salida, ...))
-
-# Iteraciones agotadas — escala
-registrar_resultado(salida, MAX_ITERACIONES, "escalado")
-escalar_a_humano(salida, problemas)
-```
-
-Crítico: cada ronda de revisión usa **agentes frescos**. Los revisores no deben arrastrar memoria de rondas anteriores; el contexto previo crea sesgo de anclaje.
-
-## Patrones de implementación
-
-### Patrón A: subagentes de Theus (recomendado)
-
-Los subagentes proporcionan aislamiento de contexto real. Cada revisor es un proceso separado sin estado compartido.
-
-```text
-En una sesión del CLI, usa la herramienta de agentes (Task/Agent) para lanzar
-los dos revisores en paralelo, cada uno con la rúbrica y la salida completas
-en su prompt, y sin acceso al historial de la conversación principal.
-```
-
-### Patrón B: secuencial en línea (alternativa)
-
-Cuando no hay subagentes disponibles, simula el aislamiento con reinicios explícitos de contexto:
-
-1. Genera la salida.
-2. Contexto nuevo: "Eres el Revisor 1. Evalúa SOLO contra esta rúbrica. Encuentra problemas."
-3. Registra los hallazgos textualmente.
-4. Limpia el contexto por completo.
-5. Contexto nuevo: "Eres el Revisor 2. Evalúa SOLO contra esta rúbrica. Encuentra problemas."
-6. Compara ambas revisiones, corrige, repite.
-
-El patrón de subagentes es estrictamente superior — la simulación en línea arriesga fugas de contexto entre revisores.
-
-### Patrón C: muestreo por lotes
-
-Para lotes grandes (100+ ítems), la verificación completa de cada ítem es prohibitiva en coste. Usa muestreo estratificado:
-
-1. Ejecuta la verificación sobre una muestra aleatoria (10-15 % del lote, mínimo 5 ítems).
-2. Clasifica los fallos por tipo (alucinación, cumplimiento, completitud, etc.).
-3. Si emergen patrones sistemáticos, aplica correcciones dirigidas a todo el lote.
-4. Re-muestrea y re-verifica el lote corregido.
-5. Continúa hasta que una muestra limpia apruebe.
-
-```python
-import random
-
-def verificar_lote(items, rubrica, tasa_muestreo=0.15):
-    muestra = random.sample(items, max(5, int(len(items) * tasa_muestreo)))
-
-    for item in muestra:
-        resultado = verificar_completo(item, rubrica)
-        if resultado.veredicto == "NO_APTO":
-            patron = clasificar_fallo(resultado.problemas)
-            items = corregir_lote(items, patron)  # Corrige todos los ítems que coinciden con el patrón
-            return verificar_lote(items, rubrica)  # Re-muestrea
-
-    return items  # Muestra limpia → publicar el lote
-```
-
-## Modos de fallo y mitigaciones
-
-| Modo de fallo | Síntoma | Mitigación |
-|-------------|---------|------------|
-| Bucle infinito | Los revisores siguen encontrando problemas nuevos tras cada corrección | Tope de iteraciones (3). Escalar. |
-| Sello automático | Ambos revisores aprueban todo | Prompt adversarial: "Tu trabajo es encontrar problemas, no aprobar." |
-| Deriva subjetiva | Los revisores marcan preferencias de estilo, no errores | Rúbrica estricta solo con criterios objetivos de pasa/falla |
-| Regresión al corregir | Corregir el problema A introduce el problema B | Los revisores frescos de cada ronda detectan regresiones |
-| Sesgo de acuerdo | Ambos revisores omiten lo mismo | La independencia lo mitiga, no lo elimina. Para salidas críticas, añade un tercer revisor o un chequeo humano. |
-| Explosión de costos | Demasiadas iteraciones en salidas grandes | Patrón de muestreo por lotes. Topes de presupuesto por ciclo. |
-
-## Integración con otras skills
-
-| Skill | Relación |
-|-------|-------------|
-| `bucle-verificacion` | Úsala para chequeos deterministas (build, lint, test). Esta skill cubre los chequeos semánticos (precisión, alucinaciones). Primero `bucle-verificacion`, luego esta. |
-| `harness-evaluacion` | Los resultados de esta skill alimentan métricas de evaluación. Rastrea pass@k entre ejecuciones para medir la calidad del generador en el tiempo. |
-| `aprendizaje-continuo-v2` | Los hallazgos se convierten en instintos. Fallos repetidos en el mismo criterio → comportamiento aprendido para evitar el patrón. |
-| `compactacion-estrategica` | Ejecuta la verificación ANTES de compactar. No pierdas el contexto de revisión a mitad de verificación. |
-
-## Métricas
-
-Rastrea estas métricas para medir la efectividad del método:
-
-- **Tasa de aprobación al primer intento**: % de salidas que aprueban en la ronda 1 (objetivo: >70 %).
-- **Iteraciones medias hasta convergencia**: rondas promedio hasta APTO (objetivo: <1.5).
-- **Taxonomía de problemas**: distribución de tipos de fallo (alucinación vs completitud vs cumplimiento).
-- **Acuerdo entre revisores**: % de problemas marcados por ambos vs solo uno (acuerdo bajo = la rúbrica necesita ajuste).
-- **Tasa de escape**: problemas detectados tras publicar que la verificación debió atrapar (objetivo: 0).
-
-## Análisis de costos
-
-Este método cuesta aproximadamente 2-3× el costo en tokens de la generación sola por ciclo de verificación. Para la mayoría de salidas de alto riesgo, es una ganga:
-
-```
-Costo de verificar = (tokens de generación) + 2×(tokens de revisión por ronda) × (rondas promedio)
-Costo de NO verificar = (daño reputacional) + (esfuerzo de corrección) + (erosión de confianza)
-```
-
-Para operaciones en lote, el patrón de muestreo reduce el costo a ~15-20 % de la verificación completa capturando >90 % de los problemas sistemáticos.
-
-## Skills relacionadas
-
-- `bucle-verificacion`
-- `harness-evaluacion`
-- `verificacion-factual`

package/vendor/theus-arsenal/skills/revision-riesgo-prediccion/SKILL.md

@@ -1,56 +0,0 @@
----
-name: revision-riesgo-prediccion
-description: Revisa flujos de mercados de predicción, baskets, oráculos y agentes de trading en busca
-  de riesgos de cumplimiento, seguridad, calidad de datos, privacidad y ejecución. Úsala antes de que
-  cualquier flujo maneje autenticación de venues, datos de portafolio del usuario, API keys o
-  planificación de operaciones.
----
-
-# Revisión de riesgo en mercados de predicción
-
-Usa esta skill antes de que un flujo de mercados de predicción toque contexto financiero del usuario, autenticación de venues, datos de portafolio, automatización o herramientas capaces de ejecutar operaciones.
-
-## Puertas de revisión
-
-### Frontera de asesoría
-
-- Confirma que la salida es informativa.
-- Elimina recomendaciones de comprar/vender/mantener/dimensionar.
-- Mantén explícitos los puntos de decisión manual del usuario.
-
-### Frontera de venue y regulatoria
-
-- Identifica los términos del venue, las restricciones geográficas, los límites de cuenta y las reglas de API.
-- Marca para revisión legal cualquier ambigüedad entre apuestas, derivados, valores o commodities cuando sea relevante.
-- No eludas restricciones del venue ni límites de tasa.
-
-### Calidad de datos
-
-- Revisa liquidez de mercado, spread, reglas de resolución, precios obsoletos y timestamps de las fuentes.
-- Separa los datos públicos del venue de los datos restringidos de Itô.
-- No mezcles fuentes públicas y privadas sin etiquetarlas.
-
-### Seguridad
-
-- No solicites ni almacenes claves privadas, frases semilla ni contraseñas.
-- Mantén `ITO_API_KEY` y las API keys de venues fuera de logs y documentación.
-- Usa scopes de solo lectura por defecto.
-- Exige circuit breakers, límites de gasto, ejecuciones en seco y aprobación humana antes de que cualquier implementación privada añada capacidad de ejecución.
-
-### Privacidad
-
-- Minimiza los datos de portafolio, financieros y de base de conocimiento del usuario.
-- Censura las fuentes privadas en artefactos públicos.
-- Conserva solo los campos necesarios para la revisión.
-
-## Contrato de salida
-
-Devuelve:
-
-1. alcance revisado
-2. hallazgos aprueba/advierte/falla
-3. acciones bloqueadas
-4. mitigaciones requeridas
-5. siguiente paso seguro
-
-Si se solicita cualquier paso capaz de ejecutar operaciones, exige un plan de implementación separado y la aprobación explícita del usuario.