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 PRs em excesso, desviando 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 e não é 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 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 ao cliente precisam ser separados claramente
• search-first antes de inventar ajudantes 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 segurança de reexecução e estado exato pós-correção
• tdd-workflow quando a correção precisa de cobertura de regressão no worker, roteador ou caminhos de faturamento

Quando Usar

• o usuário menciona taxa de queima do ECC Tools, recursão de PRs, PRs criados em excesso, desvio 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 imposição de portão pago
• um relatório de cliente diz que o app 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 everything-claude-code
• comece somente leitura, a menos que o usuário tenha solicitado claramente uma correção
• não mude 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 do lado do repositório
  • impacto de faturamento voltado ao 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 branch e diff local primeiro
• identifique a superfície exata sob auditoria:
  • roteador 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, comment ou reexecução manual podem convergir no mesmo caminho caro

3. Rastrear o worker e os efeitos colaterais

• inspecione o consumidor de fila ou worker agendado que lida com 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 ajudantes de PR e nomenclatura de branches
• verifique desduplicação, tratamento de evento synchronize e reutilização de PR existente
• se branches gerados pelo app podem reentrar na análise, trate isso como um risco de recursão de prioridade 0

Desvio de cota

• inspecione onde a cota é verificada versus onde o uso é reservado ou incrementado
• se a cota é verificada antes do enfileiramento, mas o uso é cobrado apenas dentro do worker, trate passagens simultâneas pela porta da frente como uma condição de corrida real

Vazamento de modelo premium

• inspecione seleção de modelo, ramificação de camadas 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 retentativa

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

5. Corrigir na ordem de queima

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

1. parar a multiplicação automática de PRs
2. parar o desvio de cota
3. parar o vazamento premium
4. parar a dispersão de jobs duplicados e retentativas inúteis
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 queima agora está:
  • bloqueado
  • desduplicado
  • rebaixado para análise mais barata
  • ou rejeitado antecipadamente
• 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 job 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, solicitações concorrentes podem todas passar pelo portão e exceder a cota.

3. Camada gratuita no caminho premium

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

4. Branches gerados pelo app reentram no webhook

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

5. Trabalho caro antes da 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 vadiagem ampla pelo repositório; estabeleça webhook -> fila -> worker primeiro
• não misture inferência de faturamento ao cliente com verdade de produto baseada em código
• não corrija problemas de qualidade de menor valor antes que o caminho de maior queima esteja contido
• não afirme que a queima está corrigida até que a etapa de prova estreita tenha sido reexecutada
• não envie ou implante a menos que o usuário tenha solicitado
• não toque em alterações locais do repositório não relacionadas 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 elegância do código
• comandos de prova são nomeados
• status final distingue alteração local, verificação, envio e implantação