auditoría-de-costos-ecc-tools

Auditoría de Costos de ECC Tools

Usa esta skill cuando el usuario sospeche que la GitHub App de ECC Tools está quemando créditos, creando PRs en exceso, evadiendo límites de uso, o enrutando usuarios gratuitos a rutas de análisis premium.

Este es un flujo de trabajo de operador enfocado en el repositorio hermano ECC-Tools. No es una skill genérica de facturación ni una revisión de código de todo el repositorio.

Pila de Skills

Incorpora estas skills nativas de ECC al flujo de trabajo cuando sea relevante:

• autonomous-loops para auditorías multi-paso acotadas que cruzan webhooks, colas, facturación y reintentos
• agentic-engineering para rastrear la ruta de la solicitud en unidades discretas y demostrables
• customer-billing-ops cuando el comportamiento del repositorio y el impacto matemático en el cliente deban separarse limpiamente
• search-first antes de inventar ayudantes o reimplementar utilidades locales del repositorio
• security-review cuando se toquen autenticación, compuertas de uso, derechos o secretos
• verification-loop para demostrar la seguridad de la re-ejecución y el estado exacto post-corrección
• tdd-workflow cuando la corrección necesite cobertura de regresión en las rutas del worker, enrutador o facturación

Cuándo Usarlo

• el usuario menciona tasa de consumo de ECC Tools, recursión de PRs, PRs creados en exceso, evasión de límites de uso, o fuga de modelos premium
• la tarea está en el repositorio hermano ECC-Tools y depende de manejadores de webhook, workers de cola, reserva de uso, lógica de creación de PRs, o aplicación de compuertas de pago
• un informe de cliente dice que la app creó demasiados PRs, facturó incorrectamente, o analizó código sin producir un resultado útil

Barreras de Alcance

• trabajar en el repositorio hermano ECC-Tools, no en everything-claude-code
• comenzar en modo solo lectura a menos que el usuario haya solicitado explícitamente una corrección
• no mutar flujos no relacionados de facturación, checkout o UI mientras se rastrea el consumo de análisis
• tratar las ramas generadas por la app y los PRs generados por la app como rutas de recursión de bandera roja hasta que se demuestre lo contrario
• separar explícitamente tres cosas:
  • causa raíz del consumo del lado del repositorio
  • impacto de facturación visible para el cliente
  • brechas de producto o derechos que necesiten seguimiento en el backlog

Flujo de Trabajo

1. Congelar el alcance del repositorio

• cambiarse al repositorio hermano ECC-Tools
• verificar primero la rama y el diff local
• identificar la superficie exacta bajo auditoría:
  • enrutador de webhook
  • productor de cola
  • consumidor de cola
  • ruta de creación de PR
  • ruta de reserva de uso / facturación
  • ruta de enrutamiento de modelos

2. Rastrear el ingreso antes de teorizar

• inspeccionar src/index.* o el punto de entrada principal primero
• mapear cada ruta de enqueue antes de sugerir una corrección
• confirmar qué eventos de GitHub comparten un tipo de cola
• confirmar si los eventos push, pull_request, synchronize, comment, o re-run manual pueden converger en la misma ruta costosa

3. Rastrear el worker y los efectos secundarios

• inspeccionar el consumidor de cola o el worker programado que maneja el análisis
• confirmar si un análisis encolado siempre termina en:
  • creación de PR
  • creación de rama
  • actualizaciones de archivos
  • llamadas a modelos premium
  • incrementos de uso
• si el análisis puede gastar tokens y luego fallar antes de que la salida se persista, clasificarlo como consumo-con-salida-rota

4. Auditar las rutas de consumo de alta señal

Multiplicación de PRs

• inspeccionar los ayudantes de PR y la nomenclatura de ramas
• verificar la desduplicación, el manejo del evento synchronize, y la reutilización de PRs existentes
• si las ramas generadas por la app pueden reingresar al análisis, tratar eso como un riesgo de recursión de prioridad 0

Evasión de cuota

• inspeccionar dónde se verifica la cuota versus dónde se reserva o incrementa el uso
• si la cuota se verifica antes del enqueue pero el uso se cobra solo dentro del worker, tratar los pases concurrentes por la puerta principal como una condición de carrera real

Fuga de modelo premium

• inspeccionar la selección de modelo, la ramificación por niveles y el enrutamiento del proveedor
• verificar si los usuarios gratuitos o con límites aún pueden alcanzar analizadores premium cuando las claves premium están presentes

Consumo por reintentos

• inspeccionar los bucles de reintento, los trabajos de cola duplicados y las re-ejecuciones por fallos deterministas
• si el mismo error no transitorio puede gastar análisis repetidamente, corregir eso antes de las mejoras de calidad

5. Corregir en orden de consumo

Si el usuario solicitó cambios de código, priorizar las correcciones en este orden:

1. detener la multiplicación automática de PRs
2. detener la evasión de cuota
3. detener la fuga premium
4. detener la propagación de trabajos duplicados y los reintentos sin sentido
5. cerrar las brechas de seguridad en re-ejecución/actualización

Mantener el pase acotado a una o tres correcciones directas a menos que la misma causa raíz abarque claramente varios archivos.

6. Verificar con los pasos de prueba más pequeños

• re-ejecutar solo las pruebas específicas o los fragmentos de integración que cubren la ruta modificada
• verificar si la ruta de consumo ahora está:
  • bloqueada
  • desduplicada
  • degradada a análisis más barato
  • o rechazada temprano
• indicar el estado final exactamente:
  • cambiado localmente
  • verificado localmente
  • subido (push)
  • desplegado
  • aún bloqueado

Patrones de Falla de Alta Señal

1. Un solo tipo de cola para todos los desencadenantes

Si los pushes, las sincronizaciones de PR y las auditorías manuales encolan el mismo trabajo y el worker siempre crea un PR, el análisis equivale a spam de PRs.

2. Reserva de uso posterior al enqueue

Si el uso se verifica en la puerta principal pero solo se incrementa en el worker, las solicitudes concurrentes pueden pasar todas la compuerta y exceder la cuota.

3. Nivel gratuito en ruta premium

Si los trabajos encolados gratuitos aún pueden enrutarse a Anthropic u otro proveedor premium cuando existen claves, eso es una fuga de gasto real incluso si el usuario nunca ve el resultado premium.

4. Las ramas generadas por la app reingresan al webhook

Si las ejecuciones activadas por pull_request.synchronize, pushes de rama, o comentarios se disparan en ramas propiedad de la app, la app puede analizar recursivamente su propia salida.

5. Trabajo costoso antes de la seguridad de persistencia

Si el sistema puede gastar tokens y luego fallar en la creación de PR, actualización de archivos o colisión de ramas, está quemando costos sin entregar valor.

Errores Comunes

• no comenzar con un vagabundeo amplio por el repositorio; establecer primero webhook -> cola -> worker
• no mezclar inferencia de facturación al cliente con la verdad del producto respaldada por código
• no corregir problemas de calidad de menor valor antes de que la ruta de mayor consumo esté contenida
• no afirmar que el consumo está corregido hasta que se haya re-ejecutado el paso de prueba estrecho
• no hacer push ni desplegar a menos que el usuario lo haya solicitado
• no tocar cambios locales no relacionados del repositorio si ya están en progreso

Verificación

• las causas raíz citan rutas de archivo exactas y áreas de código
• las correcciones se ordenan por impacto en el consumo, no por claridad del código
• los comandos de prueba se nombran
• el estado final distingue entre cambio local, verificación, push y despliegue