auditoria-de-producao

Auditoria de Produção

Use esta skill quando o usuário perguntar se uma aplicação está pronta para ser lançada, o que poderia quebrar em produção, ou o que deve ser corrigido antes de um lançamento. Esta é uma reescrita segura para mantenedores da ideia desatualizada de auditoria de produção da comunidade: ela mantém a lente útil de prontidão para produção e remove a execução externa não verificada e o compartilhamento de dados com terceiros.

Quando Usar

• O usuário pergunta "isso está pronto para produção", "o que quebraria em prod", "o que perdemos", "audite este repositório" ou "pronto para lançar?"
• Uma funcionalidade foi mesclada e precisa de uma passagem de risco pré-implantação ou pós-merge.
• Um lançamento público, demonstração, rollout para cliente ou apresentação para investidores está próximo.
• A CI está verde, mas o usuário quer risco de produção, não apenas status de teste.
• Uma URL implantada, branch de release, PR ou checkout atual está disponível para coleta de evidências.

Quando Não Usar

• Durante implementação ativa, quando a lente correta é codificação segura em nível de linha; use security-review primeiro.
• Para bibliotecas puras, modelos, repositórios apenas de documentação ou scaffolds, a menos que o usuário queira prontidão de empacotamento/liberação, em vez de prontidão de aplicação.
• Quando o usuário pede uma auditoria formal de conformidade. Esta skill é triagem de engenharia, não certificação legal, financeira, médica ou regulatória.
• Quando a única evidência disponível é uma ideia de produto sem repositório, implantação, CI ou superfície de runtime.

Como Funciona

Construa a auditoria a partir de evidências locais e autorizadas pelo usuário. Não execute código remoto não verificado, carregue conteúdos do repositório em serviços de terceiros ou chame scanners externos a menos que o usuário aprove explicitamente essa ferramenta e fluxo de dados específicos.

Use esta ordem:

1. Estabeleça a superfície de liberação.
2. Leia mudanças recentes e o estado atual do branch.
3. Inspecione os limites de runtime, autenticação, dados, pagamento, jobs em segundo plano, IA e implantação que realmente existem no repositório.
4. Verifique CI, testes, migrações, documentação de ambiente e caminho de rollback.
5. Produza uma recomendação curta de lançamento/bloqueio com correções específicas.

Lista de Verificação de Evidências

Comece com sinais locais e baratos:

git status --short --branch
git log --oneline --decorate -20
git diff --stat origin/main...HEAD

Em seguida, inspecione a superfície específica do projeto:

• Scripts de pacote, fluxos de trabalho de CI, scripts de release, arquivos Docker e manifestos de implantação.
• Rotas de API, webhooks, middleware de autenticação, workers em segundo plano, jobs cron e migrações de banco de dados.
• Documentação de variáveis de ambiente e verificações de inicialização.
• Ganchos de observabilidade, relatórios de erro, logs, verificações de saúde e dashboards.
• Instruções de rollback, seed, migração e backfill.
• Cobertura E2E para os caminhos de usuário mais importantes.

Se uma URL implantada estiver no escopo, use verificações de navegador ou HTTP apenas contra essa URL e evite ações com credenciais a menos que o usuário forneça uma conta de teste segura.

Lentes de Risco

Segurança e Autenticação

• As rotas públicas, rotas de API e rotas de admin estão claramente separadas?
• A autenticação e autorização são aplicadas no lado do servidor?
• Os segredos são mantidos fora de bundles de cliente, logs, saída de exemplo e arquivos versionados?
• Limites de taxa, proteções CSRF, política CORS e validação de upload estão presentes onde a aplicação precisa deles?
• A superfície de IA ou agente se defende contra injeção de prompt, abuso de ferramentas e conteúdo não confiável cruzando para ações privilegiadas?

Integridade dos Dados

• As migrações são executadas de forma limpa e têm um plano de rollback ou recuperação?
• Migrações destrutivas, backfills e importações de dados são encenados com segurança?
• As políticas de banco de dados, concessões e limites de função de serviço correspondem ao modelo de locação da aplicação?
• As tentativas são idempotentes para gravações, jobs e manipuladores de webhook?

Pagamentos e Webhooks

• As assinaturas de webhook são verificadas antes de analisar campos de payload confiáveis?
• Cada webhook de pagamento, assinatura ou entrega é idempotente?
• A repetição, entrega duplicada e entrega fora de ordem são tratadas?
• As credenciais de modo de teste e modo ao vivo estão separadas?

Operações

• A aplicação pode iniciar a partir de um checkout limpo usando comandos documentados?
• As variáveis de ambiente necessárias são nomeadas, validadas e falham rapidamente?
• Existe uma verificação de saúde que comprova que as dependências estão acessíveis?
• Os caminhos de implantação, rollback e proprietário de incidente estão documentados?
• Os logs são úteis sem vazar segredos ou dados pessoais?

Experiência do Usuário

• Os caminhos críticos de lançamento são cobertos em desktop e mobile?
• Os formulários são utilizáveis em mobile sem zoom de entrada, sobreposição de layout ou estados de submissão bloqueados?
• Os estados de carregamento, vazio, erro e permissão negada informam ao usuário o que aconteceu?
• Existe um caminho de suporte ou recuperação quando uma operação crítica falha?

Pontuação

Use pontuações para forçar priorização, não para implicar certeza matemática.

Faixa	Pontuação	Significado
Bloqueado	0-49	Não lance até que os principais riscos sejam corrigidos
Arriscado	50-69	Lance apenas com um rollout pequeno ou beta interno
Lançável com Riscos	70-84	Lance se os proprietários aceitarem os riscos listados
Forte	85-100	Nenhum bloqueador de lançamento óbvio a partir das evidências disponíveis

Limite a pontuação em 69 se alguma destas condições for verdadeira:

• Autenticação ou autorização está ausente em dados sensíveis.
• Webhooks de pagamento ou entrega não são idempotentes.
• Migrações necessárias não podem ser executadas com segurança.
• Segredos estão expostos em bundles de cliente, logs ou arquivos versionados.
• Não há caminho de rollback para um lançamento de alto impacto.

Limite a pontuação em 84 se a CI não estiver verde ou o caminho crítico de lançamento não tiver sido testado de ponta a ponta.

Formato de Saída

Comece com uma frase:

Auditoria de produção: 76/100, lançável com riscos, com idempotência de webhook e documentação de rollback como os dois riscos a corrigir antes do lançamento público.

Em seguida, liste:

• Bloqueadores: itens que devem ser corrigidos antes da implantação.
• Correções de alto valor: próximas correções se o usuário quiser melhorar a pontuação.
• Evidências verificadas: arquivos, comandos, CI, URL implantada ou PRs inspecionados.
• Evidências faltando: o que mudaria a confiança se fornecido.
• Próxima ação: uma correção ou etapa de verificação concreta.

Mantenha os pontos fortes curtos. O usuário perguntou sobre prontidão, então a resposta útil é o risco restante e a próxima ação.

Exemplo

Usuário:

isso está pronto para lançar?

Resposta:

Auditoria de produção: 68/100, arriscado, porque os webhooks do Stripe são verificados mas não são idempotentes e não há nota de rollback para a migração pendente.

Bloqueadores:
- Adicionar idempotência para `checkout.session.completed` antes de atender pedidos.
- Escrever e testar o caminho de rollback para `20260511_add_billing_state.sql`.

Correções de alto valor:
- Adicionar uma verificação de saúde que comprove a acessibilidade do banco de dados e do provedor de pagamento.
- Adicionar um caminho E2E para upgrade, entrega de webhook e atualização da página de faturamento.

Evidências verificadas:
- `api/stripe/webhook.ts`
- `db/migrations/20260511_add_billing_state.sql`
- Execução do GitHub Actions para o branch de release

Próxima ação: Quer que eu corrija a idempotência do webhook primeiro?

Anti-Padrões

• Executar npx <pacote>@latest ou um scanner remoto como caminho de auditoria padrão.
• Carregar código-fonte, segredos, dados de clientes ou topologia privada para um serviço de auditoria externo sem aprovação explícita.
• Produzir uma pontuação sem nomear as evidências verificadas.
• Tratar CI verde como prontidão para produção.
• Terminar com um genérico "me avise o que você quer fazer".

Veja Também

• Skill: security-review
• Skill: deployment-patterns
• Skill: e2e-testing
• Skill: tdd-workflow
• Skill: verification-loop