theus-cli-linux-x64 1.2.2 → 1.4.0

package/vendor/theus-arsenal/skills/flujo-ingenieria-ml/SKILL.md

@@ -1,343 +0,0 @@
----
-name: flujo-ingenieria-ml
-description: Flujo de ingeniería de machine learning en producción — contratos de datos, entrenamiento reproducible, evaluación, despliegue, monitoreo y rollback. Úsala al construir, revisar o endurecer sistemas de ML más allá de notebooks puntuales.
----
-
-# Flujo de ingeniería de machine learning
-
-Usa esta skill para convertir trabajo de modelado en un sistema de ML de producción con contratos de datos claros, entrenamiento repetible, puertas de calidad medibles, artefactos desplegables y monitoreo operativo.
-
-## Cuándo activarla
-
-- Al planificar o revisar una funcionalidad de ML de producción, un refresh de modelo, un sistema de ranking, un recomendador, un clasificador, un flujo de embeddings o un pipeline de pronóstico
-- Al convertir código de notebook en un pipeline reutilizable de entrenamiento, evaluación, inferencia por lotes o inferencia en línea
-- Al diseñar criterios de promoción de modelos, evaluaciones offline/online, seguimiento de experimentos o rutas de rollback
-- Al depurar fallos causados por drift de datos, fuga de etiquetas, features obsoletas, artefactos desalineados o lógica inconsistente entre entrenamiento y servicio
-- Al añadir monitoreo de modelos, despliegue canario, tráfico sombra o verificaciones de calidad post-despliegue
-
-## Calibración de alcance
-
-Usa solo los carriles que encajen con el sistema que tienes delante. Esta skill sirve para ranking, búsqueda, recomendaciones, clasificadores, pronósticos, embeddings, flujos con LLM, detección de anomalías y analítica por lotes, pero no debe forzar una única arquitectura sobre todos ellos.
-
-- No asumas que todo modelo tiene etiquetas supervisadas, servicio en línea, feature store, PyTorch, GPUs, revisión humana, tests A/B o retroalimentación en tiempo real.
-- No añadas maquinaria pesada de MLOps cuando un contrato de datos, una línea base, un script de evaluación y una nota de rollback bastarían para que el cambio sea revisable.
-- Haz explícitas las suposiciones cuando el proyecto carezca de etiquetas, resultados retrasados, definiciones de segmentos, tráfico de producción o dueños del monitoreo.
-- Trata los ejemplos como andamios intercambiables. Sustituye métricas, modo de servicio, almacenes de datos y mecánica de despliegue por los equivalentes nativos del proyecto.
-
-## Skills relacionadas
-
-- `patrones-python` y `testing-python` para implementación en Python y cobertura con pytest
-- `patrones-pytorch` para modelos de deep learning, data loaders, manejo de dispositivos y bucles de entrenamiento
-- `harness-evaluacion` y `regresion-codigo-ia` para puertas de promoción y verificaciones de regresión asistidas por el agente
-- `migraciones-bd`, `patrones-postgres` y `patrones-clickhouse` para almacenamiento de datos y superficies analíticas
-- `patrones-despliegue`, `patrones-docker` y `revision-seguridad` para servicio, secretos, contenedores y endurecimiento de producción
-
-## Reutiliza la superficie de ingeniería de software
-
-No trates la ingeniería de ML como algo separado de la ingeniería de software. La mayoría de los flujos de SWE de este arsenal aplican directamente a sistemas de ML, muchas veces con modos de fallo más estrictos. Emplea esta skill junto con el agente `revisor-ml` para la revisión especializada.
-
-| Superficie SWE | Uso en ingeniería de ML |
-|----------------|-------------------------|
-| `capacidad-producto` / `decisiones-arquitectura` | Convertir el trabajo de modelado en contratos de producto explícitos y registrar decisiones irreversibles de datos, modelo y despliegue |
-| `onboarding-codigo` / `tours-de-codigo` / agente `explorador-codigo` | Encontrar las rutas existentes de entrenamiento, features, servicio, evaluación y monitoreo antes de introducir una pila de ML paralela |
-| `/plan` / `/funcionalidad` | Delimitar los cambios de modelo como capacidades de producto con fases de datos, evaluación, servicio y rollback |
-| `flujo-tdd` / `testing-python` | Testear transformaciones de features, lógica de particionado, cálculo de métricas, carga de artefactos y esquemas de inferencia antes de implementar |
-| agentes `revisor-codigo` / `revisor-ml` | Revisar la calidad del código además de riesgos específicos de ML: fugas, reproducibilidad, promoción y monitoreo |
-| `/arreglar-build` / agente `analista-tests-pr` | Diagnosticar CI roto, evaluaciones inestables, fixtures faltantes y fallos de modelo o dependencias por entorno |
-| `/control-calidad` / `/cobertura-tests` | Exigir evidencia automatizada para transformaciones, métricas, contratos de inferencia, puertas de promoción y comportamiento de rollback |
-| `harness-evaluacion` / `bucle-verificacion` | Convertir métricas offline, verificaciones por segmento, presupuestos de latencia y simulacros de rollback en puertas repetibles |
-| `regresion-codigo-ia` | Preservar cada bug de producción como regresión: feature faltante, etiqueta obsoleta, artefacto malo, drift de esquema o desalineación de servicio |
-| `diseno-api` / `patrones-backend` | Diseñar APIs de predicción, jobs por lotes, endpoints de reentrenamiento idempotentes y envolturas de respuesta |
-| `migraciones-bd` / `patrones-postgres` / `patrones-clickhouse` | Versionar etiquetas, snapshots de features, logs de predicciones, métricas de experimentos y analítica de drift |
-| `patrones-despliegue` / `patrones-docker` | Empaquetar imágenes reproducibles de entrenamiento y servicio con health checks, límites de recursos y rollback |
-| `vigilancia-canary` | Hacer visible la salud del despliegue con paneles por versión de modelo, segmento, drift, latencia, costo y etiquetas retrasadas |
-| `revision-seguridad` / agente `escaner-secretos` | Revisar artefactos de modelo, notebooks, prompts, datasets y logs en busca de secretos, PII, deserialización insegura y riesgo de cadena de suministro |
-| `testing-e2e` / `qa-navegador` / `accesibilidad` | Testear los flujos críticos de producto que consumen predicciones, incluidos los estados de explicabilidad y de UI de respaldo |
-| `benchmark` / agente `optimizador-rendimiento` | Medir throughput, latencia p95, memoria, utilización de GPU y costo por predicción o reentrenamiento |
-| `optimizacion-costos-llm` / `presupuesto-contexto` | Enrutar cargas de LLM/embeddings por calidad, latencia y presupuesto en vez de usar por defecto el modelo más grande |
-| `consulta-documentacion` / `buscar-primero` | Verificar el comportamiento actual de librerías de servicio de modelos, feature stores, bases vectoriales y herramientas de evaluación antes de programar |
-| `flujo-git` / `operaciones-github` / `pipeline-opensource` | Empaquetar cambios de ML para revisión con alcance nítido, artefactos generados excluidos y evidencia de tests reproducible |
-| `compactacion-estrategica` | Dividir el trabajo largo de ML en pistas paralelas: contrato de datos, harness de evaluación, ruta de servicio, monitoreo y documentación |
-
-## Diez simulaciones de tareas de ML
-
-Usa estas simulaciones como verificación de cobertura al planificar o revisar trabajo de ingeniería de ML. Un buen flujo debe reducir cada tarea a contratos explícitos, superficies SWE reutilizables, evidencia automatizada y un artefacto revisable.
-
-| ID | Tarea común de ML | Ruta recomendada | Resultado exigido | Carriles cubiertos |
-|----|-------------------|------------------|-------------------|--------------------|
-| ML-01 | Encuadrar una capacidad ambigua de predicción, ranking, recomendación, clasificación, embeddings o pronóstico | `capacidad-producto`, `/plan`, `decisiones-arquitectura`, `flujo-ingenieria-ml` | Compacto de iteración que nombre a quién le importa, dueño de la decisión, métrica de éxito, errores inaceptables, suposiciones, restricciones y primer experimento | contrato de producto, costo por interesado, riesgo, despliegue |
-| ML-02 | Definir metas de métricas, etiquetas, fuentes de datos y presupuesto de errores | `onboarding-codigo`, agente `revisor-bd`, `migraciones-bd`, `patrones-postgres`, `patrones-clickhouse` | Contrato de datos y métricas con grano de entidad, timing y confianza de etiquetas, timing de features, joins point-in-time, política de particionado y snapshot del dataset | contrato de datos, diseño de métricas, fugas, reproducibilidad |
-| ML-03 | Construir un modelo base y una ruta de scoring antes de añadir complejidad | `flujo-tdd`, `testing-python`, `patrones-python`, agente `revisor-codigo` | Scorer base con matriz de confusión, notas de calibración, estimación de latencia/costo, debilidades conocidas y tests de forma y determinismo del score | línea base, scoring, testing, paridad de servicio |
-| ML-04 | Generar features desde hipótesis sobre qué separa los resultados | `patrones-python`, `patrones-pytorch`, `patrones-docker`, `patrones-despliegue` | Plan de features y módulo de transformación que cubra fuente de señal, valores faltantes, atípicos, correlaciones, verificaciones de fuga y equivalencia entrenamiento/servicio | pipeline de features, fugas, entrenamiento, artefactos |
-| ML-05 | Ajustar umbrales, configuraciones y complejidad del modelo bajo tradeoffs | `harness-evaluacion`, `regresion-codigo-ia`, `/control-calidad`, `/cobertura-tests` | Informe de umbrales/configuración que compare precisión, recall, F1, AUC, calibración, segmentos, latencia, costo, complejidad y clases de error aceptables | evaluación, umbral, promoción, regresión |
-| ML-06 | Hacer análisis de errores y convertir los fallos en el siguiente experimento | `harness-evaluacion`, `regresion-codigo-ia`, agentes `revisor-ml` y `cazador-fallos-silenciosos` | Informe de clústeres de error para falsos positivos, falsos negativos, etiquetas ambiguas, features obsoletas, señales faltantes y trazas de bug con lecciones capturadas | análisis de errores, traza de bug, iteración, regresión |
-| ML-07 | Empaquetar un artefacto de modelo para inferencia por lotes o en línea | `diseno-api`, `patrones-backend`, `revision-seguridad`, agente `escaner-secretos` | Bundle de artefacto versionado con preprocesamiento, configuración, restricciones de dependencias, validación de esquema, carga segura y logs sin PII | artefacto, seguridad, contrato de inferencia |
-| ML-08 | Publicar servicio en línea o scoring por lotes con captura de retroalimentación | `diseno-api`, `patrones-backend`, `testing-e2e`, `qa-navegador`, `accesibilidad` | Endpoint de predicción o job por lotes con envoltura de respuesta, timeout, batching, respaldo, versión de modelo, confianza, logging de retroalimentación y tests de flujo de producto | servicio, inferencia por lotes, respaldo, flujo de usuario |
-| ML-09 | Desplegar un modelo con tráfico sombra, canario, test A/B o rollback | `vigilancia-canary`, `bucle-verificacion`, agente `optimizador-rendimiento` | Plan de despliegue que nombre reparto de tráfico, paneles, latencia p95, costo, barandas de calidad, artefacto de rollback y disparador de rollback | despliegue, canario, rollback |
-| ML-10 | Operar, depurar y refrescar un modelo de producción tras el lanzamiento | agentes `cazador-fallos-silenciosos` y `revisor-ml`, agente `actualizador-docs`, `operaciones-github` | Bitácora de observación y plan de refresh con verificaciones de drift, salud de etiquetas retrasadas, dueños de alertas, actualización de runbooks, criterios de reentrenamiento y evidencia en el PR | monitoreo, respuesta a incidentes, reentrenamiento |
-
-## Compacto de iteración
-
-Antes de tocar código de modelo, comprime el trabajo en un solo artefacto revisable. Debe ser lo bastante corto para caber en la descripción de un PR y lo bastante preciso para que otro ingeniero pueda cuestionar los tradeoffs.
-
-```text
-Meta:
-A quién le importa:
-Dueño de la decisión:
-Acción de usuario o sistema que cambia el modelo:
-Métrica de éxito:
-Métricas de baranda:
-Presupuesto de errores:
-Errores inaceptables:
-Errores aceptables:
-Suposiciones:
-Restricciones:
-Etiquetas y snapshot de datos:
-Línea base:
-Señales candidatas:
-Plan de umbral o configuración:
-Segmentos de evaluación:
-Riesgos conocidos:
-Siguiente experimento:
-Rollback o respaldo:
-```
-
-Este compacto es el equivalente en ML de una buena nota de diseño de software. Evita que el equipo optimice una métrica en la que nadie confía, añada features que no atacan el modo de error real o publique complejidad sin rollback.
-
-## Cerebro de decisión
-
-Usa este bucle cuando la tarea sea ambigua, de alto impacto o con muchas métricas:
-
-1. Parte de la decisión, no del modelo. Nombra la acción que cambia el comportamiento aguas abajo.
-2. Nombra a quién le importa y por qué. Distintos interesados pagan costos distintos por falsos positivos, falsos negativos, latencia, gasto de cómputo, opacidad u oportunidades perdidas.
-3. Convierte la ambigüedad en hipótesis. Pregunta qué señal separaría los resultados, qué evidencia la refutaría y qué línea base simple debería ser difícil de batir.
-4. Investiga arte previo o un problema conocido cercano antes de inventar un sistema a medida.
-5. Puntúa las opciones con `(probabilidad, confianza) x (costo, severidad, importancia, impacto)`.
-6. Considera comportamiento adversarial, incentivos, divulgación selectiva, cambios de distribución y bucles de retroalimentación.
-7. Prefiere el cambio más simple que reduzca el error más importante. La simplicidad no es pereza; es una forma de minimizar torpezas preservando la velocidad de iteración.
-8. Captura la decisión, la evidencia, el contraargumento y el siguiente paso reversible.
-
-## Economía de métricas y errores
-
-Elige métricas a partir de los costos de fallo, no por costumbre:
-
-- Usa una matriz de confusión desde el inicio para que el equipo discuta falsos positivos y falsos negativos concretos en lugar de exactitud abstracta.
-- Favorece la precisión cuando domina el costo de una decisión positiva incorrecta.
-- Favorece el recall cuando domina el costo de un positivo perdido.
-- Usa F1 solo cuando el tradeoff precisión/recall esté genuinamente equilibrado y sea explicable.
-- Usa AUC o métricas de ranking cuando la calidad del ordenamiento importe más que un umbral único.
-- Rastrea latencia, throughput, memoria y costo como métricas de primera clase porque acotan la complejidad viable del modelo.
-- Compara contra una línea base y contra el modelo de producción actual antes de celebrar una mejora offline.
-- Trata las señales de retroalimentación del mundo real como etiquetas retrasadas con sesgo, retardo y brechas de cobertura; no las trates como verdad absoluta sin análisis.
-
-Toda elección de métrica debe explicitar qué error abarata, qué error hace más probable y quién absorbe ese costo.
-
-## Hipótesis de datos y features
-
-Las features deben salir de una teoría de separación:
-
-- Texto, campos categóricos, historiales numéricos, relaciones de grafo, recencia, frecuencia y agregados son familias de señal candidatas, no features automáticas.
-- Para cada familia de features, explicita por qué debería separar los resultados y cómo podría filtrar información del futuro.
-- Ante etiquetas ruidosas, considera adjudicación, confianza de etiqueta, targets suaves o ponderación por confianza.
-- Ante clases desbalanceadas, compara pérdida ponderada, remuestreo, movimiento de umbral y reglas de decisión calibradas.
-- Ante valores faltantes, decide si la ausencia es informativa, imputable o motivo para abstenerse.
-- Ante atípicos, decide si recortarlos, agruparlos, investigarlos o preservarlos como señal rara pero importante.
-- Ante features correlacionadas, verifica si son redundantes, inestables o proxies de estado futuro no disponible.
-
-No añadas complejidad al modelo hasta que el análisis de errores demuestre que la línea base falla por una razón que señal o capacidad adicional pueda arreglar de forma plausible.
-
-## Bucle de análisis de errores
-
-Tras cada línea base, corrida de entrenamiento, cambio de umbral o de configuración:
-
-1. Separa los fallos en falsos positivos, falsos negativos, abstenciones, casos de baja confianza y fallos de sistema.
-2. Agrupa los errores por rasgos compartidos: idioma, tipo de entidad, fuente, tiempo, geografía, dispositivo, escasez, recencia, frescura de features, origen de etiqueta o versión de modelo.
-3. Separa los errores del modelo de los bugs de datos, la ambigüedad de etiquetas, la ambigüedad de producto, las brechas de instrumentación y las desalineaciones de servicio.
-4. Traza cada clúster mayor a uno de cuatro movimientos: mejores etiquetas, mejores features, mejor umbral/configuración, o mejor respaldo de producto.
-5. Preserva cada error importante como test de regresión, segmento de evaluación, panel de monitoreo o entrada de runbook.
-6. Redacta la siguiente iteración como experimento falsable, no como una tarea vaga de "mejorar el modelo".
-
-El bucle de ML más fuerte no es entrenar → métrica → publicar. Es error → clúster → hipótesis → experimento → evidencia → sistema más simple.
-
-## Bitácora de observación
-
-Mantén un rastro compacto de decisiones y evidencia junto al código, el PR, el informe de experimento o el runbook:
-
-```text
-Iteración:
-Cambio:
-Por qué importó:
-Movimiento de métrica:
-Movimiento por segmento:
-Falsos positivos:
-Falsos negativos:
-Errores inesperados:
-Decisión:
-Tradeoff aceptado:
-Lección capturada:
-Regresión añadida:
-Deuda creada:
-Siguiente iteración:
-```
-
-Usa la bitácora para que el trabajo de modelado sea acumulativo. La meta es que cada iteración facilite la siguiente decisión, no que solo produzca otro artefacto.
-
-## Flujo central
-
-### 1. Define el contrato de predicción
-
-Captura el contrato a nivel de producto antes de escribir código de modelo:
-
-- Objetivo de predicción y dueño de la decisión
-- Entidad de entrada, esquema de salida, campos de confianza/calibración y latencia permitida
-- Modo de servicio por lotes, en línea, streaming o híbrido
-- Comportamiento de respaldo cuando el modelo, el feature store o una dependencia no esté disponible
-- Ruta de revisión humana o anulación para decisiones de alto impacto
-- Requisitos de privacidad, retención y auditoría para entradas, predicciones y etiquetas
-
-No aceptes "mejorar el modelo" como requisito. Ata el modelo a un comportamiento de producto observable y a una puerta de aceptación medible.
-
-### 2. Fija el contrato de datos
-
-Toda tarea de ML necesita un contrato de datos explícito:
-
-- Grano de entidad y clave primaria
-- Definición de etiqueta, timestamp de etiqueta y retardo de disponibilidad de etiqueta
-- Timestamp de features, SLA de frescura y reglas de join point-in-time
-- Política de partición de entrenamiento, validación, test y backtest
-- Columnas requeridas, nulos permitidos, rangos, categorías y unidades
-- Campos con PII o sensibles que no deben entrar en artefactos de entrenamiento ni logs
-- Versión o ID de snapshot del dataset para reproducibilidad
-
-Protégete primero contra las fugas. Si una feature no está disponible en el momento de la predicción, o se une usando información del futuro, elimínala o muévela a una ruta solo de análisis.
-
-### 3. Construye un pipeline reproducible
-
-El código de entrenamiento debe poder ejecutarlo otro ingeniero sin estado oculto de notebook:
-
-- Usa archivos de configuración tipados o dataclasses para todos los hiperparámetros y rutas
-- Fija (pin) las dependencias de paquetes y modelos
-- Establece semillas aleatorias y documenta cualquier comportamiento no determinista de GPU
-- Registra versión del dataset, SHA del código, hash de configuración, métricas y URI del artefacto
-- Guarda la lógica de preprocesamiento junto al artefacto del modelo, no aparte en un notebook
-- Mantén las transformaciones de entrenamiento, evaluación e inferencia compartidas o generadas desde una sola fuente
-- Haz cada paso idempotente para que los reintentos no corrompan artefactos ni métricas
-
-Prefiere valores inmutables y funciones de transformación puras. Evita mutar data frames compartidos o configuración global durante la generación de features.
-
-```python
-import hashlib
-from dataclasses import dataclass
-from pathlib import Path
-
-
-@dataclass(frozen=True)
-class TrainingConfig:
-    dataset_uri: str
-    model_dir: Path
-    seed: int
-    learning_rate: float
-    batch_size: int
-
-
-def artifact_name(config: TrainingConfig, code_sha: str) -> str:
-    config_key = f"{config.dataset_uri}:{config.seed}:{config.learning_rate}:{config.batch_size}"
-    config_hash = hashlib.sha256(config_key.encode("utf-8")).hexdigest()[:12]
-    return f"{code_sha[:12]}-{config_hash}"
-```
-
-### 4. Evalúa antes de promover
-
-Los criterios de promoción deben declararse antes de que termine el entrenamiento:
-
-- Comparación con el modelo base y con el modelo de producción actual
-- Métrica primaria alineada con el comportamiento del producto
-- Métricas de baranda para latencia, calibración, segmentos de equidad, costo y concentración de errores
-- Métricas por segmento para cohortes, geografías, dispositivos, idiomas o fuentes de datos importantes
-- Intervalos de confianza o varianza de corridas repetidas cuando las métricas sean ruidosas
-- Ejemplos de fallo revisados por una persona en modelos de alto impacto
-- Umbrales explícitos de "no publicar"
-
-```python
-PROMOTION_GATES = {
-    "auc": ("min", 0.82),
-    "calibration_error": ("max", 0.04),
-    "p95_latency_ms": ("max", 80),
-}
-
-
-def assert_promotion_ready(metrics: dict[str, float]) -> None:
-    missing = sorted(name for name in PROMOTION_GATES if name not in metrics)
-    if missing:
-        raise ValueError(f"Faltan métricas requeridas por las puertas de promoción: {missing}")
-
-    failures = {
-        name: value
-        for name, (direction, threshold) in PROMOTION_GATES.items()
-        for value in [metrics[name]]
-        if (direction == "min" and value < threshold)
-        or (direction == "max" and value > threshold)
-    }
-    if failures:
-        raise ValueError(f"El modelo no pasó las puertas de promoción: {failures}")
-```
-
-Usa las métricas offline como puertas, no como garantías. Cuando el modelo cambie el comportamiento del producto, planifica evaluación sombra, despliegue canario o test A/B antes del despliegue completo.
-
-### 5. Empaqueta para servicio
-
-Un artefacto de ML está listo para producción solo cuando el contrato de servicio es testeable:
-
-- El artefacto del modelo incluye versión, referencia a los datos de entrenamiento, configuración y preprocesamiento
-- El esquema de entrada rechaza features inválidas, obsoletas o fuera de rango
-- El esquema de salida incluye la versión del modelo y campos de confianza o explicación cuando aporten
-- La ruta de servicio tiene timeout, batching, límites de recursos y comportamiento de respaldo
-- Los requisitos de CPU/GPU son explícitos y están probados
-- Los logs de predicción evitan PII e incluyen identificadores suficientes para depuración y joins de etiquetas
-- Los tests de integración cubren features faltantes, features obsoletas, tipos incorrectos, lotes vacíos y la ruta de respaldo
-
-Nunca dejes que el código de features exclusivo de entrenamiento diverja del de servicio sin un test que pruebe su equivalencia.
-
-### 6. Opera el modelo
-
-El monitoreo de modelos necesita señales de sistema y de calidad:
-
-- Disponibilidad, tasa de error, tasa de timeout, profundidad de cola y latencia p50/p95/p99
-- Tasa de nulos por feature, drift de rangos, drift categórico y drift de frescura
-- Drift de la distribución de predicciones y de la distribución de confianza
-- Salud de la llegada de etiquetas y métricas de calidad retrasadas
-- Barandas de KPI de negocio y disparadores de rollback
-- Paneles por versión para canarios y rollbacks
-
-Todo despliegue debe tener un plan de rollback que nombre el artefacto anterior, la configuración, la dependencia de datos y el mecanismo de conmutación de tráfico.
-
-## Lista de verificación de revisión
-
-- [ ] El contrato de predicción es explícito y testeable
-- [ ] El contrato de datos define grano de entidad, timing de etiquetas, timing de features y snapshot/versión
-- [ ] Los riesgos de fuga se verificaron contra la disponibilidad en el momento de la predicción
-- [ ] El entrenamiento es reproducible desde código, configuración, versión de datos y semilla
-- [ ] Las métricas comparan contra la línea base y el modelo de producción actual
-- [ ] Hay métricas por segmento y barandas para las cohortes de alto riesgo
-- [ ] Las puertas de promoción están automatizadas y fallan cerradas
-- [ ] Las transformaciones de entrenamiento y servicio son compartidas o tienen test de equivalencia
-- [ ] El artefacto del modelo lleva versión, configuración, referencia al dataset y preprocesamiento
-- [ ] La ruta de servicio valida entradas y tiene timeout, respaldo y rollback
-- [ ] El monitoreo cubre salud del sistema, drift de features, drift de predicciones y etiquetas retrasadas
-- [ ] Los datos sensibles están excluidos de artefactos, logs, prompts y ejemplos
-
-## Antipatrones
-
-- El estado del notebook es requerido para reproducir el modelo
-- La partición aleatoria filtra datos futuros a los conjuntos de validación o test
-- Los joins de features ignoran el tiempo del evento y la disponibilidad de etiquetas
-- La métrica offline mejora mientras segmentos importantes empeoran
-- Los umbrales se ajustan repetidamente sobre el conjunto de test
-- El preprocesamiento de entrenamiento se copia a mano al código de servicio
-- Falta la versión del modelo en los logs de predicción
-- El monitoreo solo verifica el uptime del servicio, no la calidad de datos y predicciones
-- El rollback exige reentrenar en lugar de conmutar a un artefacto bueno conocido
-
-## Expectativas de salida
-
-Al usar esta skill, devuelve artefactos concretos: contrato de datos, puertas de promoción, pasos del pipeline, plan de tests, plan de despliegue o hallazgos de revisión. Señala las incógnitas que bloquean la preparación para producción en lugar de rellenarlas con suposiciones.