Auditoria de Custo das Ferramentas ECC

Use esta habilidade quando o usuário suspeitar que o GitHub App ECC Tools está gerando custos excessivos, criando PRs em excesso, contornando limites de uso ou direcionando usuários gratuitos para caminhos de análise premium.

Este é um fluxo de trabalho de operador focado para o repositório irmão ECC-Tools. Não é uma habilidade genérica de faturamento e não é uma análise de código em todo o repositório.

Pilha de Habilidades

Incorpore estas habilidades nativas do ECC no fluxo de trabalho quando relevante:

• autonomous-loops para auditorias delimitadas de várias etapas que abrangem webhooks, filas, faturamento e retentativas
• agentic-engineering para rastrear o caminho da solicitação em unidades discretas e comprováveis
• customer-billing-ops quando o comportamento do repositório e a matemática de impacto no cliente precisam ser separados de forma limpa
• search-first antes de inventar auxiliares ou reimplementar utilitários locais do repositório
• security-review quando autenticação, portões de uso, direitos ou segredos são tocados
• verification-loop para provar a segurança de reexecução e o estado exato pós-correção
• tdd-workflow quando a correção precisa de cobertura de regressão nos caminhos do worker, roteador ou faturamento

Quando Usar

• o usuário diz que a taxa de queima das Ferramentas ECC, recursão de PR, PRs criados em excesso, contorno de limite de uso ou vazamento de modelo premium
• a tarefa está no repositório irmão ECC-Tools e depende de manipuladores de webhook, workers de fila, reserva de uso, lógica de criação de PR ou aplicação de portão pago
• um relatório de cliente diz que o aplicativo criou muitos PRs, faturou incorretamente ou analisou código sem produzir um resultado utilizável

Barreiras de Escopo

• trabalhe no repositório irmão ECC-Tools, não em ECC
• comece somente leitura, a menos que o usuário tenha solicitado claramente uma correção
• não modifique fluxos de faturamento, checkout ou UI não relacionados enquanto rastreia o consumo de análise
• trate branches gerados pelo aplicativo e PRs gerados pelo aplicativo como caminhos de recursão de bandeira vermelha até prova em contrário
• separe explicitamente três coisas:
  • causa raiz do consumo no lado do repositório
  • impacto de faturamento voltado para o cliente
  • lacunas de produto ou direitos que precisam de acompanhamento no backlog

Fluxo de Trabalho

1. Congelar escopo do repositório

• mude para o repositório irmão ECC-Tools
• verifique primeiro o branch e as diferenças locais
• identifique a superfície exata sob auditoria:
  • roteador de webhook
  • produtor de fila
  • consumidor de fila
  • caminho de criação de PR
  • caminho de reserva de uso / faturamento
  • caminho de roteamento do modelo

2. Rastrear entrada antes de teorizar

• inspecione src/index.* ou o ponto de entrada principal primeiro
• mapeie todos os caminhos de enfileiramento antes de sugerir uma correção
• confirme quais eventos do GitHub compartilham um tipo de fila
• confirme se eventos push, pull_request, synchronize, comment ou re-run manual podem convergir no mesmo caminho caro

3. Rastrear o worker e os efeitos colaterais

• inspecione o consumidor de fila ou o worker agendado que lida com a análise
• confirme se uma análise enfileirada sempre termina em:
  • criação de PR
  • criação de branch
  • atualizações de arquivo
  • chamadas de modelo premium
  • incrementos de uso
• se a análise puder gastar tokens e depois falhar antes que a saída seja persistida, classifique-a como consumo-com-saída-quebrada

4. Auditar os caminhos de consumo de alto sinal

Multiplicação de PR

• inspecione auxiliares de PR e nomenclatura de branches
• verifique deduplicação, tratamento de eventos de sincronização e reutilização de PR existente
• se branches gerados pelo aplicativo puderem reentrar na análise, trate isso como um risco de recursão de prioridade 0

Contorno de cota

• inspecione onde a cota é verificada versus onde o uso é reservado ou incrementado
• se a cota for verificada antes do enfileiramento, mas o uso for cobrado apenas dentro do worker, trate passes concorrentes na porta de entrada como uma corrida real

Vazamento de modelo premium

• inspecione seleção de modelo, ramificação de tier e roteamento de provedor
• verifique se usuários gratuitos ou com limite ainda podem atingir analisadores premium quando chaves premium estão presentes

Consumo de retentativa

• inspecione loops de retentativa, trabalhos de fila duplicados e reexecuções de falha determinísticas
• se o mesmo erro não transitório puder gastar análise repetidamente, corrija isso antes das melhorias de qualidade

5. Corrigir na ordem de consumo

Se o usuário solicitou alterações de código, priorize as correções nesta ordem:

1. parar a multiplicação automática de PR
2. parar o contorno de cota
3. parar o vazamento premium
4. parar a dispersão de trabalhos duplicados e retentativas sem sentido
5. fechar lacunas de segurança de reexecução/atualização

Mantenha a passagem limitada a uma a três correções diretas, a menos que a mesma causa raiz abranja claramente vários arquivos.

6. Verificar com os menores passos de prova

• reexecute apenas os testes direcionados ou fatias de integração que cobrem o caminho alterado
• verifique se o caminho de consumo agora está:
  • bloqueado
  • deduplicado
  • rebaixado para análise mais barata
  • ou rejeitado precocemente
• declare o status final exatamente:
  • alterado localmente

…