Automação de Auditoria e Operações

O que Automação de Auditoria e Operações faz?

Use isso quando o usuário perguntar quais automações estão ativas, quais jobs estão quebrados, onde há sobreposição ou quais ferramentas e conectores estão realmente realizando trabalho útil agora.

Esta é uma skill de operador focada em auditoria. O trabalho é produzir um inventário baseado em evidências e um conjunto de recomendações de manter / mesclar / cortar / corrigir em seguida antes de reescrever qualquer coisa.

Pilha de Skills

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

• workspace-surface-audit para inventário de conectores, MCP, hooks e apps
• knowledge-ops quando a auditoria precisar reconciliar a verdade do repositório ativo com o contexto persistente
• github-ops quando a resposta depender de CI, workflows agendados, issues ou automação de PR
• ecc-tools-cost-audit quando o problema real for fanout de webhook, jobs enfileirados ou queima de faturamento no repositório de aplicativo irmão
• research-ops quando o inventário local precisar ser comparado com o suporte atual da plataforma ou documentação pública
• verification-loop para provar o estado pós-correção em vez de confiar em recuperação presumida

Quando Usar

• o usuário pergunta "quais automações eu tenho", "o que está ativo", "o que está quebrado" ou "o que se sobrepõe"
• a tarefa abrange cron jobs, GitHub Actions, hooks locais, servidores MCP, conectores, wrappers ou integrações de aplicativos
• o usuário quer saber o que foi portado de outro sistema de agente e o que ainda precisa ser reconstruído dentro do ECC
• o workspace acumulou várias formas de fazer a mesma coisa e o usuário quer uma única via canônica

Diretrizes

• comece somente leitura, a menos que o usuário tenha explicitamente solicitado correções
• separe:
  • configurado
  • autenticado
  • verificado recentemente
  • desatualizado ou quebrado
  • completamente ausente
• não afirme que uma ferramenta está ativa só porque uma skill ou configuração a referencia
• não mescle ou exclua superfícies sobrepostas até que a tabela de evidências exista

Fluxo de Trabalho

1. Inventariar a superfície real

Leia a superfície ativa atual antes de teorizar:

• hooks e scripts de hook locais do repositório
• GitHub Actions e workflows agendados
• configurações MCP e servidores habilitados
• integrações baseadas em conector ou aplicativo
• scripts wrapper e pontos de entrada de automação específicos do repositório

Agrupe-os por superfície:

• runtime local
• CI / automação do repositório
• sistemas externos conectados
• mensageria / notificações
• faturamento / operações do cliente
• pesquisa / monitoramento

2. Classificar cada item por estado de operação

Para cada automação identificada, marque:

• configurado
• autenticado
• verificado recentemente
• desatualizado ou quebrado
• ausente

Em seguida, classifique o tipo de problema:

• quebra ativa
• falha de autenticação
• status desatualizado
• sobreposição ou redundância
• capacidade ausente

3. Rastrear o caminho da prova

Fundamente cada afirmação importante com uma fonte concreta:

• caminho de arquivo
• execução de workflow
• log de hook
• entrada de configuração
• saída de comando recente
• assinatura exata de falha

Se o estado atual for ambíguo, diga isso diretamente em vez de fingir que a auditoria está completa.

4. Terminar com manter / mesclar / cortar / corrigir em seguida

Para cada superfície suspeita ou sobreposta, retorne uma decisão:

• manter
• mesclar
• cortar
• corrigir em seguida

O valor está em colocar automação ruidosa em uma única via canônica do ECC, não em preservar todo caminho histórico.

Formato de Saída

SUPERFÍCIE ATUAL
- automação
- fonte
- estado de operação
- prova

CONSTATAÇÕES
- quebra ativa
- sobreposição
- status desatualizado
- capacidade ausente

RECOMENDAÇÃO
- manter
- mesclar
- cortar
- corrigir em seguida

PRÓXIMA AÇÃO ECC
- skill / hook / workflow / via de aplicativo exata a fortalecer

Armadilhas

• não responda de memória quando o inventário ativo puder ser lido
• não trate "presente na configuração" como "funcionando"
• não corrija redundância de baixo valor antes de nomear o caminho de alto sinal quebrado
• não amplie a tarefa para uma reescrita do repositório se o usuário pediu inventário primeiro

Verificação

• afirmações importantes citam um caminho de prova ativo
• cada automação identificada é rotulada com uma categoria clara de estado de operação
• a recomendação final distingue manter / mesclar / cortar / corrigir em seguida