ECC-Tools Cost Audit

Audit des coûts des ECC Tools

Utilisez cette compétence lorsque l'utilisateur soupçonne que l'application GitHub ECC Tools brûle du budget, crée trop de PR, contourne les limites d'utilisation ou achemine les utilisateurs gratuits vers des chemins d'analyse premium.

Il s'agit d'un workflow opérateur ciblé pour le dépôt sibling ECC-Tools. Ce n'est pas une compétence de facturation générique et ce n'est pas une revue de code à l'échelle du dépôt.

Stack de compétences

Tirez ces compétences natives des ECC dans le workflow lorsqu'elles sont pertinentes :

• autonomous-loops pour les audits multi-étapes bornés qui traversent les webhooks, les files d'attente, la facturation et les reprises
• agentic-engineering pour tracer le chemin de la requête en unités discrètes et prouvables
• customer-billing-ops lorsque le comportement du dépôt et l'impact mathématique sur le client doivent être séparés proprement
• search-first avant d'inventer des helpers ou de réimplémenter des utilitaires locaux au dépôt
• security-review lorsque l'authentification, les barrières d'utilisation, les droits d'accès ou les secrets sont touchés
• verification-loop pour prouver la sécurité de la ré-exécution et l'état exact post-correction
• tdd-workflow lorsque la correction nécessite une couverture de régression dans le worker, le routeur ou les chemins de facturation

Quand l'utiliser

• l'utilisateur mentionne le taux de brûlure des ECC Tools, la récursion de PR, les PR créées en trop, le contournement des limites d'utilisation ou la fuite de modèle premium
• la tâche se trouve dans le dépôt sibling ECC-Tools et dépend des gestionnaires de webhooks, des workers de file d'attente, de la réservation d'utilisation, de la logique de création de PR ou de l'application de la barrière payante
• un rapport client indique que l'application a créé trop de PR, facturé incorrectement ou analysé du code sans produire de résultat utilisable

Garde-fous de périmètre

• travailler dans le dépôt sibling ECC-Tools, pas dans everything-claude-code
• commencer en lecture seule sauf si l'utilisateur a clairement demandé une correction
• ne pas modifier les flux de facturation, de checkout ou d'interface utilisateur non liés lors du traçage de la brûlure d'analyse
• traiter les branches générées par l'application et les PR générées par l'application comme des chemins de récursion à drapeau rouge jusqu'à preuve du contraire
• séparer explicitement trois choses :
  • la cause racine de la brûlure côté dépôt
  • l'impact de la facturation côté client
  • les lacunes de produit ou de droits d'accès nécessitant un suivi dans le backlog

Workflow

1. Geler le périmètre du dépôt

• basculer dans le dépôt sibling ECC-Tools
• vérifier d'abord la branche et le diff local
• identifier la surface exacte sous audit :
  • routeur webhook
  • producteur de file d'attente
  • consommateur de file d'attente
  • chemin de création de PR
  • chemin de réservation d'utilisation / facturation
  • chemin de routage des modèles

2. Tracer l'entrée avant de théoriser

• inspecter src/index.* ou le point d'entrée principal en premier
• cartographier chaque chemin d'enfilement avant de suggérer une correction
• confirmer quels événements GitHub partagent un type de file d'attente
• confirmer si les événements push, pull_request, synchronize, comment ou les ré-exécutions manuelles peuvent converger sur le même chemin coûteux

3. Tracer le worker et les effets de bord

• inspecter le consommateur de file d'attente ou le worker planifié qui gère l'analyse
• confirmer si une analyse en file d'attente se termine toujours par :
  • création de PR
  • création de branche
  • mises à jour de fichiers
  • appels de modèles premium
  • incréments d'utilisation
• si l'analyse peut dépenser des tokens puis échouer avant que la sortie ne soit persistée, la classer comme brûlure-avec-sortie-cassée

4. Auditer les chemins de brûlure à fort signal

Multiplication de PR

• inspecter les helpers de PR et la dénomination des branches
• vérifier la déduplication, la gestion des événements synchronize et la réutilisation des PR existantes
• si les branches générées par l'application peuvent ré-entrer dans l'analyse, traiter cela comme un risque de récursion de priorité 0

Contournement de quota

• inspecter où le quota est vérifié par rapport à où l'utilisation est réservée ou incrémentée
• si le quota est vérifié avant l'enfilement mais que l'utilisation est facturée uniquement à l'intérieur du worker, traiter les passages simultanés par la porte d'entrée comme une véritable course critique

Fuite de modèle premium

• inspecter la sélection de modèle, la ramification par niveau et le routage des fournisseurs
• vérifier si les utilisateurs gratuits ou plafonnés peuvent toujours atteindre les analyseurs premium lorsque des clés premium sont présentes

Brûlure par reprises

• inspecter les boucles de reprise, les tâches de file d'attente en double et les ré-exécutions déterministes d'échec
• si la même erreur non transitoire peut dépenser de l'analyse à plusieurs reprises, corriger cela avant les améliorations de qualité

5. Corriger par ordre de brûlure

Si l'utilisateur a demandé des modifications de code, priorisez les correctifs dans cet ordre :

1. arrêter la multiplication automatique de PR
2. arrêter le contournement de quota
3. arrêter la fuite premium
4. arrêter la diffusion de tâches en double et les reprises inutiles
5. combler les lacunes de sécurité de ré-exécution/mise à jour

Limitez la passe à une à trois corrections directes, sauf si la même cause racine couvre clairement plusieurs fichiers.

6. Vérifier avec les plus petites étapes de preuve

• ré-exécuter uniquement les tests ciblés ou les tranches d'intégration qui couvrent le chemin modifié
• vérifier si le chemin de brûlure est désormais :
  • bloqué
  • dédupliqué
  • rétrogradé vers une analyse moins chère
  • ou rejeté tôt
• indiquer le statut final exactement :
  • modifié localement
  • vérifié localement
  • poussé
  • déployé
  • toujours bloqué

Schémas d'échec à fort signal

1. Un seul type de file d'attente pour tous les déclencheurs

Si les pushes, les synchronisations de PR et les audits manuels enfilent tous le même travail et que le worker crée toujours une PR, l'analyse équivaut à du spam de PR.

2. Réservation d'utilisation après enfilement

Si l'utilisation est vérifiée à la porte d'entrée mais seulement incrémentée dans le worker, les requêtes concurrentes peuvent toutes passer la porte et dépasser le quota.

3. Niveau gratuit sur le chemin premium

Si des travaux gratuits en file d'attente peuvent toujours être acheminés vers Anthropic ou un autre fournisseur premium lorsque des clés existent, il s'agit d'une véritable fuite de dépenses, même si l'utilisateur ne voit jamais le résultat premium.

4. Les branches générées par l'application ré-entrent dans le webhook

Si les événements pull_request.synchronize, les pushes de branche ou les exécutions déclenchées par un commentaire se déclenchent sur des branches appartenant à l'application, l'application peut analyser récursivement sa propre sortie.

5. Travail coûteux avant la sécurité de la persistance

Si le système peut dépenser des tokens puis échouer lors de la création de PR, de la mise à jour de fichier ou de la collision de branche, il brûle du budget sans produire de valeur.

Pièges

• ne commencez pas par une errance large dans le dépôt ; établissez d'abord webhook -> file d'attente -> worker
• ne mélangez pas l'inférence de facturation client avec la vérité produit basée sur le code
• ne corrigez pas les problèmes de qualité de moindre valeur avant que le chemin de brûlure le plus élevé ne soit contenu
• ne prétendez pas que la brûlure est corrigée tant que l'étape de preuve étroite n'a pas été ré-exécutée
• ne poussez ni ne déployez sauf si l'utilisateur l'a demandé
• ne touchez pas aux modifications locales non liées du dépôt si elles sont déjà en cours

Vérification

• les causes racines citent des chemins de fichiers et des zones de code exacts
• les corrections sont ordonnées par impact de brûlure, pas par propreté du code
• les commandes de preuve sont nommées
• le statut final distingue la modification locale, la vérification, le push et le déploiement