theus-cli-linux-x64 1.2.2 → 1.4.0

package/vendor/theus-arsenal/skills/arquitectura-pipelines-recomendacion/SKILL.md

@@ -1,112 +0,0 @@
----
-name: arquitectura-pipelines-recomendacion
-description: Diseña pipelines componibles de recomendación, ranking y feeds con el marco de seis etapas
-  Source→Hydrator→Filter→Scorer→Selector→SideEffect. Úsala cuando el usuario construya cualquier sistema
-  que elija "los K mejores ítems para un (usuario, contexto)" — feeds sociales, CMS de contenido,
-  rerankers de RAG, priorizadores de tareas, triaje de notificaciones, reranking de búsqueda o ranking de anuncios.
----
-
-# Arquitectura de pipelines de recomendación
-
-Skill de especificación y andamiaje para construir pipelines componibles de recomendación, ranking y feeds. Codifica el **patrón de seis etapas** — Source → Hydrator → Filter → Scorer → Selector → SideEffect — popularizado por el [algoritmo For You de X](https://github.com/xai-org/x-algorithm), publicado como código abierto (Apache 2.0). Esta skill es una reimplementación independiente del patrón; no copia código del original.
-
-## Cuándo usarla
-
-- El usuario quiere construir cualquier sistema que elija "los K mejores ítems para un usuario/contexto".
-- El usuario pregunta "¿cómo debería rankear X?" o describe un problema de feed/personalización.
-- El usuario ya tiene una función de scoring y necesita la fontanería del pipeline a su alrededor.
-- El usuario quiere migrar de un único score de relevancia a predicción multi-acción con pesos ajustables.
-- El usuario está envolviendo un scorer de ML o basado en un modelo de lenguaje y necesita filtros, hidratadores, side-effects y un andamio ejecutable en su stack (TypeScript / Go / Python).
-- Disparadores: "sistema de recomendación", "algoritmo de feed", "pipeline de ranking", "feed for you", "pipeline de candidatos", "recomendador de contenido", "reranker de recuperación RAG".
-
-## Cuándo NO usarla
-
-- Trabajo de arquitectura de modelos (diseño de transformers, recuperación two-tower, entrenamiento de embeddings) — esta skill es la fontanería *alrededor* del modelo, no el modelo.
-- Pipelines puros de entrenamiento de ML — la función de scoring es responsabilidad del usuario.
-- Operar un pipeline ya desplegado (monitoreo, autoescalado) — fuera de alcance.
-
-## El marco de seis etapas
-
-| # | Etapa | Trabajo | ¿Paralelo? |
-|---|---|---|---|
-| 1 | **Source** | Obtener candidatos de uno o más orígenes | Sí — múltiples fuentes corren en paralelo |
-| 2 | **Hydrator** | Enriquecer cada candidato con los metadatos que necesitan el filtrado y el scoring | Sí — los hidratadores independientes corren en paralelo |
-| 3 | **Filter** | Descartar candidatos que nunca deben mostrarse (bloqueados, expirados, duplicados, no elegibles) | Secuencial — cada filtro ve menos ítems |
-| 4 | **Scorer** | Asignar a cada candidato superviviente uno o más scores | Secuencial — los scorers posteriores ven los scores anteriores |
-| 5 | **Selector** | Ordenar por score final, devolver el top K | Operación única |
-| 6 | **SideEffect** | Cachear IDs servidos, registrar impresiones, emitir eventos, actualizar contadores | Asíncrono — nunca debe bloquear la respuesta |
-
-### Por qué exactamente este orden
-
-- Fuentes antes de hidratación: saber qué candidatos existen antes de pagar por enriquecerlos.
-- Hidratación antes de filtrado: muchos filtros necesitan metadatos que la fuente no proporcionó.
-- Filtrado antes de scoring: el scoring es la etapa cara; descarta primero lo no elegible.
-- Cadena de scorers (no un scorer único): los sistemas reales componen scoring de ML + reranking de diversidad + reglas de negocio.
-- Selector después del scoring: mantiene el scoring determinista y cacheable.
-- SideEffects al final y asíncronos: los efectos secundarios nunca deben bloquear la respuesta al usuario.
-
-## Flujo de trabajo al invocarla
-
-Guía al usuario por estos ocho pasos:
-
-1. **Aclara el caso de uso** (una ronda, tres preguntas): ¿qué ítems se rankean? ¿cuál es el contexto de entrada? ¿lenguaje/runtime?
-2. **Identifica las fuentes de candidatos**: normalmente in-network (seguidos/propios/suscritos) + out-of-network (recuperación por ML / tendencias / similares-a-gustados).
-3. **Lista las hidrataciones requeridas**: por cada filtro y scorer, ¿qué datos necesita que la fuente no proporcionó?
-4. **Lista los filtros**: duplicados, propios, antigüedad, bloqueo/silencio, ya-servidos, elegibilidad. El orden importa — barato antes que caro.
-5. **Diseña la cadena de scorers**: primario (ML) → combinador (multi-acción con pesos) → diversidad → reglas de negocio.
-6. **Selector**: ordenar descendente por score final, tomar el top K (o mezcla estratificada in-network/out-of-network).
-7. **SideEffects**: cachear IDs servidos, emitir eventos de impresión, actualizar contadores, registrar analítica — todo fire-and-forget.
-8. **Genera el andamio** en el stack del usuario.
-
-## Compromisos clave a exponer (nunca decidas en silencio)
-
-### 1. Score único vs predicción multi-acción
-
-- **Score único**: entrenar un modelo que prediga relevancia. Para cambiar el comportamiento → reentrenar.
-- **Multi-acción**: predecir `P(acción)` para muchas acciones (leer, me gusta, compartir, saltar, reportar) y combinarlas con pesos en tiempo de servicio. Para cambiar el comportamiento → cambiar los pesos. Sin reentrenamiento.
-
-El sistema For You de X usa multi-acción con pesos positivos y negativos. Recomienda multi-acción cuando el usuario espera ajustar con frecuencia.
-
-### 2. Aislamiento de candidatos en el scoring
-
-- **Aislado**: cada candidato se puntúa de forma independiente. Determinista, cacheable.
-- **Conjunto**: los candidatos se atienden entre sí durante el scoring (p. ej., un transformer sobre el lote). Más expresivo pero no determinista entre lotes.
-
-Por defecto, aislamiento. Conjunto solo con una razón concreta (p. ej., diversidad explícita consciente del lote).
-
-### 3. Online vs offline
-
-- **En tiempo de petición (online)**: el pipeline corre en cada petición. Presupuesto de latencia: 100–300 ms. Opción por defecto.
-- **Precomputado (batch offline)**: el pipeline corre periódicamente y los resultados se cachean. Menor latencia, menor frescura.
-- **Híbrido**: recuperación de candidatos offline, ranking online.
-
-## Reglas duras
-
-1. **No inventes cifras de benchmark.** "¿Cuánto más rápido?" → "depende de la carga de trabajo; mídelo tú mismo".
-2. **Disciplina de atribución.** Cuando se cite el patrón, atribúyelo como "popularizado por el algoritmo For You de X, publicado como código abierto" / `github.com/xai-org/x-algorithm` (Apache 2.0).
-3. **Sin uso de marcas.** No nombres el artefacto del usuario como "tipo X" ni uses la marca "For You". El patrón es libre; la marca no. Nombres sugeridos: "pipeline de candidatos", "pipeline de feed", "pipeline de ranking", "pipeline de recomendación".
-4. **Expón los compromisos.** Multi-acción vs único, aislado vs conjunto, online vs offline — nunca decidas en silencio.
-5. **El andamio generado debe ejecutarse.** Nada de pseudocódigo haciéndose pasar por código.
-6. **El orden de los filtros importa.** Barato antes que caro. Universal antes que específico del usuario.
-7. **Los side effects nunca bloquean.** Envuélvelos en patrones fire-and-forget (goroutines / promesas sin await / tareas asyncio).
-
-## Antipatrones
-
-- Puntuar antes de filtrar (desperdicia cómputo en candidatos que se descartarán igualmente).
-- Side effects síncronos (escrituras a caché / emisiones de impresión bloqueando la respuesta).
-- Un único score de "relevancia" cuando el producto necesita ajustar múltiples objetivos (engagement vs seguridad vs diversidad vs anuncios).
-- Scoring conjunto por defecto (no determinista, más difícil de cachear, no compone con etapas de reranking).
-- Generar pseudocódigo "ilustrativo" — el andamio debe ejecutarse de verdad.
-
-## Recetas útiles al generar el andamio
-
-- **Filtros habituales**: duplicado, autor propio, antigüedad máxima, bloqueado/silenciado, ya servido, elegibilidad de negocio.
-- **Scorers habituales**: suma ponderada multi-acción, MMR, penalización por diversidad, corrección de sesgo de posición.
-- **Interfaces**: define cada etapa como una interfaz/trait con un método único (`fetch`, `hydrate`, `filter`, `score`, `select`, `run`), de modo que el pipeline sea una lista componible de etapas.
-- Entrega el andamio con al menos una prueba verde por etapa en el framework de tests del stack elegido (Jest / go test / pytest).
-
-## Skills relacionadas
-
-- `optimizacion-costos-llm`
-- `diseno-api`
-- `patrones-backend`

package/vendor/theus-arsenal/skills/atlas-datos-prediccion/SKILL.md

@@ -1,53 +0,0 @@
----
-name: atlas-datos-prediccion
-description: Diseña agentes en segundo plano estilo "atlas de datos" para investigación de baskets Itô, descubrimiento de mercados de predicción, borradores de parámetros y edición con humano en el circuito. Úsala para planificar arquitectura y flujo de trabajo, no para ejecutar órdenes en vivo.
----
-
-# Atlas de datos para mercados de predicción (Itô)
-
-Usa esta skill para diseñar un agente que vigila fuentes de datos, construye baskets candidatos de mercados de predicción, redacta borradores de cambios de parámetros y entrega el resultado a un humano para su revisión.
-
-Esta skill describe arquitectura y flujo de trabajo. No ejecuta trading en vivo.
-
-## Guardarraíles
-
-- Mantén toda ejecución detrás de una aprobación humana explícita.
-- Exige `ITO_API_KEY` solo para acceso de lectura a datos de Itô, salvo que una implementación privada separada añada controles de ejecución de forma explícita. Es un acceso externo propio del usuario, no forma parte de la suscripción de Theus.
-- No persistas datos privados del usuario salvo que el repositorio destino ya tenga un contrato de almacenamiento y el usuario lo pida.
-- No expongas lógica de estrategia privada, credenciales de venues ni rutas locales en documentación pública.
-
-## Patrón de arquitectura
-
-Usa cuatro carriles:
-
-1. **Recolector de investigación**: web pública, X, GitHub, documentación de venues, metadatos de APIs y endpoints de lectura de Itô cuando exista acceso autorizado.
-2. **Redactor de baskets**: convierte las fuentes en subyacentes candidatos, pesos, reglas y preguntas.
-3. **Revisor de riesgo**: verifica frescura de datos, límites de venue, ambigüedad de resolución, notas de cumplimiento y exposición a inyección de prompts.
-4. **Editor humano**: abre un chat o estado de UI donde el usuario puede aprobar, rechazar, ajustar o pedir más investigación.
-
-## Flujo de trabajo
-
-1. Define el objetivo del usuario y las acciones excluidas.
-2. Lista las fuentes de datos y los requisitos de acceso.
-3. Redacta una especificación de basket con procedencia para cada subyacente.
-4. Produce parámetros editables, no órdenes ejecutables.
-5. Almacena una pista de auditoría: entradas, salida del modelo, fuentes y decisión humana.
-
-## Cadenas de skills útiles
-
-- `investigacion-profunda` para la recolección de fuentes.
-- `api-x` para señal social/de eventos actual.
-- `inteligencia-mercados-prediccion` para contexto de venues y subyacentes.
-- `comparador-baskets-prediccion` para el emparejamiento con la base de conocimiento del usuario.
-- `revision-riesgo-prediccion` antes de cualquier integración con capacidad de ejecución.
-
-## Contrato de salida
-
-Devuelve una especificación de flujo de trabajo lista para implementar con:
-
-- fuentes de datos
-- puertas de acceso
-- roles de agentes
-- puntos de aprobación humana
-- frontera de almacenamiento/auditoría
-- no-objetivos

package/vendor/theus-arsenal/skills/auditoria-arquitectura-agentes/SKILL.md

@@ -1,257 +0,0 @@
----
-name: auditoria-arquitectura-agentes
-description: Diagnóstico integral de aplicaciones con agentes y LLM. Audita las 12 capas del stack
-  agéntico en busca de regresiones de wrapper, contaminación de memoria, fallos de disciplina de tools,
-  bucles de reparación ocultos y corrupción de renderizado. Produce hallazgos ordenados por severidad
-  con correcciones código-primero.
----
-
-# Auditoría de arquitectura de agentes
-
-Flujo de diagnóstico para sistemas de agentes que ocultan fallos detrás de capas de wrapper, memoria obsoleta, bucles de reintento o mutaciones de transporte/renderizado.
-
-## Cuándo activarla
-
-**OBLIGATORIA para:**
-- Publicar a producción cualquier agente o aplicación impulsada por LLM
-- Lanzar funcionalidades con llamadas a tools, memoria o flujos multipaso
-- Cuando el comportamiento del agente se degrada tras añadir capas de wrapper
-- Cuando el usuario reporta "el agente está empeorando" o "las tools fallan de forma intermitente"
-- Cuando el mismo modelo funciona en pruebas directas pero se rompe dentro de tu wrapper
-- Cuando llevas más de 15 minutos depurando el comportamiento del agente sin encontrar la causa raíz
-
-**Especialmente crítica cuando:**
-- Añadiste nuevas capas de prompt, definiciones de tools o sistemas de memoria
-- Distintos agentes del sistema se comportan de forma inconsistente
-- El modelo estaba bien ayer pero hoy alucina
-- Sospechas de bucles ocultos de reparación/reintento que mutan respuestas en silencio
-
-**No usarla para:**
-- Depuración general de código — usa `introspeccion-agente`
-- Revisión de código — usa los agentes revisores por lenguaje
-- Escaneo de seguridad — usa `revision-seguridad`
-- Benchmarking de rendimiento de agentes — usa el agente `evaluador-agentes`
-- Escribir funcionalidades nuevas — usa la skill de flujo apropiada
-
-## El stack de 12 capas
-
-Todo sistema de agentes tiene estas capas. Cualquiera puede corromper la respuesta:
-
-| # | Capa | Qué sale mal |
-|---|------|--------------|
-| 1 | Prompt de sistema | Instrucciones en conflicto, inflación de instrucciones |
-| 2 | Historial de sesión | Inyección de contexto obsoleto de turnos anteriores |
-| 3 | Memoria de largo plazo | Contaminación entre sesiones, temas viejos en conversaciones nuevas |
-| 4 | Destilación | Artefactos comprimidos que reingresan como pseudohechos |
-| 5 | Recuperación activa | Capas de re-resumen redundantes que desperdician contexto |
-| 6 | Selección de tools | Enrutamiento a la tool equivocada, el modelo omite tools requeridas |
-| 7 | Ejecución de tools | Ejecución alucinada — afirma llamar pero no lo hace |
-| 8 | Interpretación de tools | Salida de la tool mal leída o ignorada |
-| 9 | Modelado de respuesta | Corrupción de formato en la respuesta final |
-| 10 | Renderizado de plataforma | Mutación en la capa de transporte (UI, API o CLI mutan respuestas válidas) |
-| 11 | Bucles de reparación ocultos | Agentes de fallback/reintento silenciosos que ejecutan un segundo pase de LLM |
-| 12 | Persistencia | Estado expirado o artefactos cacheados reutilizados como evidencia viva |
-
-## Patrones de fallo comunes
-
-### 1. Regresión de wrapper
-
-El modelo base produce respuestas correctas, pero las capas de wrapper las empeoran.
-
-**Síntomas:**
-- El modelo funciona bien en llamada directa a la API, se rompe dentro de tu agente
-- Añadiste una nueva capa de prompt y el comportamiento existente se degradó
-- El agente suena confiado pero se equivoca con confianza
-- "Funcionaba antes de la última actualización"
-
-### 2. Contaminación de memoria
-
-Temas antiguos se filtran a conversaciones nuevas vía historial, recuperación de memoria o destilación.
-
-**Síntomas:**
-- El agente saca temas pasados sin relación
-- Las correcciones del usuario no persisten (la memoria vieja sobrescribe la nueva)
-- Artefactos de la misma sesión reingresan como pseudohechos
-- La memoria crece sin límite y degrada la calidad de las respuestas con el tiempo
-
-### 3. Fallo de disciplina de tools
-
-Las tools se declaran en el prompt pero no se exigen en código. El modelo las omite o alucina su ejecución.
-
-**Síntomas:**
-- "Debes usar la tool X" en el prompt, pero el modelo responde sin llamarla
-- Los resultados de la tool parecen correctos pero nunca se ejecutó realmente
-- Distintas tools compiten por la misma responsabilidad
-- El modelo usa la tool cuando no debe, o la omite cuando es obligatoria
-
-### 4. Corrupción de renderizado/transporte
-
-La respuesta interna del agente es correcta, pero la capa de plataforma la muta durante la entrega.
-
-**Síntomas:**
-- Los logs muestran la respuesta correcta, el usuario ve una salida rota
-- El renderizado de markdown, el parseo de JSON o los fragmentos de streaming corrompen respuestas válidas
-- Un agente de fallback oculto reemplaza la respuesta en silencio antes de la entrega
-- La salida difiere entre terminal y UI
-
-### 5. Capas de agente ocultas
-
-Agentes silenciosos de reparación, reintento, resumen o recuperación se ejecutan sin contratos explícitos.
-
-**Síntomas:**
-- La salida cambia entre la generación interna y la entrega al usuario
-- Bucles de "auto-arreglo" ejecutan un segundo pase de LLM que el usuario desconoce
-- Múltiples agentes modifican la misma salida sin coordinación
-- Las respuestas se "suavizan" o "corrigen" por capas invisibles
-
-## Flujo de auditoría
-
-### Fase 1: alcance
-
-Define qué estás auditando:
-
-- **Sistema objetivo** — ¿qué aplicación de agentes?
-- **Puntos de entrada** — ¿cómo interactúan los usuarios con ella?
-- **Stack de modelos** — ¿qué LLM(s) y proveedores?
-- **Síntomas** — ¿qué reporta el usuario?
-- **Ventana temporal** — ¿cuándo empezó?
-- **Capas a auditar** — ¿cuáles de las 12 capas aplican?
-
-### Fase 2: recolección de evidencia
-
-Reúne evidencia del código:
-
-- **Código fuente** — bucle del agente, enrutador de tools, admisión de memoria, ensamblado de prompts
-- **Logs** — trazas históricas de sesión, registros de llamadas a tools
-- **Configuración** — plantillas de prompt, esquemas de tools, ajustes de proveedor
-- **Archivos de memoria** — procedimientos, bases de conocimiento, archivos de sesión
-
-Usa `rg` para buscar antipatrones:
-
-```bash
-# Requisitos de tools expresados solo en texto de prompt (no en código)
-rg "must.*tool|debe.*tool|required.*call" --type md
-
-# Ejecución de tools sin validación
-rg "tool_call|toolCall|tool_use" --type py --type ts
-
-# Llamadas ocultas al LLM fuera del bucle principal del agente
-rg "completion|chat\.create|messages\.create|llm\.invoke"
-
-# Admisión de memoria sin prioridad para correcciones del usuario
-rg "memory.*admit|long.*term.*update|persist.*memory" --type py --type ts
-
-# Bucles de fallback que ejecutan llamadas adicionales al LLM
-rg "fallback|retry.*llm|repair.*prompt|re-?prompt" --type py --type ts
-
-# Mutación silenciosa de la salida
-rg "mutate|rewrite.*response|transform.*output|shap" --type py --type ts
-```
-
-### Fase 3: mapeo de fallos
-
-Por cada hallazgo, documenta:
-
-- **Síntoma** — lo que ve el usuario
-- **Mecanismo** — cómo el wrapper lo causa
-- **Capa de origen** — cuál de las 12 capas
-- **Causa raíz** — la causa más profunda
-- **Evidencia** — referencia archivo:línea o log:fila
-- **Confianza** — de 0.0 a 1.0
-
-### Fase 4: estrategia de corrección
-
-Orden de corrección por defecto (código-primero, no prompt-primero):
-
-1. **Exigir los requisitos de tools en código** — no solo en texto de prompt
-2. **Eliminar o acotar los agentes de reparación ocultos** — hacer el fallback explícito y con contrato
-3. **Reducir la duplicación de contexto** — la misma información vía prompt + historial + memoria + destilación
-4. **Endurecer la admisión de memoria** — correcciones del usuario > afirmaciones del agente
-5. **Endurecer los disparadores de destilación** — no comprimir lo que no debe comprimirse
-6. **Reducir la mutación de renderizado** — passthrough, no transformación
-7. **Convertir a sobres JSON tipados** — flujo interno estructurado, no prosa libre
-
-## Modelo de severidad
-
-| Nivel | Significado | Acción |
-|-------|-------------|--------|
-| `critical` | El agente puede producir con confianza comportamiento operativo erróneo | Corregir antes del próximo release |
-| `high` | El agente degrada con frecuencia la corrección o la estabilidad | Corregir en este sprint |
-| `medium` | La corrección suele sobrevivir pero la salida es frágil o derrochadora | Planificar para el próximo ciclo |
-| `low` | Problemas mayormente cosméticos o de mantenibilidad | Backlog |
-
-## Formato de salida
-
-Presenta los hallazgos al usuario en este orden:
-
-1. **Hallazgos ordenados por severidad** (lo más crítico primero)
-2. **Diagnóstico de arquitectura** (qué capa corrompió qué, y por qué)
-3. **Plan de corrección ordenado** (código-primero, no prompt-primero)
-
-No abras con cumplidos ni resúmenes. Si el sistema está roto, dilo directamente.
-
-## Preguntas rápidas de diagnóstico
-
-Al auditar un sistema de agentes, responde estas:
-
-| # | Pregunta | Si la respuesta es sí → |
-|---|----------|------------------------|
-| 1 | ¿Puede el modelo omitir una tool requerida y aun así responder? | Tool no exigida en código |
-| 2 | ¿Aparece contenido de conversaciones antiguas en turnos nuevos? | Contaminación de memoria |
-| 3 | ¿Está la misma información en el prompt de sistema Y la memoria Y el historial? | Duplicación de contexto |
-| 4 | ¿La plataforma ejecuta un segundo pase de LLM antes de la entrega? | Bucle de reparación oculto |
-| 5 | ¿Difiere la salida entre la generación interna y la entrega al usuario? | Corrupción de renderizado |
-| 6 | ¿Las reglas "debe usar la tool X" están solo en texto de prompt? | Fallo de disciplina de tools |
-| 7 | ¿Puede el propio monólogo del agente convertirse en memoria persistente? | Envenenamiento de memoria |
-
-## Antipatrones a evitar
-
-- No culpes al modelo antes de falsar las regresiones de las capas de wrapper.
-- No culpes a la memoria sin mostrar la ruta de contaminación.
-- No dejes que un estado actual limpio borre un incidente histórico sucio.
-- No trates la prosa en markdown como un protocolo interno confiable.
-- No aceptes "debe usar la tool" en texto de prompt cuando el código nunca lo exige.
-- Mantén los hallazgos directos, respaldados por evidencia y ordenados por severidad.
-
-## Esquema de reporte
-
-Las auditorías deben producir reportes estructurados con esta forma:
-
-```json
-{
-  "schema_version": "theus.auditoria-arquitectura-agentes.reporte.v1",
-  "executive_verdict": {
-    "overall_health": "high_risk",
-    "primary_failure_mode": "string",
-    "most_urgent_fix": "string"
-  },
-  "scope": {
-    "target_name": "string",
-    "model_stack": ["string"],
-    "layers_to_audit": ["string"]
-  },
-  "findings": [
-    {
-      "severity": "critical|high|medium|low",
-      "title": "string",
-      "mechanism": "string",
-      "source_layer": "string",
-      "root_cause": "string",
-      "evidence_refs": ["archivo:línea"],
-      "confidence": 0.0,
-      "recommended_fix": "string"
-    }
-  ],
-  "ordered_fix_plan": [
-    { "order": 1, "goal": "string", "why_now": "string", "expected_effect": "string" }
-  ]
-}
-```
-
-## Skills relacionadas
-
-- `introspeccion-agente` — Depurar fallos de runtime del agente (bucles, timeouts, errores de estado)
-- `evaluador-agentes` (agente) — Comparar el rendimiento de agentes cara a cara
-- `revision-seguridad` — Auditoría de seguridad de código y configuración
-- `harness-agente-autonomo` — Montar operaciones de agentes autónomos
-- `construccion-harness-agentes` — Construir harnesses de agentes desde cero

package/vendor/theus-arsenal/skills/auditoria-produccion/SKILL.md

@@ -1,180 +0,0 @@
----
-name: auditoria-produccion
-description: Auditoría de preparación para producción basada en evidencia local, para apps ya desplegadas, revisiones pre-lanzamiento, chequeos post-merge y preguntas de "¿qué se rompe en prod?" sin enviar datos del repo a un servicio de auditoría externo.
-version: "1.0.0"
----
-
-# Auditoría de producción
-
-Usa esta skill cuando el usuario pregunte si una aplicación está lista para lanzarse, qué podría romperse en producción o qué debe corregirse antes de un lanzamiento. Es una reescritura segura para mantenedores de la idea comunitaria (ya desactualizada) de auditoría de producción: conserva la lente útil de preparación para producción y elimina la ejecución externa sin fijar versiones y el envío de datos a terceros.
-
-## Cuándo usar
-
-- El usuario pregunta "¿esto está listo para producción?", "¿qué se rompería en prod?", "¿qué se nos pasó?", "audita este repo" o "¿listo para lanzar?"
-- Se hizo merge de una funcionalidad y necesita una pasada de riesgo pre-deploy o post-merge.
-- Se acerca un lanzamiento público, una demo, un rollout a clientes o una presentación a inversionistas.
-- El CI está en verde pero el usuario quiere riesgo de producción, no solo el estado de los tests.
-- Hay disponible una URL desplegada, una rama de release, un PR o el checkout actual para recolectar evidencia.
-
-## Cuándo no usar
-
-- Durante la implementación activa, cuando la lente correcta es la codificación segura a nivel de línea; usa primero `revision-seguridad`.
-- Para librerías puras, plantillas, repos solo de docs o scaffolds, salvo que el usuario quiera preparación de empaquetado/release en lugar de preparación de aplicación.
-- Cuando el usuario pide una auditoría formal de cumplimiento. Esta skill es triaje de ingeniería, no una certificación legal, financiera, médica ni regulatoria.
-- Cuando la única evidencia disponible es una idea de producto sin repo, deployment, CI ni superficie de runtime.
-
-## Cómo funciona
-
-Construye la auditoría a partir de evidencia local y autorizada por el usuario. No ejecutes código remoto sin versión fijada, no subas el contenido del repositorio a servicios de terceros y no llames a escáneres externos salvo que el usuario apruebe explícitamente esa herramienta y ese flujo de datos concretos.
-
-Sigue este orden:
-
-1. Establece la superficie del release.
-2. Lee los cambios recientes y el estado de la rama actual.
-3. Inspecciona las fronteras de runtime, auth, datos, pagos, jobs en segundo plano, IA y despliegue que realmente existan en el repo.
-4. Revisa CI, tests, migraciones, documentación de variables de entorno y ruta de rollback.
-5. Produce una recomendación breve de lanzar/bloquear con correcciones específicas.
-
-## Checklist de evidencia
-
-Empieza con señales locales y baratas:
-
-```text
-git status --short --branch
-git log --oneline --decorate -20
-git diff --stat origin/main...HEAD
-```
-
-Luego inspecciona la superficie específica del proyecto:
-
-- Scripts del package, workflows de CI, scripts de release, archivos Docker y manifiestos de despliegue.
-- Rutas de API, webhooks, middleware de auth, workers en segundo plano, cron jobs y migraciones de base de datos.
-- Documentación de variables de entorno y chequeos de arranque.
-- Hooks de observabilidad, reporte de errores, logs, health checks y dashboards.
-- Instrucciones de rollback, seed, migración y backfill.
-- Cobertura E2E de las rutas de usuario que más importan.
-
-Si hay una URL desplegada en el alcance, usa chequeos de navegador o HTTP solo contra esa URL y evita acciones con credenciales salvo que el usuario proporcione una cuenta de prueba segura.
-
-## Lentes de riesgo
-
-### Seguridad y auth
-
-- ¿Están claramente separadas las rutas públicas, las rutas de API y las rutas de administración?
-- ¿La autenticación y la autorización se aplican del lado del servidor?
-- ¿Los secretos se mantienen fuera de los bundles del cliente, los logs, la salida de ejemplos y los archivos versionados?
-- ¿Existen rate limits, protecciones CSRF, política CORS y validación de uploads donde la app los necesita?
-- ¿La superficie de IA o de agentes se defiende contra inyección de prompts, abuso de herramientas y contenido no confiable cruzando hacia acciones privilegiadas?
-
-### Integridad de datos
-
-- ¿Las migraciones corren hacia adelante limpiamente y tienen un plan de rollback o recuperación?
-- ¿Las migraciones destructivas, los backfills y las importaciones de datos se escalonan de forma segura?
-- ¿Las políticas de base de datos, los grants y los límites de roles de servicio coinciden con el modelo de tenencia de la app?
-- ¿Los reintentos son idempotentes en escrituras, jobs y handlers de webhooks?
-
-### Pagos y webhooks
-
-- ¿Se verifican las firmas de los webhooks antes de parsear campos confiables del payload?
-- ¿Cada webhook de pago, suscripción o fulfillment es idempotente?
-- ¿Se manejan replays, entregas duplicadas y entregas fuera de orden?
-- ¿Las credenciales de modo test y modo live están separadas?
-
-### Operaciones
-
-- ¿La app puede arrancar desde un checkout limpio usando comandos documentados?
-- ¿Las variables de entorno requeridas están nombradas, validadas y fallan rápido?
-- ¿Hay un health check que demuestre que las dependencias son alcanzables?
-- ¿Están documentadas las rutas de deploy, rollback y dueño de incidentes?
-- ¿Los logs son útiles sin filtrar secretos ni datos personales?
-
-### Experiencia de usuario
-
-- ¿Las rutas críticas del lanzamiento están cubiertas en escritorio y móvil?
-- ¿Los formularios son usables en móvil sin zoom de input, solapamiento de layout ni estados de envío bloqueados?
-- ¿Los estados de carga, vacío, error y permiso denegado le dicen al usuario qué pasó?
-- ¿Hay una ruta de soporte o recuperación cuando falla una operación crítica?
-
-## Puntuación
-
-Usa las puntuaciones para forzar la priorización, no para implicar certeza matemática.
-
-| Banda | Puntuación | Significado |
-| --- | --- | --- |
-| Bloqueado | 0-49 | No lanzar hasta corregir los riesgos principales |
-| Riesgoso | 50-69 | Lanzar solo detrás de un rollout pequeño o beta interna |
-| Lanzable con salvedades | 70-84 | Lanzar si los responsables aceptan los riesgos listados |
-| Sólido | 85-100 | Sin bloqueantes de lanzamiento obvios según la evidencia disponible |
-
-Limita la puntuación a `69` si cualquiera de estas condiciones se cumple:
-
-- Falta autenticación o autorización sobre datos sensibles.
-- Los webhooks de pago o fulfillment no son idempotentes.
-- Las migraciones requeridas no pueden ejecutarse de forma segura.
-- Hay secretos expuestos en bundles del cliente, logs o archivos versionados.
-- No hay ruta de rollback para un release de alto impacto.
-
-Limita la puntuación a `84` si el CI no está en verde o la ruta crítica del lanzamiento no se probó de extremo a extremo.
-
-## Formato de salida
-
-Empieza con una sola frase:
-
-```text
-Auditoría de producción: 76/100, lanzable con salvedades, con la idempotencia de webhooks y la documentación de rollback como los dos riesgos a corregir antes del lanzamiento público.
-```
-
-Luego lista:
-
-- `Bloqueantes`: ítems imprescindibles antes del deploy.
-- `Correcciones de alto valor`: las siguientes correcciones si el usuario quiere mejorar la puntuación.
-- `Evidencia revisada`: archivos, comandos, CI, URL desplegada o PRs inspeccionados.
-- `Evidencia faltante`: qué cambiaría la confianza si se proporcionara.
-- `Siguiente acción`: una corrección o paso de verificación concreto.
-
-Mantén las fortalezas cortas. El usuario preguntó por la preparación, así que la respuesta útil es el riesgo restante y la siguiente acción.
-
-## Ejemplo
-
-Usuario:
-
-```text
-¿esto está listo para lanzar?
-```
-
-Respuesta:
-
-```text
-Auditoría de producción: 68/100, riesgoso, porque los webhooks de Stripe se verifican pero no son idempotentes y no hay nota de rollback para la migración pendiente.
-
-Bloqueantes:
-- Añadir idempotencia a `checkout.session.completed` antes de completar pedidos.
-- Escribir y probar la ruta de rollback de `20260511_add_billing_state.sql`.
-
-Correcciones de alto valor:
-- Añadir un health check que verifique la alcanzabilidad de la base de datos y del proveedor de pagos.
-- Añadir una ruta E2E para upgrade, fulfillment por webhook y refresco de la página de facturación.
-
-Evidencia revisada:
-- `api/stripe/webhook.ts`
-- `db/migrations/20260511_add_billing_state.sql`
-- Ejecución de GitHub Actions de la rama de release
-
-Siguiente acción: ¿Quieres que parchee primero la idempotencia de los webhooks?
-```
-
-## Anti-patrones
-
-- Ejecutar `npx <paquete>@latest` o un escáner remoto como ruta de auditoría por defecto.
-- Subir código fuente, secretos, datos de clientes o topología privada a un servicio de auditoría externo sin aprobación explícita.
-- Producir una puntuación sin nombrar la evidencia revisada.
-- Tratar un CI en verde como preparación para producción.
-- Terminar con un genérico "avísame qué quieres hacer".
-
-## Ver también
-
-- Skill: `revision-seguridad`
-- Skill: `patrones-despliegue`
-- Skill: `testing-e2e`
-- Skill: `flujo-tdd`
-- Skill: `bucle-verificacion`