theus-cli-linux-x64 0.2.84

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

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

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