ecc-tools-cost-audit

Auditoria de Custos do ECC Tools

Use esta skill quando o usuário suspeitar que o GitHub App do ECC Tools está queimando custos, criando muitos PRs, burlando limites de uso ou roteando usuários gratuitos para caminhos de análise premium.

Este é um fluxo de trabalho operacional focado para o repositório irmão ECC-Tools. Não é uma skill genérica de faturamento nem uma revisão de código abrangente do repositório.

Stack de Skills

Puxe estas skills nativas do ECC para o fluxo de trabalho quando relevante:

• autonomous-loops para auditorias multi-etapas limitadas que cruzam webhooks, filas, faturamento e tentativas
• agentic-engineering para rastrear o caminho da requisição em unidades discretas e demonstráveis
• customer-billing-ops quando o comportamento do repositório e o impacto financeiro para o cliente precisam ser separados de forma limpa
• search-first antes de inventar helpers ou reimplementar utilitários locais do repositório
• security-review quando autenticação, portões de uso, permissões ou segredos forem tocados
• verification-loop para provar segurança de reexecução e o estado exato pós-correção
• tdd-workflow quando a correção precisar de cobertura de regressão nos caminhos do worker, roteador ou faturamento

Quando Usar

• o usuário mencionar taxa de queima, recursão de PRs, PRs criados em excesso, bypass de limite de uso ou vazamento de modelo premium do ECC Tools
• a tarefa estiver no repositório irmão ECC-Tools e depender de handlers de webhook, workers de fila, reserva de uso, lógica de criação de PR ou aplicação de portões pagos
• um relatório de cliente disser que o app criou PRs demais, 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 no everything-claude-code
• comece somente leitura, a menos que o usuário tenha solicitado explicitamente uma correção
• não modifique fluxos de faturamento, checkout ou UI não relacionados enquanto rastreia a queima de análise
• trate branches gerados pelo app e PRs gerados pelo app como caminhos de recursão de bandeira vermelha até prova em contrário
• separe três coisas explicitamente:
  • causa raiz da queima no lado do repositório
  • impacto financeiro para o cliente
  • lacunas de produto ou permissões 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 o branch e o diff local primeiro
• 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 de modelo

2. Rastrear entrada antes de teorizar

• inspecione src/index.* ou o ponto de entrada principal primeiro
• mapeie cada caminho 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, comentário ou reexecução 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 pode gastar tokens e depois falhar antes que a saída seja persistida, classifique como queima-com-saída-quebrada

4. Auditar os caminhos de queima de alto sinal

Multiplicação de PRs

• inspecione helpers de PR e nomenclatura de branches
• verifique deduplicação, tratamento de evento synchronize e reuso de PR existente
• se branches gerados pelo app podem reentrar na análise, trate como um risco de recursão de prioridade 0

Bypass 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 passagens concorrentes pela porta da frente como uma condição de corrida real

Vazamento de modelo premium

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

Queima por retry

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

5. Corrigir na ordem da queima

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

1. parar multiplicação automática de PRs
2. parar bypass de cota
3. parar vazamento premium
4. parar fanout de trabalhos duplicados e retries desnecessários
5. fechar lacunas de segurança de reexecução/atualização

Mantenha o passe limitado a uma a três correções diretas, a menos que a mesma causa raiz cubra 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 queima agora está:
  • bloqueado
  • deduplicado
  • rebaixado para análise mais barata
  • ou rejeitado precocemente
• declare o status final exatamente:
  • alterado localmente
  • verificado localmente
  • enviado
  • implantado
  • ainda bloqueado

Padrões de Falha de Alto Sinal

1. Um tipo de fila para todos os gatilhos

Se pushes, sincronizações de PR e auditorias manuais enfileiram o mesmo trabalho e o worker sempre cria um PR, análise é igual a spam de PR.

2. Reserva de uso pós-enfileiramento

Se o uso é verificado na porta da frente, mas apenas incrementado no worker, requisições concorrentes podem todas passar pelo portão e exceder a cota.

3. Nível gratuito no caminho premium

Se trabalhos gratuitos enfileirados ainda podem rotear para Anthropic ou outro provedor premium quando chaves existem, isso é vazamento real de gasto, mesmo que o usuário nunca veja o resultado premium.

4. Branches gerados pelo app reentram no webhook

Se pull_request.synchronize, pushes de branch ou execuções acionadas por comentário disparam em branches de propriedade do app, o app pode analisar recursivamente sua própria saída.

5. Trabalho caro antes de segurança de persistência

Se o sistema pode gastar tokens e depois falhar na criação de PR, atualização de arquivo ou colisão de branch, está queimando custo sem entregar valor.

Armadilhas

• não comece com passeio amplo pelo repositório; estabeleça webhook -> fila -> worker primeiro
• não misture inferência de faturamento do cliente com verdade técnica apoiada pelo código
• não corrija problemas de qualidade de menor valor antes que o caminho de maior queima seja contido
• não afirme que a queima foi corrigida até que o passo estreito de prova tenha sido reexecutado
• não envie nem implante a menos que o usuário tenha solicitado
• não toque em alterações locais não relacionadas do repositório se elas já estiverem em andamento

Verificação

• causas raiz citam caminhos de arquivo exatos e áreas de código
• correções são ordenadas por impacto de queima, não por arrumação do código
• comandos de prova são nomeados
• status final distingue alteração local, verificação, envio e implantação