auditoria-producao

Auditoria de Produção

Use esta skill quando o usuário perguntar se uma aplicação está pronta para ser enviada, o que poderia quebrar em produção ou o que deve ser corrigido antes de um lançamento. Esta é uma reescrita segura e de fácil manutenção da ideia desatualizada de auditoria de produção: ela mantém a lente útil de prontidão para produção e remove a execução externa não fixada 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 esquecemos", "audite este repositório" ou "pronto para enviar?"
• Uma funcionalidade foi mesclada e precisa de uma verificação de risco pré-implantação ou pós-merge.
• Um lançamento público, demonstração, implantação para cliente ou apresentação para investidores está próximo.
• O CI está verde, mas o usuário quer risco de produção, não apenas status de teste.
• Uma URL implantada, branch de lançamento, 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 solicitar 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 fixado, faça upload do conteúdo do repositório para 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 lançamento.
2. Leia as alterações recentes e o estado atual da 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 reversão.
5. Produza uma recomendação curta de enviar/bloquear 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, workflows de CI, scripts de lançamento, arquivos Docker e manifestos de implantação.
• Rotas de API, webhooks, middleware de autenticação, workers em segundo plano, tarefas 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 painéis.
• Instruções de reversão, seed, migração e backfill.
• Cobertura E2E para os caminhos de usuário mais importantes.

Se uma URL implantada estiver no escopo, use apenas verificações de navegador ou HTTP contra essa URL e evite ações autenticadas, 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 administrador 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 do 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 o aplicativo 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 que cruza para ações privilegiadas?

Integridade dos Dados

• As migrações são executadas de forma limpa e têm um plano de reversão ou recuperação?
• Migrações destrutivas, backfills e importações de dados são encenadas 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 do aplicativo?
• 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 fulfillment é idempotente?
• A repetição, entrega duplicada e entrega fora de ordem são tratadas?
• As credenciais de modo de teste e modo de produção são separadas?

Operações

• O aplicativo 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 prova que as dependências estão acessíveis?
• Os caminhos de implantação, reversão 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 a priorização, não para implicar certeza matemática.

Faixa	Pontuação	Significado
Bloqueado	0-49	Não envie até que os principais riscos sejam corrigidos
Arriscado	50-69	Envie apenas com rollout pequeno ou beta interno
Lançável com Ressalvas	70-84	Envie 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:

• A autenticação ou autorização está ausente em dados sensíveis.
• Os webhooks de pagamento ou fulfillment não são idempotentes.
• As migrações necessárias não podem ser executadas com segurança.
• Segredos estão expostos em bundles do cliente, logs ou arquivos versionados.
• Não há caminho de reversão para um lançamento de alto impacto.

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

Formato de Saída

Comece com uma frase:

Auditoria de produção: 76/100, lançável com ressalvas, com idempotência de webhook e documentação de reversão 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 ausentes: o que mudaria a confiança se fosse fornecido.
• Próxima ação: uma correção concreta ou etapa de verificação.

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

Exemplo

Usuário:

isso está pronto para enviar?

Resposta:

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

Bloqueadores:
- Adicione idempotência para `checkout.session.completed` antes de atender pedidos.
- Escreva e teste o caminho de reversão para `20260511_add_billing_state.sql`.

Correções de alto valor:
- Adicione uma verificação de saúde que verifique a acessibilidade do banco de dados e do provedor de pagamento.
- Adicione um caminho E2E para upgrade, fulfillment 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 a branch de lançamento

Próxima ação: Deseja 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.
• Fazer upload de 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ê deseja fazer."

Veja Também

• Skill: revisão-de-segurança
• Skill: padrões-de-implantação
• Skill: testes-e2e
• Skill: fluxo-tdd
• Skill: ciclo-de-verificação