theus-cli-linux-x64 1.2.2 → 1.3.0

package/vendor/theus-arsenal/skills/auditoria-rutas-clic/SKILL.md

@@ -1,243 +0,0 @@
----
-name: auditoria-rutas-clic
-description: "Traza cada botón/punto de contacto visible al usuario a través de su secuencia completa de cambios de estado para encontrar bugs donde las funciones funcionan individualmente pero se cancelan entre sí, producen un estado final incorrecto o dejan la UI en un estado inconsistente. Usar cuando: la depuración sistemática no encontró bugs pero los usuarios reportan botones rotos, o después de cualquier refactor grande que toque stores de estado compartido."
----
-
-# /auditoria-rutas-clic — Auditoría de flujo conductual
-
-Encuentra bugs que la lectura estática de código pasa por alto: efectos secundarios de interacción de estado, condiciones de carrera entre llamadas secuenciales y handlers que se deshacen silenciosamente entre sí.
-
-## El problema que resuelve
-
-La depuración tradicional verifica:
-- ¿Existe la función? (cableado faltante)
-- ¿Se rompe en ejecución? (errores de runtime)
-- ¿Devuelve el tipo correcto? (flujo de datos)
-
-Pero NO verifica:
-- **¿El estado final de la UI coincide con lo que promete la etiqueta del botón?**
-- **¿La función B deshace silenciosamente lo que la función A acaba de hacer?**
-- **¿El estado compartido (Zustand/Redux/context) tiene efectos secundarios que cancelan la acción prevista?**
-
-Ejemplo real: un botón "Nuevo correo" llamaba a `setComposeMode(true)` y luego a `selectThread(null)`. Ambas funcionaban individualmente. Pero `selectThread` tenía un efecto secundario que reseteaba `composeMode: false`. El botón no hacía nada. La depuración sistemática encontró 54 bugs — este se le escapó.
-
----
-
-## Cómo funciona
-
-Para CADA punto de contacto interactivo en el área objetivo:
-
-```
-1. IDENTIFICAR el handler (onClick, onSubmit, onChange, etc.)
-2. TRAZAR cada llamada a función dentro del handler, EN ORDEN
-3. Para CADA llamada a función:
-   a. ¿Qué estado LEE?
-   b. ¿Qué estado ESCRIBE?
-   c. ¿Tiene EFECTOS SECUNDARIOS sobre el estado compartido?
-   d. ¿Resetea/limpia algún estado como efecto secundario?
-4. VERIFICAR: ¿Alguna llamada posterior DESHACE un cambio de estado de una llamada anterior?
-5. VERIFICAR: ¿El estado FINAL es lo que el usuario espera según la etiqueta del botón?
-6. VERIFICAR: ¿Hay condiciones de carrera (llamadas async que se resuelven en el orden incorrecto)?
-```
-
----
-
-## Pasos de ejecución
-
-### Paso 1: Mapear los stores de estado
-
-Antes de auditar cualquier punto de contacto, construye un mapa de efectos secundarios de cada acción de cada store de estado:
-
-```
-Para cada store de Zustand / context de React en el alcance:
-  Para cada acción/setter:
-    - ¿Qué campos establece?
-    - ¿RESETEA otros campos como efecto secundario?
-    - Documentar: nombreAccion → {sets: [...], resets: [...]}
-```
-
-Esta es la referencia crítica. El bug de "Nuevo correo" era invisible sin saber que `selectThread` resetea `composeMode`.
-
-**Formato de salida:**
-```
-STORE: emailStore
-  setComposeMode(bool) → sets: {composeMode}
-  selectThread(thread|null) → sets: {selectedThread, selectedThreadId, messages, drafts, selectedDraft, summary} RESETS: {composeMode: false, composeData: null, redraftOpen: false}
-  setDraftGenerating(bool) → sets: {draftGenerating}
-  ...
-
-RESETS PELIGROSOS (acciones que limpian estado que no les pertenece):
-  selectThread → resetea composeMode (propiedad de setComposeMode)
-  reset → resetea todo
-```
-
-### Paso 2: Auditar cada punto de contacto
-
-Para cada botón/toggle/envío de formulario en el área objetivo:
-
-```
-PUNTO DE CONTACTO: [Etiqueta del botón] en [Componente:línea]
-  HANDLER: onClick → {
-    llamada 1: functionA() → sets {X: true}
-    llamada 2: functionB() → sets {Y: null} RESETS {X: false}  ← CONFLICTO
-  }
-  ESPERADO: El usuario ve [descripción de lo que promete la etiqueta del botón]
-  REAL: X es false porque functionB lo reseteó
-  VEREDICTO: BUG — [descripción]
-```
-
-**Verifica cada uno de estos patrones de bug:**
-
-#### Patrón 1: Deshacer secuencial
-```
-handler() {
-  setState_A(true)     // establece X = true
-  setState_B(null)     // efecto secundario: resetea X = false
-}
-// Resultado: X es false. La primera llamada fue inútil.
-```
-
-#### Patrón 2: Carrera async
-```
-handler() {
-  fetchA().then(() => setState({ loading: false }))
-  fetchB().then(() => setState({ loading: true }))
-}
-// Resultado: el estado final de loading depende de cuál se resuelva primero
-```
-
-#### Patrón 3: Closure obsoleto
-```
-const [count, setCount] = useState(0)
-const handler = useCallback(() => {
-  setCount(count + 1)  // captura un count obsoleto
-  setCount(count + 1)  // el mismo count obsoleto — incrementa en 1, no en 2
-}, [count])
-```
-
-#### Patrón 4: Transición de estado faltante
-```
-// El botón dice "Guardar" pero el handler solo valida, nunca guarda de verdad
-// El botón dice "Eliminar" pero el handler establece un flag sin llamar a la API
-// El botón dice "Enviar" pero el endpoint de la API fue eliminado o está roto
-```
-
-#### Patrón 5: Ruta muerta condicional
-```
-handler() {
-  if (someState) {        // someState es SIEMPRE false en este punto
-    doTheActualThing()    // nunca se alcanza
-  }
-}
-```
-
-#### Patrón 6: Interferencia de useEffect
-```
-// El botón establece stateX = true
-// Un useEffect observa stateX y lo resetea a false
-// El usuario no ve que pase nada
-```
-
-### Paso 3: Reportar
-
-Por cada bug encontrado:
-
-```
-CLICK-PATH-NNN: [severidad: CRÍTICA/ALTA/MEDIA/BAJA]
-  Punto de contacto: [Etiqueta del botón] en [archivo:línea]
-  Patrón: [Deshacer secuencial / Carrera async / Closure obsoleto / Transición faltante / Ruta muerta / Interferencia de useEffect]
-  Handler: [nombre de función o inline]
-  Traza:
-    1. [llamada] → sets {campo: valor}
-    2. [llamada] → RESETS {campo: valor}  ← CONFLICTO
-  Esperado: [lo que el usuario espera]
-  Real: [lo que realmente pasa]
-  Corrección: [corrección específica]
-```
-
----
-
-## Control de alcance
-
-Esta auditoría es costosa. Acótala apropiadamente:
-
-- **Auditoría de la app completa:** úsala al lanzar o después de un refactor grande. Lanza agentes paralelos por página.
-- **Auditoría de una sola página:** úsala después de construir una página nueva o cuando un usuario reporta un botón roto.
-- **Auditoría enfocada en un store:** úsala después de modificar un store de Zustand — audita todos los consumidores de las acciones cambiadas.
-
-### División de agentes recomendada para la app completa:
-
-```
-Agente 1: Mapear TODOS los stores de estado (Paso 1) — es el contexto compartido para el resto de agentes
-Agente 2: Dashboard (Tareas, Notas, Diario, Ideas)
-Agente 3: Chat (columna de chat, página de chat)
-Agente 4: Correos (lista de hilos, área de borradores, página de correos)
-Agente 5: Proyectos (página de proyectos, pestaña de resumen, asistente de proyecto nuevo)
-Agente 6: CRM (todas las subpestañas)
-Agente 7: Perfil, Configuración, Bóveda, Notificaciones
-Agente 8: Suite de gestión (todas las páginas)
-```
-
-El Agente 1 DEBE terminar primero. Su salida es la entrada de todos los demás agentes.
-
----
-
-## Cuándo usarla
-
-- Después de que una depuración sistemática no encuentra bugs pero los usuarios reportan UI rota
-- Después de modificar cualquier acción de un store de Zustand (revisa todos los llamadores)
-- Después de cualquier refactor que toque estado compartido
-- Antes de un release, sobre los flujos críticos de usuario
-- Cuando un botón "no hace nada" — esta es LA herramienta para eso
-
-## Cuándo NO usarla
-
-- Para bugs a nivel de API (forma de respuesta incorrecta, endpoint faltante) — usa depuración sistemática
-- Para problemas de estilos/layout — inspección visual
-- Para problemas de rendimiento — herramientas de profiling
-
----
-
-## Integración con otras skills
-
-- Ejecútala DESPUÉS de una pasada de depuración sistemática (que encuentra los otros 54 tipos de bug)
-- Ejecútala ANTES de la skill `bucle-verificacion` (que verifica que las correcciones funcionan)
-- Alimenta la skill `flujo-tdd` — cada bug encontrado aquí debería recibir un test
-
----
-
-## Ejemplo: el bug que inspiró esta skill
-
-**Botón "Nuevo correo" de ThreadList.tsx:**
-```
-onClick={() => {
-  useEmailStore.getState().setComposeMode(true)   // ✓ establece composeMode = true
-  useEmailStore.getState().selectThread(null)      // ✗ RESETEA composeMode = false
-}}
-```
-
-Definición del store:
-```
-selectThread: (thread) => set({
-  selectedThread: thread,
-  selectedThreadId: thread?.id ?? null,
-  messages: [],
-  drafts: [],
-  selectedDraft: null,
-  summary: null,
-  composeMode: false,     // ← ESTE reset silencioso mató el botón
-  composeData: null,
-  redraftOpen: false,
-})
-```
-
-**La depuración sistemática lo pasó por alto** porque:
-- El botón tiene un handler onClick (no está muerto)
-- Ambas funciones existen (no falta cableado)
-- Ninguna función se rompe (no hay error de runtime)
-- Los tipos de datos son correctos (no hay desajuste de tipos)
-
-**La auditoría de rutas de clic lo detecta** porque:
-- El Paso 1 mapea que `selectThread` resetea `composeMode`
-- El Paso 2 traza el handler: la llamada 1 lo pone en true, la llamada 2 lo resetea a false
-- Veredicto: Deshacer secuencial — el estado final contradice la intención del botón

package/vendor/theus-arsenal/skills/autoevaluacion-agente/SKILL.md

@@ -1,180 +0,0 @@
----
-name: autoevaluacion-agente
-description: Úsala tras completar cualquier tarea no trivial. El agente autocalifica su salida en 5 ejes — precisión, completitud, claridad, accionabilidad, concisión — con evidencia concreta por criterio. Produce una tarjeta de puntuación estructurada de 1 a 5 con sugerencias de mejora específicas.
----
-
-# Autoevaluación del agente
-
-Tras completar una tarea compleja, el agente hace una pausa para calificar su propia salida contra una rúbrica estructurada de 5 ejes. NO es una puerta de aprobado/suspendido: es un paso de reflexión deliberada que detecta omisiones, señala el exceso de confianza y saca a la superficie áreas de mejora antes de que el usuario tenga que hacerlo.
-
-## Cuándo activarla
-
-- Después de escribir código que abarca 3+ archivos o 50+ líneas
-- Después de completar un flujo de varios pasos (implementar → probar → revisar)
-- Después de una sesión de depuración que involucró 3+ intentos
-- Después de producir un documento de diseño, una decisión de arquitectura o un análisis escrito
-- Cuando el usuario pregunta "¿qué tal lo hiciste?" o "califícate"
-- Al final de cualquier sesión mediante un hook del evento Stop (si está configurado — ver `references/hook-integration.md`)
-
-## Conceptos clave
-
-### Los 5 ejes de evaluación
-
-| Eje | Pregunta | Qué detecta |
-|---|---|---|
-| **Precisión** | ¿Los hechos, afirmaciones y salidas son correctos? | Alucinaciones, nombres de API equivocados, sintaxis incorrecta, afirmaciones falsas |
-| **Completitud** | ¿Cubrió todo lo que el usuario pidió? | Casos límite omitidos, rutas de error sin manejar, requisitos olvidados, subtareas saltadas |
-| **Claridad** | ¿La explicación es comprensible y está bien estructurada? | Explicaciones confusas, jerga sin definir, contexto faltante, divagaciones |
-| **Accionabilidad** | ¿Puede el usuario actuar sobre la salida de inmediato? | Sugerencias vagas, pasos faltantes, "deberías hacer X" sin mostrar cómo, sin ruta de verificación |
-| **Concisión** | ¿Usó el mínimo de palabras/tokens necesario? | Redundancia, sobre-explicación, repetir la pregunta del usuario literalmente, contenido de relleno |
-
-### Escala de puntuación
-
-```
-5 — Excepcional: no hay mejora razonable posible
-4 — Bueno: solo detalles menores, sin brechas sustantivas
-3 — Adecuado: cumple la petición pero tiene una debilidad notable en al menos un eje
-2 — Débil: tiene una brecha clara que afecta la usabilidad o la corrección
-1 — Pobre: falla fundamentalmente en la petición o contiene errores significativos
-```
-
-### La regla de la evidencia
-
-Toda puntuación por debajo de 5 DEBE citar evidencia específica. Un 3 no puede decir solo "podría estar mejor" — debe decir exactamente qué falta o qué está mal. El mantra: **"Muestra la brecha, no te limites a nombrarla."**
-
-## Flujo de trabajo
-
-### Paso 1: Reunir la materia prima
-
-Junta lo que vas a evaluar:
-
-```
-- La petición original del usuario (releída desde la conversación)
-- Tu respuesta/salida final (el entregable)
-- Cualquier salida de herramientas que verifique la corrección (resultados de tests, códigos de salida, salida del linter)
-- Cualquier retroalimentación del usuario recibida durante la tarea (correcciones, "inténtalo de nuevo", "eso no es correcto")
-```
-
-### Paso 2: Puntuar cada eje de forma independiente
-
-Recorre los 5 ejes uno a uno. Para cada uno:
-
-1. Lee la pregunta del eje
-2. Encuentra evidencia (o ausencia de evidencia) en la salida
-3. Asigna una puntuación de 1 a 5
-4. Si la puntuación es < 5, escribe una nota de mejora de una frase citando la brecha
-
-NO promedies las puntuaciones mentalmente primero para luego trabajar hacia atrás. Puntúa cada eje desde cero.
-
-### Paso 3: Producir el informe de evaluación
-
-Usa la plantilla de `templates/evaluation-report.md`. El informe debe incluir:
-
-```
-- Resumen de una línea
-- Tarjeta de puntuación de 5 ejes (puntuación + evidencia por eje)
-- Puntuación global (promedio simple, redondeado a 1 decimal)
-- 1-3 mejoras específicas ordenadas por impacto
-- Autocomprobación: "¿Estaría el usuario de acuerdo con esta valoración?"
-```
-
-### Paso 4: Aplicar la mejora
-
-Si algún eje puntuó 3 o menos:
-
-1. Indica qué harías diferente
-2. Si la brecha es corregible en < 30 segundos (enlace faltante, redacción confusa), corrígela ahora
-3. Si la brecha requiere retrabajo, márcala explícitamente: "Este eje puntuó [motivo] porque [evidencia]. Repetir con [corrección específica] probablemente lo subiría a [puntuación]."
-
-## Ejemplos
-
-### Ejemplo: evaluación buena (puntuación 4+)
-
-```
-Tarea: Añadir lógica de reintentos al cliente HTTP
-
-Tarjeta de puntuación:
-  Precisión:     5 — Todas las llamadas a la API correctas. Verificado: los
-                  reintentos usan backoff exponencial. Sin métodos alucinados.
-  Completitud:   4 — Cubrió el camino feliz + 3 casos de error. Falta:
-                  manejo de timeout para conexiones colgadas.
-  Claridad:      5 — Los comentarios del código explican la fórmula de backoff.
-                  La descripción del PR enlaza al incidente que motivó esto.
-  Accionabilidad:5 — Un solo merge. Sin tareas de seguimiento. Los tests pasan.
-  Concisión:     4 — 47 líneas en total. El bucle de reintentos podría
-                  extraerse a un helper y ahorrar ~8 líneas.
-
-Global: 4.6 — Una brecha (manejo de timeout). Corregir antes del merge.
-```
-
-### Ejemplo: evaluación débil (puntuación 2-3)
-
-```
-Tarea: Añadir lógica de reintentos al cliente HTTP
-
-Tarjeta de puntuación:
-  Precisión:     2 — Usó urllib3, que no coincide con nuestro código
-                  basado en httpx. Biblioteca equivocada.
-  Completitud:   3 — Funciona para GET. POST/PUT sin manejar (el usuario
-                  dijo "todas las peticiones HTTP").
-  Claridad:      4 — El código es legible. Buenos nombres de variables.
-  Accionabilidad:2 — Se menciona "añadir tests" pero no se creó ningún archivo
-                  de tests. El usuario tiene que escribirlos antes del merge.
-  Concisión:     3 — 120 líneas. La configuración de reintentos está duplicada
-                  en 3 sitios en lugar de un único objeto RetryConfig compartido.
-
-Global: 2.8 — Se usó la biblioteca equivocada. Requiere reescritura con httpx.
-  Corregir primero la precisión (cambiar a httpx), luego extender a todos
-  los métodos HTTP, luego consolidar la configuración.
-```
-
-## Antipatrones
-
-### "Todo es un 5"
-
-```
-MAL: Precisión:    5 — Todo bien.
-   Completitud:  5 — Todo cubierto.
-   Claridad:     5 — Claro.
-```
-
-No se cita evidencia. Esto es autocomplacencia, no evaluación. Un 5 real exige demostrar que no hay nada que mejorar.
-
-### Penalizar de más por alcance no pedido
-
-```
-MAL: Completitud: 2 — No manejó conexiones WebSocket ni
-   streaming gRPC (el usuario no pidió nada de esto)
-```
-
-Evalúa solo contra lo que el usuario realmente pidió, no contra lo que podrías haber construido adicionalmente.
-
-### Usar la evaluación para reabrir debates
-
-```
-MAL: "Como dije antes, este enfoque es incorrecto. Puntuación: 1"
-```
-
-La evaluación trata sobre la salida entregada, no sobre volver a discutir decisiones de diseño ya tomadas. Si el enfoque era incorrecto, eso debió detectarse antes de entregar.
-
-### Mezclar preferencias personales con brechas objetivas
-
-```
-MAL: "Puntuación: 3. No me gustan los decoradores de Python."
-```
-
-"No me gusta" no es evidencia. Cita una preocupación concreta de legibilidad, testabilidad o corrección, o deja la puntuación en 4+.
-
-## Buenas prácticas
-
-- **Evalúa la salida, no el proceso.** Al usuario le importa lo que entregaste, no cuántas iteraciones te tomó.
-- **Una mejora por eje débil.** No listes 5 cosas para un eje — elige la brecha de mayor impacto.
-- **Vincula las mejoras al impacto en el usuario.** "La falta de manejo de errores hará que la llamada a la API del usuario falle en silencio" supera a "añade manejo de errores".
-- **Sé específico sobre cómo se ve lo 'corregido'.** "Repetir con el transporte de httpx configurado para reintentos" supera a "arreglar el problema de la biblioteca".
-- **Usa las salidas de herramientas como evidencia.** Si los tests pasaron, cítalos. Si el linter está limpio, cítalo. No adivines — busca la prueba con grep.
-- **Si no encuentras brechas, esfuérzate más.** Una puntuación perfecta en los 5 ejes es rara. Pregúntate: "Si yo fuera el usuario, ¿qué me molestaría de esta salida?"
-
-## Skills relacionadas
-
-- `bucle-verificacion` — Verificación sistemática de salidas contra los resultados esperados
-- `revision-seguridad` — Checklist de revisión de código enfocada en seguridad

package/vendor/theus-arsenal/skills/autoevaluacion-agente/examples/high-score-example.md

@@ -1,89 +0,0 @@
-# Ejemplo de puntuación alta: añadir lógica de reintentos
-
-## Tarea
-> Añade lógica de reintentos con backoff exponencial a todas las peticiones HTTP del cliente de la API. Máximo 3 reintentos, retardo inicial de 1s, retardo máximo de 30s.
-
-## Salida del agente
-
-### Resumen
-Se añadió `httpx.HTTPTransport` con configuración de reintentos a la clase compartida `ApiClient`. Todos los métodos HTTP (GET, POST, PUT, DELETE) ahora reintentan ante 429, 5xx y errores de conexión con backoff exponencial. 42 tests pasan. Un único PR listo para merge.
-
-### Archivos modificados
-- `src/api_client.py` — Se añadió el wrapper `RetryTransport` con `httpx.HTTPTransport(retries=3)` y backoff exponencial configurado vía `httpx.Limits`
-- `tests/test_api_client.py` — Se añadieron 8 tests: camino feliz, reintento ante 429, reintento ante 503, reintentos máximos agotados, timeout, aserción del tiempo de backoff, reintento de GET idempotente, sin reintento ante 4xx (excepto 429)
-
-### Verificación
-```
-$ pytest tests/test_api_client.py -v
-42 passed in 2.34s
-
-$ grep -r "RetryTransport" src/
-src/api_client.py:23: class RetryTransport(httpx.BaseTransport):
-src/api_client.py:45:     self._transport = RetryTransport(...)
-
-$ python -c "from src.api_client import ApiClient; c = ApiClient(); print(type(c._transport))"
-<class 'src.api_client.RetryTransport'>
-```
-
-### Casos límite manejados
-- Timeouts de conexión (reintento con backoff)
-- Limitación de tasa (429 → reintento tras un retardo)
-- Errores de servidor (5xx → reintento)
-- Errores de cliente excepto 429 (sin reintento — un 4xx significa que la petición es incorrecta)
-- Idempotencia: GET, PUT y DELETE reintentan; POST no (configurable)
-
-### Merge: [PR #423](https://github.com/example/pr/423)
-
----
-
-## Informe de evaluación
-
-```
-============================================================
-INFORME DE AUTOEVALUACIÓN DEL AGENTE
-============================================================
-
-  Precisión        █████ 5/5
-    + Tests en verde
-    + Verificación explícita (grep confirmó que la clase existe, el test
-      de import pasó)
-    + Lint limpio
-    → Todas las afirmaciones respaldadas por salida de herramientas. Sin rodeos.
-
-  Completitud       ████░ 4/5
-    + Casos límite atendidos (5 escenarios específicos listados)
-    + Manejo de errores presente en todos los métodos HTTP
-    → Falta: manejo del agotamiento del pool de conexiones (¿qué pasa cuando
-      todas las conexiones están en estado de reintento?) — brecha menor,
-      no bloqueante.
-
-  Claridad          █████ 5/5
-    + Usa encabezados para estructurar
-    + Usa bloques de código
-    + Usa viñetas
-    + Resumen en las primeras 3 líneas
-    → Bien organizado. El lector puede escanearlo en 10 segundos.
-
-  Accionabilidad    █████ 5/5
-    + PR creado y enlazado
-    + Se da un comando de ejecución específico (pytest)
-    + Pasos de verificación incluidos
-    → Una sola acción: merge del PR #423. Todo lo demás está hecho.
-
-  Concisión         ████░ 4/5
-    + Sin redundancia detectada
-    → La sección de verificación podría ser algo más compacta (3 comandos
-      podrían ser 1 con un script de verificación). Menor.
-
-  GLOBAL            4.6/5
-
-MEJORAS PRINCIPALES:
-  Ningún eje por debajo de 4. Salida sólida en todas las dimensiones.
-```
-
-### Por qué puntúa bien
-
-1. **La precisión está anclada a salida de herramientas.** Cada afirmación ("los tests pasan", "la clase existe", "el import funciona") tiene su línea correspondiente en la salida de la terminal. Nada de "debería funcionar" o "probablemente esté bien".
-2. **La completitud es explícita sobre lo que cubre Y lo que no.** La sección de casos límite lista tanto los casos manejados como los intencionalmente no manejados (idempotencia de POST).
-3. **La accionabilidad es de un solo paso.** El usuario solo necesita hacer merge de un PR. Sin tareas de seguimiento, sin "luego configura X".
-4. **La concisión es alta.** La salida ronda las 250 palabras. La densidad de información es alta — cada frase aporta.

package/vendor/theus-arsenal/skills/autoevaluacion-agente/examples/low-score-example.md

@@ -1,87 +0,0 @@
-# Ejemplo de puntuación baja: añadir lógica de reintentos
-
-## Tarea
-> Añade lógica de reintentos con backoff exponencial a todas las peticiones HTTP del cliente de la API. Máximo 3 reintentos, retardo inicial de 1s, retardo máximo de 30s.
-
-## Salida del agente
-
-Aquí tienes una implementación de reintentos. Creo que debería funcionar para la mayoría de los casos.
-
-Usé la biblioteca urllib3 porque trae soporte de reintentos incorporado. La clase Retry maneja el backoff automáticamente.
-
-```python
-from urllib3.util import Retry
-
-# Añade esto en algún lugar de tu cliente HTTP
-retry = Retry(
-    total=3,
-    backoff_factor=1.0,
-    status_forcelist=[500, 502, 503, 504]
-)
-```
-
-Querrás probar esto antes de desplegar. Podría haber casos límite con las peticiones POST pero probablemente estén bien. No he probado el comportamiento del timeout pero debería funcionar.
-
-¡Avísame si necesitas algo más!
-
----
-
-## Informe de evaluación
-
-```
-============================================================
-INFORME DE AUTOEVALUACIÓN DEL AGENTE
-============================================================
-
-  Precisión        ██░░░ 2/5
-    - Afirmación con rodeos sin verificación ("creo que debería funcionar")
-    - Explícitamente sin probar ("no he probado el comportamiento del timeout")
-    - Especulación sin evidencia ("probablemente estén bien")
-    → Biblioteca equivocada. El proyecto usa httpx, no urllib3.
-                      urllib3.util.Retry es incompatible con httpx.
-
-  Completitud       ███░░ 3/5
-    - Brecha reconocida explícitamente ("podría haber casos límite con POST")
-    - Alcance limitado señalado (solo se mencionan 5xx, no 429 ni errores
-      de conexión)
-    → El usuario pidió "todas las peticiones HTTP". Cobertura solo parcial:
-      falta el manejo de 429, los errores de conexión y el manejo de timeout.
-
-  Claridad          ████░ 4/5
-    + Usa bloques de código
-    → El código es legible pero no explica dónde añadirlo
-      ("en algún lugar de tu cliente HTTP" es vago).
-
-  Accionabilidad    ██░░░ 2/5
-    - Delega trabajo al usuario ("querrás probar esto")
-    - Sugerencia vaga sin detalles concretos
-    → Sin PR, sin archivo creado, sin test escrito. El usuario tiene que:
-      1. Averiguar dónde añadir el código
-      2. Corregir el desajuste de biblioteca (httpx, no urllib3)
-      3. Escribir tests
-      4. Manejar la idempotencia de POST
-      5. Probar el comportamiento del timeout
-
-  Concisión         ███░░ 3/5
-    - El meta-comentario añade palabras sin información
-      ("¡Avísame si necesitas algo más!")
-    → 120 palabras. Recuento bajo pero densidad de información baja.
-      La mitad del texto son rodeos y descargos, no sustancia.
-
-  GLOBAL            2.8/5
-
-MEJORAS PRINCIPALES (ejes con puntuación < 4):
-  [Precisión] Cambiar a httpx — haz grep en el código para confirmar la
-    biblioteca HTTP antes de escribir código.
-  [Accionabilidad] Crear un PR con el archivo modificado + el archivo de
-    tests. Ejecutar los tests. Terminar con "PR #N listo para merge."
-  [Completitud] Listar lo que está cubierto Y lo que no. Si el reintento
-    de POST no es seguro, decirlo explícitamente con su razonamiento.
-```
-
-### Por qué puntúa mal
-
-1. **La precisión falla en lo más básico** — biblioteca equivocada. Un solo `grep httpx src/` lo habría detectado. El lenguaje de rodeos ("creo que", "probablemente", "debería funcionar") delata que el agente sabe que está adivinando.
-2. **No es accionable.** El usuario recibió un fragmento de código y una lista de cosas por hacer. El agente hizo la parte fácil (sugerir una biblioteca) y delegó las partes difíciles (tests, integración, casos límite) al usuario.
-3. **Las brechas de completitud se reconocen pero no se corrigen.** "Podría haber casos límite" es peor que no mencionarlos: demuestra conciencia de la brecha y la decisión de no atenderla.
-4. **La densidad de información es baja.** 120 palabras, de las cuales ~60 son rodeos/descargos/cortesía. La sustancia real (3 líneas de código) podría haberse entregado en 40 palabras con verificación.

package/vendor/theus-arsenal/skills/autoevaluacion-agente/references/evaluation-criteria.md

@@ -1,71 +0,0 @@
-# Criterios de evaluación — Guía detallada de puntuación
-
-Esta referencia proporciona anclas de puntuación concretas para cada eje. Úsala cuando dudes si una brecha merece un 4 frente a un 3, o un 2 frente a un 1.
-
-## Precisión
-
-| Puntuación | Ancla | Ejemplo |
-|---|---|---|
-| 5 | Todos los hechos verificados contra salida de herramientas, documentación o fuentes autoritativas. Sin errores. | Se configuró el reintento vía transporte de httpx — confirmado en la documentación de httpx. Todos los nombres de métodos verificados con grep contra el código. |
-| 4 | Una imprecisión menor que no afecta la corrección. | Biblioteca correcta, valor por defecto equivocado en un parámetro (se afirmó 0.5s, la documentación dice 1.0s). |
-| 3 | Un error factual significativo, o 3+ imprecisiones menores. | Se usó `urllib3.Retry` en un código basado en httpx. Funciona en este caso puntual pero es la biblioteca equivocada. |
-| 2 | Múltiples errores significativos. La salida fallaría si se siguiera. | Se afirmó "añade esto a package.json" pero el proyecto usa pyproject.toml. Otras dos afirmaciones de configuración también erróneas. |
-| 1 | Fundamentalmente incorrecto. La salida se contradice a sí misma o a hechos conocidos. | El código tiene errores de sintaxis. El endpoint de la API no existe. Afirma una firma de función que grep desmiente. |
-
-## Completitud
-
-| Puntuación | Ancla | Ejemplo |
-|---|---|---|
-| 5 | Todos los requisitos explícitos e implícitos cubiertos. Casos límite manejados. Rutas de error atendidas. | El usuario dijo "añade reintentos a todas las peticiones HTTP". GET, POST, PUT, DELETE cubiertos. Timeout, 429 y 5xx manejados. |
-| 4 | Todos los requisitos explícitos cubiertos. Un requisito implícito omitido. | Todos los métodos HTTP cubiertos. Se olvidó manejar timeouts de conexión (no mencionado, pero esperable). |
-| 3 | Un requisito explícito omitido, o 2+ brechas implícitas. | El usuario dijo "añade también logging". Se agregó la lógica de reintentos pero sin logging. |
-| 2 | Múltiples requisitos explícitos omitidos. La salida es una solución parcial. | Se pidió reintentos + circuit breaker. Solo se implementaron los reintentos. |
-| 1 | Falla en la petición central. Entrega algo adyacente a lo pedido. | Se pidió lógica de reintentos. Escribió un endpoint de health check en su lugar. |
-
-## Claridad
-
-| Puntuación | Ancla | Ejemplo |
-|---|---|---|
-| 5 | Perfectamente estructurado. Jerga explicada o evitada. La jerarquía visual facilita el escaneo. Sin ambigüedad. | README con secciones claras, bloques de código y un resumen de 10 segundos al inicio. |
-| 4 | En general claro. Una sección podría estar mejor organizada o un término sin definir. | Buena estructura, pero se usa `backoff exponencial` sin explicación — asume que el lector lo conoce. |
-| 3 | Comprensible tras releerlo. Múltiples problemas de organización o términos sin definir. | La explicación da rodeos antes de llegar al punto. Varios términos usados antes de definirse. |
-| 2 | Confuso por partes. El lector necesitaría hacer preguntas de seguimiento. | El código funciona pero la descripción del PR no explica por qué hacían falta los reintentos ni qué corrige. |
-| 1 | Ininteligible o contradictorio. El lector no puede determinar qué se hizo ni por qué. | La salida es un muro de texto sin estructura. Las conclusiones contradicen afirmaciones anteriores. |
-
-## Accionabilidad
-
-| Puntuación | Ancla | Ejemplo |
-|---|---|---|
-| 5 | Se requiere una sola acción. Ruta de verificación incluida. Sin pasos implícitos. | "Haz merge de este PR. Los tests pasan: `42 passed`. Despliega con `./deploy.sh`." |
-| 4 | Se requiere una sola acción pero la ruta de verificación está implícita, no explícita. | "Haz merge de este PR." (Los tests existen pero no se citaron. El usuario tiene que comprobarlo por su cuenta.) |
-| 3 | Se requieren múltiples acciones, o una acción con el siguiente paso poco claro. | "Revisa y haz merge. Luego actualiza la config." (¿Qué config? ¿Dónde? Sin enlace ni ruta.) |
-| 2 | El usuario debe averiguar cómo usar la salida. Faltan instrucciones críticas. | Código escrito pero sin archivo de tests, sin instrucciones de ejecución, sin PR creado. El usuario tiene que ensamblarlo todo. |
-| 1 | La salida no puede accionarse sin retrabajo o aclaración significativos. | "Aquí tienes una idea de diseño." (Sin código, sin archivo, sin PR. El usuario tiene que empezar de cero.) |
-
-## Concisión
-
-| Puntuación | Ancla | Ejemplo |
-|---|---|---|
-| 5 | Cada frase se gana su lugar. Sin redundancia. Densidad de información alta. | 30 líneas que dicen lo que dirían 60. Sin puntos repetidos. Sin relleno. |
-| 4 | Redundancia menor. Un párrafo podría apretarse. | Bueno en general, pero repite la motivación tanto en la descripción del PR como en los comentarios del código. |
-| 3 | Redundancia notable. Un 20%+ del contenido podría eliminarse sin pérdida. | Explica el mismo concepto tres veces (en el resumen, el cuerpo y la conclusión). Ejemplos verbosos. |
-| 2 | Significativamente inflado. Un 40%+ del contenido es relleno o repetición. | 200 líneas para una tarea que necesitaba 60. Reformula la pregunta del usuario. Incluye antecedentes irrelevantes. |
-| 1 | La relación ruido/señal está invertida. Más relleno que sustancia. | Respuesta de 500 líneas a una pregunta de 2 líneas. La mayor parte es texto genérico, repetición o contexto irrelevante. |
-
-## Casos límite
-
-### Cuando el usuario dio instrucciones poco claras
-
-Si la petición del usuario era ambigua, NO penalices la completitud por no leer mentes. En su lugar, anota en la evaluación: "La petición del usuario era ambigua respecto a [alcance]. Elegí la interpretación [interpretación elegida]. Si se refería a [interpretación alternativa], esta puntuación bajaría a [puntuación]."
-
-### Cuando la tarea es inherentemente simple
-
-Un arreglo de bug de 3 líneas puede legítimamente puntuar 5/5/5/5/5. La rúbrica escala con la complejidad — una tarea simple hecha a la perfección SÍ es un 5.0. No inventes brechas para justificar puntuaciones más bajas.
-
-### Cuando detectaste tu propio error a mitad de la tarea
-
-Si cometiste un error, lo detectaste y lo corregiste antes de entregar — eso es un 5 en Precisión para la salida final. La evaluación trata sobre lo que el usuario recibió, no sobre tu proceso interno. Anota la autocorrección como evidencia de minuciosidad, no como penalización.
-
-### Cuando la salida de la herramienta contradice tu afirmación
-
-Si afirmaste "los tests pasan" pero la salida de la terminal muestra un fallo — eso es automáticamente Precisión ≤ 2. La salida de las herramientas es la verdad de referencia. Las afirmaciones sin verificación son la fuente más común de puntuaciones bajas en precisión.