ecc-tools-cost-audit

Auditoría de Costos de ECC Tools

Use esta habilidad cuando el usuario sospeche que la App de GitHub de ECC Tools está generando costos excesivos, creando PRs de forma descontrolada, eludiendo los límites de uso o enrutando usuarios gratuitos a rutas de análisis premium.

Este es un flujo de trabajo operativo específico para el repositorio hermano ECC-Tools. No es una habilidad de facturación genérica ni una revisión de código exhaustiva del repositorio.

Pila de Habilidades

Incorpore estas habilidades nativas de ECC en el flujo de trabajo cuando sea relevante:

• autonomous-loops para auditorías multi-paso acotadas que atraviesan webhooks, colas, facturación y reintentos
• agentic-engineering para rastrear la ruta de solicitud en unidades discretas y demostrables
• customer-billing-ops cuando el comportamiento del repositorio y el impacto matemático en el cliente deban separarse claramente
• 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 re-ejecución y el estado exacto posterior a la corrección
• tdd-workflow cuando la corrección necesite cobertura de regresión en el worker, enrutador o rutas de facturación

Cuándo Usarla

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

Barreras de Alcance

• trabaje en el repositorio hermano ECC-Tools, no en everything-claude-code
• comience en modo solo lectura a menos que el usuario haya solicitado explícitamente una corrección
• no modifique flujos de facturación, checkout o interfaz de usuario no relacionados mientras rastrea el consumo del análisis
• trate 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
• separe explícitamente tres cosas:
  • causa raíz del consumo en el repositorio
  • impacto de facturación visible para el cliente
  • brechas de producto o derechos que necesitan seguimiento en el backlog

Flujo de Trabajo

1. Congele el alcance del repositorio

• cambie al repositorio hermano ECC-Tools
• primero verifique la rama y el diff local
• identifique la superficie exacta bajo auditoría:
  • enrutador de webhooks
  • productor de cola
  • consumidor de cola
  • ruta de creación de PR
  • ruta de reserva de uso / facturación
  • ruta de enrutamiento de modelo

2. Rastree el ingreso antes de teorizar

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

3. Rastree el worker y los efectos secundarios

• inspeccione el consumidor de cola o el worker programado que maneja el análisis
• confirme 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 se persista la salida, clasifíquelo como consumo-con-salida-rota

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

Multiplicación de PRs

• inspeccione los ayudantes de PR y la nomenclatura de ramas
• verifique la deduplicació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, trate eso como un riesgo de recursión de prioridad 0

Elusión de cuota

• inspeccione dónde se verifica la cuota versus dónde se reserva o incrementa el uso
• si la cuota se verifica antes del encolado pero el uso se cobra solo dentro del worker, trate los pases concurrentes en la puerta de entrada como una condición de carrera real

Fuga de modelo premium

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

Consumo por reintentos

• inspeccione los bucles de reintentos, trabajos de cola duplicados y re-ejecuciones deterministas de fallos
• si el mismo error no transitorio puede gastar análisis repetidamente, corríjalo antes de mejorar la calidad

5. Corrija en orden de consumo

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

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

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

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

• re-ejecute solo las pruebas específicas o los fragmentos de integración que cubran la ruta modificada
• verifique si la ruta de consumo ahora está:
  • bloqueada
  • deduplicada
  • degradada a análisis más barato
  • o rechazada temprano
• indique el estado final exactamente:
  • cambiado localmente
  • verificado localmente
  • enviado (pushed)
  • desplegado (deployed)
  • aún bloqueado

Patrones de Falla de Alta Señal

1. Un 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 encolado

Si el uso se verifica en la puerta de entrada 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 desencadenadas por pull_request.synchronize, pushes de rama o comentarios se activan 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á consumiendo costos sin entregar valor.

Errores Comunes

• no comience con un deambular amplio por el repositorio; primero establezca webhook -> cola -> worker
• no mezcle la inferencia de facturación del cliente con la verdad del producto respaldada por código
• no corrija problemas de calidad de menor valor antes de contener la ruta de mayor consumo
• no afirme que el consumo está corregido hasta que se haya re-ejecutado el paso de prueba acotado
• no envíe (push) ni despliegue a menos que el usuario lo haya solicitado
• no toque 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 de consumo, no por limpieza del código
• los comandos de prueba se nombran
• el estado final distingue cambio local, verificación, envío (push) y despliegue