theus-cli-linux-arm64 1.2.2 → 1.3.0

package/vendor/theus-arsenal/skills/operaciones-github/SKILL.md

@@ -1,143 +0,0 @@
----
-name: operaciones-github
-description: Operaciones, automatización y gestión de repositorios de GitHub. Triaje de issues, gestión de PRs, operaciones de CI/CD, gestión de releases y monitoreo de seguridad usando la CLI gh. Úsala cuando el usuario quiera gestionar issues, PRs, estado del CI, releases, contribuyentes, elementos inactivos o cualquier tarea operativa de GitHub que vaya más allá de comandos simples de git.
----
-
-# Operaciones de GitHub
-
-Gestiona repositorios de GitHub con foco en la salud de la comunidad, la fiabilidad del CI y la experiencia de los contribuyentes.
-
-## Cuándo activar esta skill
-
-- Al hacer triaje de issues (clasificar, etiquetar, responder, deduplicar)
-- Al gestionar PRs (estado de revisión, checks de CI, PRs inactivos, preparación para el merge)
-- Al depurar fallos de CI/CD
-- Al preparar releases y changelogs
-- Al monitorear alertas de Dependabot y de seguridad
-- Al gestionar la experiencia de contribuyentes en proyectos open source
-- Cuando el usuario dice "revisa GitHub", "haz triaje de issues", "revisa los PRs", "merge", "release", "el CI está roto"
-
-## Requisitos de herramientas
-
-- **CLI gh** para todas las operaciones con la API de GitHub
-- Acceso al repositorio configurado mediante `gh auth login`
-
-## Triaje de issues
-
-Clasifica cada issue por tipo y prioridad:
-
-**Tipos:** bug, feature-request, question, documentation, enhancement, duplicate, invalid, good-first-issue
-
-**Prioridad:** crítica (rotura/seguridad), alta (impacto significativo), media (deseable), baja (cosmética)
-
-### Flujo de triaje
-
-1. Lee el título, el cuerpo y los comentarios del issue
-2. Comprueba si duplica un issue existente (busca por palabras clave)
-3. Aplica las etiquetas adecuadas con `gh issue edit --add-label`
-4. Para preguntas: redacta y publica una respuesta útil
-5. Para bugs que necesitan más información: pide los pasos de reproducción
-6. Para issues aptos para principiantes: añade la etiqueta `good-first-issue`
-7. Para duplicados: comenta con el enlace al original y añade la etiqueta `duplicate`
-
-```bash
-# Buscar posibles duplicados
-gh issue list --search "keyword" --state all --limit 20
-
-# Añadir etiquetas
-gh issue edit <number> --add-label "bug,high-priority"
-
-# Comentar en un issue
-gh issue comment <number> --body "Gracias por reportarlo. ¿Podrías compartir los pasos de reproducción?"
-```
-
-## Gestión de PRs
-
-### Checklist de revisión
-
-1. Comprueba el estado del CI: `gh pr checks <number>`
-2. Comprueba si es fusionable: `gh pr view <number> --json mergeable`
-3. Revisa la antigüedad y la última actividad
-4. Marca los PRs con más de 5 días sin revisión
-5. Para PRs de la comunidad: verifica que incluyan tests y sigan las convenciones
-
-### Política de inactividad
-
-- Issues sin actividad en 14+ días: añade la etiqueta `stale` y comenta pidiendo una actualización
-- PRs sin actividad en 7+ días: comenta preguntando si siguen activos
-- Cierra automáticamente los issues inactivos tras 30 días sin respuesta (añade la etiqueta `closed-stale`)
-
-```bash
-# Encontrar issues inactivos (sin actividad en 14+ días)
-gh issue list --label "stale" --state open
-
-# Encontrar PRs sin actividad reciente
-gh pr list --json number,title,updatedAt --jq '.[] | select(.updatedAt < "2026-03-01")'
-```
-
-## Operaciones de CI/CD
-
-Cuando el CI falla:
-
-1. Revisa la ejecución del workflow: `gh run view <run-id> --log-failed`
-2. Identifica el paso que falla
-3. Determina si es un test inestable (flaky) o un fallo real
-4. Para fallos reales: identifica la causa raíz y propón una corrección
-5. Para tests inestables: anota el patrón para investigarlo más adelante
-
-```bash
-# Listar ejecuciones fallidas recientes
-gh run list --status failure --limit 10
-
-# Ver los logs de una ejecución fallida
-gh run view <run-id> --log-failed
-
-# Reejecutar un workflow fallido
-gh run rerun <run-id> --failed
-```
-
-## Gestión de releases
-
-Al preparar un release:
-
-1. Verifica que todo el CI esté en verde en main
-2. Revisa los cambios sin publicar: `gh pr list --state merged --base main`
-3. Genera el changelog a partir de los títulos de los PRs
-4. Crea el release: `gh release create`
-
-```bash
-# Listar PRs fusionados desde el último release
-gh pr list --state merged --base main --search "merged:>2026-03-01"
-
-# Crear un release
-gh release create v1.2.0 --title "v1.2.0" --generate-notes
-
-# Crear un pre-release
-gh release create v1.3.0-rc1 --prerelease --title "v1.3.0 Release Candidate 1"
-```
-
-## Monitoreo de seguridad
-
-```bash
-# Revisar alertas de Dependabot
-gh api repos/{owner}/{repo}/dependabot/alerts --jq '.[].security_advisory.summary'
-
-# Revisar alertas de escaneo de secretos
-gh api repos/{owner}/{repo}/secret-scanning/alerts --jq '.[].state'
-
-# Revisar y auto-fusionar actualizaciones de dependencias seguras
-gh pr list --label "dependencies" --json number,title
-```
-
-- Revisa y auto-fusiona las actualizaciones de dependencias que sean seguras
-- Marca de inmediato cualquier alerta de severidad crítica o alta
-- Revisa las nuevas alertas de Dependabot al menos una vez por semana
-
-## Puerta de calidad
-
-Antes de dar por completada cualquier tarea de operaciones de GitHub:
-- todos los issues con triaje tienen las etiquetas adecuadas
-- no hay PRs de más de 7 días sin revisión ni comentario
-- los fallos de CI fueron investigados (no solo reejecutados)
-- los releases incluyen changelogs precisos
-- las alertas de seguridad están reconocidas y en seguimiento

package/vendor/theus-arsenal/skills/operaciones-google-workspace/SKILL.md

@@ -1,100 +0,0 @@
----
-name: operaciones-google-workspace
-description: Opera Google Drive, Docs, Sheets y Slides como una sola superficie de trabajo para planes, trackers, presentaciones y documentos compartidos. Usa esta skill cuando el usuario necesite encontrar, resumir, editar, migrar o limpiar activos de Google Workspace sin caer en llamadas crudas a herramientas. Requiere cuenta de Google y conectores propios del usuario.
----
-
-# Operaciones en Google Workspace
-
-> **Requiere servicio externo.** Esta skill opera sobre Google Workspace, un servicio
-> de terceros. Necesitas una cuenta de Google propia y los conectores/servidores MCP
-> de Drive, Docs, Sheets y Slides configurados y autorizados por ti; su uso **no forma
-> parte de la suscripción de Theus**. Si esas herramientas no están disponibles en tu
-> sesión, esta skill no puede ejecutar los flujos descritos.
-
-Esta skill sirve para operar documentos, hojas de cálculo y presentaciones compartidas como sistemas de trabajo, no solo para editar un archivo aislado.
-
-## Cuándo usarla
-
-- El usuario necesita encontrar un doc, una hoja o una presentación y actualizarla en su lugar
-- Al consolidar planes, trackers, notas o listas de clientes almacenadas en Google Drive
-- Al limpiar o reestructurar una hoja de cálculo compartida
-- Al importar, reparar o reformatear una presentación de Google Slides
-- Al producir resúmenes de Docs, Sheets o Slides para la toma de decisiones
-
-## Superficie de herramientas preferida
-
-Usa Google Drive como punto de entrada y luego cambia al especialista correcto:
-
-- Google Docs para documentos con mucho texto
-- Google Sheets para trabajo tabular, fórmulas y gráficos
-- Google Slides para presentaciones, importaciones, migración de plantillas y limpieza
-
-No adivines la estructura solo por los nombres de archivo. Inspecciona primero.
-
-## Flujo de trabajo
-
-### 1. Encuentra el activo
-
-Empieza por la búsqueda de Drive para localizar:
-
-- el archivo exacto
-- activos hermanos
-- posibles duplicados
-- versiones modificadas recientemente
-
-Si varios documentos parecen similares, confirma por título, propietario, fecha de modificación o carpeta.
-
-### 2. Inspecciona antes de editar
-
-Antes de hacer cambios:
-
-- resume la estructura actual
-- identifica pestañas, encabezados o cantidad de diapositivas
-- determina si la tarea es una limpieza local o una cirugía estructural
-
-Elige la herramienta más pequeña que pueda hacer el trabajo con seguridad.
-
-### 3. Edita con precisión
-
-- En Docs: usa ediciones conscientes de índices, no reescrituras vagas
-- En Sheets: opera sobre pestañas y rangos explícitos
-- En Slides: distingue las ediciones de contenido de la limpieza visual o la migración de plantilla
-
-Si el trabajo pedido es visual o sensible al layout, itera con inspección y verificación en lugar de una única actualización gigante a ciegas.
-
-### 4. Mantén limpio el sistema de trabajo
-
-Cuando el archivo forma parte de un flujo mayor, señala también:
-
-- trackers duplicados
-- presentaciones desactualizadas
-- docs obsoletos frente a docs canónicos
-- si el activo debería archivarse, fusionarse o renombrarse
-
-## Formato de salida
-
-Usa:
-
-```text
-ACTIVO
-- nombre del archivo
-- tipo
-- por qué este es el archivo correcto
-
-ESTADO ACTUAL
-- resumen de la estructura
-- problemas o bloqueos clave
-
-ACCIÓN
-- ediciones realizadas o recomendadas
-
-SIGUIENTES PASOS
-- archivar / fusionar / limpiar duplicados / siguiente archivo a actualizar
-```
-
-## Buenos casos de uso
-
-- "Encuentra el documento de planificación activo y condénsalo"
-- "Limpia esta hoja de clientes y muéstrame las filas con riesgo de fuga"
-- "Importa esta presentación a Slides y déjala presentable"
-- "Encuentra el tracker vigente, no el duplicado obsoleto"

package/vendor/theus-arsenal/skills/operaciones-investigacion/SKILL.md

@@ -1,124 +0,0 @@
----
-name: operaciones-investigacion
-description: Flujo de investigación del estado actual, con la evidencia primero. Úsalo cuando el usuario quiera hechos recientes, comparaciones, enriquecimiento de datos o una recomendación construida a partir de evidencia pública actual y de cualquier contexto local aportado.
----
-
-# Operaciones de investigación
-
-Usa esta skill cuando el usuario pida investigar algo actual, comparar opciones, enriquecer información sobre personas o empresas, o convertir consultas repetidas en un flujo monitorizado.
-
-Es la capa operadora del stack de investigación de Theus: se apoya en la búsqueda web nativa, la lectura de fuentes y los subagentes de investigación en paralelo. No sustituye a esas capacidades; te dice cuándo y cómo combinarlas.
-
-## Capacidades del flujo
-
-Apóyate en estas capacidades nativas de Theus según convenga:
-
-- **Búsqueda web nativa** para descubrimiento rápido de información actual.
-- **Lectura de fuentes** (fetch de páginas y documentos) para verificar lo que la búsqueda solo resume.
-- **Subagentes de investigación en paralelo** cuando la síntesis requiere cubrir varias líneas de búsqueda a la vez: lanza un subagente por línea de investigación y consolida sus hallazgos.
-- **Contexto local del repositorio** (código, docs, el subagente `explorador-codigo`) cuando la respuesta puede estar dentro del proyecto y no en la web.
-- La skill `recuperacion-iterativa` cuando el descubrimiento deba refinarse en ciclos progresivos.
-
-## Cuándo usar
-
-- El usuario dice "investiga", "busca", "compara", "con quién debería hablar" o "qué hay de nuevo".
-- La respuesta depende de información pública actual.
-- El usuario ya aportó evidencia y quiere que se incorpore a una recomendación fresca.
-- La tarea podría ser lo bastante recurrente como para convertirse en un monitor en lugar de una consulta puntual.
-
-## Barandillas
-
-- No respondas preguntas sobre el presente desde memoria desactualizada cuando una búsqueda fresca es barata.
-- Separa siempre:
-  - hecho con fuente
-  - evidencia aportada por el usuario
-  - inferencia
-  - recomendación
-- No montes una pasada de investigación pesada si la respuesta ya está en el código o los documentos locales.
-
-## Flujo
-
-### 1. Parte de lo que el usuario ya te dio
-
-Normaliza cualquier material aportado en:
-
-- hechos ya evidenciados
-- puntos que necesitan verificación
-- preguntas abiertas
-
-No reinicies el análisis desde cero si el usuario ya construyó parte del modelo.
-
-### 2. Clasifica la petición
-
-Elige el carril correcto antes de buscar:
-
-- respuesta factual rápida
-- comparación o memo de decisión
-- pasada de enriquecimiento (personas/empresas)
-- candidata a monitorización recurrente
-
-### 3. Planifica las búsquedas antes de lanzarlas
-
-Antes de ejecutar, escribe el plan de búsqueda:
-
-- qué preguntas concretas deben responderse
-- qué consultas cubrirán cada pregunta (varía los términos: nombres alternativos, sinónimos, fechas)
-- qué fuentes serían autoritativas para cada pregunta (documentación oficial, anuncios del proveedor, repositorios, prensa especializada)
-
-Un plan de 3-5 consultas bien dirigidas rinde más que una sola consulta genérica.
-
-### 4. Toma la vía de evidencia más ligera que sea útil
-
-- Usa la búsqueda web nativa para el descubrimiento rápido; abre y lee las fuentes clave en vez de fiarte solo de los resúmenes de resultados.
-- Escala a subagentes de investigación en paralelo cuando importen la síntesis multi-fuente o haya varias líneas de investigación independientes.
-- **Triangula**: para cada afirmación importante, busca al menos dos fuentes independientes. Si dos fuentes se contradicen, di cuál es más autoritativa y por qué; si solo hay una fuente, márcalo.
-- Cuando el resultado deba terminar en una recomendación o decisión clasificada, añade una fase de evaluación explícita: criterios, puntuación de candidatos y trade-offs.
-- Si la verdadera petición es priorizar personas o empresas objetivo, aplica el mismo flujo con criterios de ranking definidos junto al usuario antes de buscar.
-
-### 5. Sintetiza con fronteras de evidencia explícitas
-
-Para las afirmaciones importantes, indica si son:
-
-- hechos con fuente (con la fuente citada)
-- contexto aportado por el usuario
-- inferencia
-- recomendación
-
-Las respuestas sensibles a la frescura deben incluir fechas concretas (fecha de la fuente y fecha de la consulta).
-
-### 6. Decide si la tarea debe seguir siendo manual
-
-Si es probable que el usuario repita la misma pregunta de investigación, dilo explícitamente y recomienda convertirla en un flujo monitorizado o programado en lugar de repetir para siempre la misma búsqueda manual.
-
-## Formato de salida
-
-```text
-TIPO DE PREGUNTA
-- factual / comparación / enriquecimiento / monitorización
-
-EVIDENCIA
-- hechos con fuente (con cita y fecha)
-- contexto aportado por el usuario
-
-INFERENCIA
-- qué se deduce de la evidencia
-
-RECOMENDACIÓN
-- respuesta o siguiente paso
-- si esto debería convertirse en un monitor
-```
-
-## Errores comunes
-
-- No mezcles inferencias con hechos con fuente sin etiquetarlas.
-- No ignores la evidencia aportada por el usuario.
-- No uses un carril de investigación pesado para una pregunta que el contexto local del repo puede responder.
-- No des respuestas sensibles a la frescura sin fechas.
-- No des por buena una afirmación con una sola fuente sin señalarlo.
-
-## Verificación
-
-- Las afirmaciones importantes están etiquetadas por tipo de evidencia.
-- Las afirmaciones clave están trianguladas o marcadas como de fuente única.
-- Las salidas sensibles a la frescura incluyen fechas.
-- La recomendación final coincide con el modo de investigación realmente usado.

package/vendor/theus-arsenal/skills/operaciones-mensajes/SKILL.md

@@ -1,103 +0,0 @@
----
-name: operaciones-mensajes
-description: Flujo de mensajería en vivo basado en evidencia. Úsala cuando el usuario quiera leer textos o DMs, recuperar un código de un solo uso reciente, inspeccionar un hilo antes de responder o probar qué fuente de mensajes se revisó realmente.
----
-
-# Operaciones de mensajes
-
-Usa esta skill cuando la tarea sea recuperación de mensajes en vivo: iMessage, DMs, códigos de un solo uso recientes o inspección de un hilo antes de un seguimiento.
-
-Esto no es trabajo de correo. Si la superficie dominante es un buzón de correo, usa `operaciones-correo`.
-
-## Pila de skills
-
-Incorpora estas skills del arsenal al flujo cuando sean relevantes:
-
-- `operaciones-correo` cuando la tarea de mensajes es en realidad trabajo de buzón
-- `optimizador-conexiones` cuando el hilo de DM pertenece a trabajo de networking saliente
-- `inteligencia-leads` cuando el hilo en vivo debe informar el targeting o un acercamiento por vía cálida
-- `operaciones-conocimiento` cuando el contenido del hilo debe capturarse como contexto duradero
-
-## Cuándo usarla
-
-- El usuario dice "lee mis mensajes", "revisa los textos", "mira los DMs" o "busca el código".
-- La tarea depende de un hilo en vivo o de un código reciente entregado a una superficie de mensajería local.
-- El usuario quiere prueba de qué fuente o hilo se inspeccionó.
-
-## Salvaguardas
-
-- Resuelve primero la fuente:
-  - mensajes locales
-  - DM de X / redes sociales
-  - otra superficie de mensajes protegida por el navegador
-- No afirmes que un hilo fue revisado sin nombrar la fuente.
-- No improvises acceso directo a bases de datos crudas si existe un helper verificado o una ruta estándar.
-- Si la autenticación o el MFA bloquean la superficie, reporta el bloqueo exacto.
-
-## Flujo de trabajo
-
-### 1. Resuelve el hilo exacto
-
-Antes de cualquier otra cosa, define:
-
-- superficie de mensajes
-- remitente / destinatario / servicio
-- ventana de tiempo
-- si la tarea es recuperación, inspección o preparación de una respuesta
-
-### 2. Lee antes de redactar
-
-Si la tarea puede convertirse en un seguimiento saliente:
-
-- lee el último mensaje entrante
-- identifica el asunto pendiente
-- luego delega en la skill de salida correcta si hace falta
-
-### 3. Trata los códigos como recuperación enfocada
-
-Para códigos de un solo uso:
-
-- busca primero en la ventana reciente de mensajes locales
-- acota por servicio o remitente cuando sea posible
-- detente cuando encuentres el código o agotes la búsqueda enfocada
-
-### 4. Reporta evidencia exacta
-
-Devuelve:
-
-- fuente usada
-- hilo o remitente cuando sea posible
-- ventana de tiempo
-- estado exacto:
-  - leído
-  - código encontrado
-  - bloqueado
-  - a la espera de borrador de respuesta
-
-## Formato de salida
-
-```text
-FUENTE
-- superficie de mensajes
-- remitente / hilo / servicio
-
-RESULTADO
-- resumen del mensaje o código
-- ventana de tiempo
-
-ESTADO
-- leído / código encontrado / bloqueado / a la espera de borrador de respuesta
-```
-
-## Errores a evitar
-
-- No mezcles trabajo de buzón de correo con trabajo de DM/textos.
-- No afirmes haber recuperado algo sin nombrar la fuente.
-- No gastes tiempo en búsquedas amplias cuando lo pedido es un código reciente.
-- No reintentes una ruta de autenticación bloqueada sin exponer el bloqueo.
-
-## Verificación
-
-- La respuesta nombra la fuente de mensajes.
-- La respuesta incluye remitente, servicio, hilo o un bloqueo claro.
-- El estado final es explícito y acotado.

package/vendor/theus-arsenal/skills/operaciones-terminal/SKILL.md

@@ -1,110 +0,0 @@
----
-name: operaciones-terminal
-description: >
-  Flujo de ejecución en repositorios basado en evidencia para Theus. Úsala cuando el usuario
-  quiera ejecutar un comando, revisar un repo, depurar un fallo de CI o empujar un fix acotado
-  con prueba exacta de qué se ejecutó y qué se verificó.
----
-
-# Operaciones de terminal
-
-Úsala cuando el usuario quiera ejecución real sobre el repo: correr comandos, inspeccionar el estado de git, depurar CI o builds, hacer un fix acotado y reportar exactamente qué cambió y qué se verificó.
-
-Esta skill es deliberadamente más estrecha que una guía general de programación. Es un flujo de operador para ejecución en terminal basada en evidencia.
-
-## Pila de skills
-
-Incorpora estas skills nativas de Theus al flujo cuando sean relevantes:
-
-- `bucle-verificacion` para los pasos exactos de prueba después de los cambios
-- `flujo-tdd` cuando el fix correcto necesita cobertura de regresión
-- `revision-seguridad` cuando hay secretos, autenticación o entradas externas involucradas
-- `operaciones-github` cuando la tarea depende de ejecuciones de CI, del estado de un PR o del estado de un release
-
-## Cuándo usarla
-
-- el usuario dice "arregla", "depura", "ejecuta esto", "revisa el repo" o "haz push"
-- la tarea depende de la salida de un comando, del estado de git, de resultados de tests o de un fix local verificado
-- la respuesta debe distinguir entre cambiado localmente, verificado localmente, commiteado y pusheado
-
-## Barandillas
-
-- inspecciona antes de editar
-- mantente en solo lectura si el usuario pidió únicamente auditoría/revisión
-- prefiere scripts y utilidades locales del repo antes que wrappers improvisados
-- no afirmes "arreglado" hasta haber vuelto a ejecutar el comando de prueba
-- no afirmes "pusheado" salvo que la rama realmente haya avanzado en el remoto
-
-## Flujo de trabajo
-
-### 1. Resuelve la superficie de trabajo
-
-Determina:
-
-- ruta exacta del repo
-- rama (branch)
-- estado del diff local
-- modo solicitado:
-  - inspeccionar
-  - arreglar
-  - verificar
-  - hacer push
-
-### 2. Lee primero la superficie que falla
-
-Antes de cambiar nada:
-
-- inspecciona el error
-- inspecciona el archivo o el test
-- inspecciona el estado de git
-- usa los logs o el contexto ya proporcionados antes de releer a ciegas
-
-### 3. Mantén el fix acotado
-
-Resuelve un fallo dominante a la vez:
-
-- usa primero el comando de prueba más pequeño que sea útil
-- solo escala a una pasada mayor de build/tests después de resolver el fallo local
-- si un comando sigue fallando con la misma firma, detén los reintentos amplios y estrecha el alcance
-
-### 4. Reporta el estado exacto de ejecución
-
-Usa palabras de estado exactas:
-
-- inspeccionado
-- cambiado localmente
-- verificado localmente
-- commiteado
-- pusheado
-- bloqueado
-
-## Formato de salida
-
-```text
-SUPERFICIE
-- repo
-- rama
-- modo solicitado
-
-EVIDENCIA
-- comando que falla / diff / test
-
-ACCIÓN
-- qué cambió
-
-ESTADO
-- inspeccionado / cambiado localmente / verificado localmente / commiteado / pusheado / bloqueado
-```
-
-## Errores comunes
-
-- no trabajes desde memoria desactualizada cuando puedes leer el estado vivo del repo
-- no amplíes un fix acotado hasta convertirlo en cambios masivos por todo el repo
-- no uses comandos destructivos de git
-- no ignores trabajo local no relacionado
-
-## Verificación
-
-- la respuesta nombra el comando o test de prueba
-- el trabajo relacionado con git nombra la ruta del repo y la rama
-- toda afirmación de push incluye la rama de destino y el resultado exacto

package/vendor/theus-arsenal/skills/optimizacion-benchmark/SKILL.md

@@ -1,70 +0,0 @@
----
-name: optimizacion-benchmark
-description: Úsala cuando el usuario pida hacer algo más rápido, probar muchas variantes, ejecutar una optimización recursiva, medir latencia/throughput/costo con benchmarks, o elegir la mejor implementación mediante pruebas medidas repetidas.
-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# Bucle de optimización por benchmark
-
-Usa esta skill para convertir un "hazlo 20x más rápido" o un "prueba 50
-optimizaciones recursivas" en un bucle acotado y medido que realmente pueda
-mejorar un sistema.
-
-## Línea base obligatoria
-
-No optimices hasta que existan:
-
-- la operación que se va a optimizar;
-- la puerta de correctitud que debe mantenerse en verde;
-- la métrica: tiempo de reloj, latencia p95, filas/seg, costo por ejecución, memoria, tasa de errores;
-- la línea base actual;
-- el presupuesto de búsqueda: máximo de variantes, tiempo máximo, gasto máximo, impacto máximo en los datos.
-
-Si el usuario pide un objetivo poco realista, conserva la ambición pero haz que
-el bucle sea acotado y medible.
-
-## Bucle
-
-1. Mide la línea base.
-2. Identifica los cuellos de botella a partir de evidencia.
-3. Genera variantes que prueben una sola hipótesis cada una.
-4. Ejecuta las variantes con la misma forma de entrada.
-5. Rechaza las variantes que fallen en correctitud, seguridad o reproducibilidad.
-6. Promueve la variante segura más rápida.
-7. Codifica el camino ganador en un script, comando, test, configuración o documento.
-8. Vuelve a ejecutar la línea base y la ganadora para confirmar el delta.
-
-## Tabla de variantes
-
-Registra las variantes así:
-
-```text
-Variante | Hipótesis | Comando | Tiempo | ¿Correcta? | Notas
-baseline | camino actual | npm run job | 120s | sí | estable
-batch-500 | menos viajes de ida y vuelta | npm run job -- --batch 500 | 42s | sí | ganadora
-parallel-8 | más workers | npm run job -- --workers 8 | 31s | no | limitada por rate limit
-```
-
-## Búsqueda recursiva
-
-Para trabajo recursivo o de hiperparámetros:
-
-- persiste cada ejecución en un registro (ledger);
-- compara contra la última ganadora aceptada, no solo contra la ejecución anterior;
-- mantén una verificación de holdout o de replay;
-- detente cuando la mejora quede dentro del ruido, la correctitud falle, el costo
-  exceda el presupuesto, o la búsqueda empiece a cambiar más variables de las que
-  puede explicar.
-
-Usa expresiones como "la mejor variante segura medida" en lugar de "óptimo
-global", salvo que el espacio de búsqueda haya sido realmente exhaustivo.
-
-## Puerta de promoción
-
-Una variante no puede convertirse en el nuevo valor por defecto hasta que:
-
-- los tests de correctitud pasen;
-- el delta de rendimiento se haya repetido o esté explicado;
-- el rollback sea obvio;
-- el cambio quede registrado en control de versiones o en un runbook duradero;
-- el resumen final incluya los comandos y las mediciones exactas.