ecc-tools-cost-audit

ECC Tools Cost Audit

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 des utilisateurs gratuits vers des chemins d'analyse premium.

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

Stack de compétences

Intégrez ces compétences natives ECC dans le workflow lorsque cela est pertinent :

• autonomous-loops pour les audits multi-étapes bornés qui traversent les webhooks, files d'attente, facturation et relances
• 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 aides ou de réimplémenter des utilitaires locaux au dépôt
• security-review lorsque l'authentification, les barrières d'utilisation, les droits ou les secrets sont touchés
• verification-loop pour prouver la sécurité de la réexécution et l'état exact après correction
• tdd-workflow lorsque le correctif 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ûlage d'ECC Tools, la récursion de PR, les PR trop créés, le contournement de limite d'utilisation ou la fuite de modèle premium
• la tâche se trouve dans le dépôt frère ECC-Tools et dépend de gestionnaires de webhooks, workers de file d'attente, réservation d'utilisation, logique de création de PR ou application de barrière payante
• un rapport client indique que l'application a créé trop de PR, a facturé incorrectement ou a analysé du code sans produire de résultat utilisable

Garde-fous de périmètre

• travaillez dans le dépôt frère ECC-Tools, pas dans everything-claude-code
• commencez en lecture seule, sauf si l'utilisateur a explicitement demandé un correctif
• ne modifiez pas les flux de facturation, de checkout ou d'interface utilisateur non liés pendant le traçage du brûlage d'analyse
• considérez les branches créées par l'application et les PR créés par l'application comme des chemins de récursion drapeau rouge jusqu'à preuve du contraire
• séparez explicitement trois choses :
  • la cause racine du brûlage côté dépôt
  • l'impact de facturation côté client
  • les lacunes de produit ou de droits nécessitant un suivi dans le backlog

Workflow

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

• basculez dans le dépôt frère ECC-Tools
• vérifiez d'abord la branche et les différences locales
• identifiez la surface exacte sous audit :
  • routeur de webhooks
  • 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 de modèle

2. Tracer l'ingress avant de théoriser

• inspectez d'abord src/index.* ou le point d'entrée principal
• cartographiez chaque chemin de mise en file avant de suggérer un correctif
• confirmez quels événements GitHub partagent un même type de file d'attente
• confirmez si des événements push, pull_request, synchronize, comment ou de réexécution manuelle peuvent converger sur le même chemin coûteux

3. Tracer le worker et les effets de bord

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

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

Multiplication de PR

• inspectez les aides à la création de PR et la dénomination des branches
• vérifiez la déduplication, la gestion des événements synchronize et la réutilisation des PR existantes
• si des branches créées par l'application peuvent rentrer dans l'analyse, traitez cela comme un risque de récursion priorité 0

Contournement de quota

• inspectez 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 la mise en file mais que l'utilisation est facturée uniquement à l'intérieur du worker, traitez les passages simultanés à la porte d'entrée comme une véritable course critique

Fuite de modèle premium

• inspectez la sélection de modèle, le branchement par niveau et le routage fournisseur
• vérifiez si des utilisateurs gratuits ou plafonnés peuvent toujours atteindre des analyseurs premium lorsque des clés premium sont présentes

Brûlage de relance

• inspectez les boucles de relance, les travaux 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, corrigez cela avant les améliorations de qualité

5. Corriger dans l'ordre de brûlage

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

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

Limitez la passe à un à trois correctifs directs, sauf si la même cause racine couvre clairement plusieurs fichiers.

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

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

Motifs 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 mettent tous en file 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 mise en file

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

3. Niveau gratuit sur chemin premium

Si des travaux gratuits mis en file peuvent encore être routé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 créées par l'application rentrent dans le webhook

Si des exécutions déclenchées par pull_request.synchronize, des pushes de branches ou des commentaires se déclenchent sur des branches appartenant à l'application, l'application peut analyser récursivement sa propre production.

5. Travail coûteux avant la sécurité de 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 d'une collision de branche, il brûle du budget sans apporter de valeur.

Pièges

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

Vérification

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