Auditoria de Produção

Use esta habilidade quando o usuário perguntar se um aplicativo está pronto para ser lançado, o que pode falhar em produção ou o que precisa ser corrigido antes de um lançamento. Esta é uma reescrita segura para mantenedores da ideia desatualizada da comunidade "production-audit": ela mantém a útil perspectiva de prontidão para produção e remove a execução externa sem fixação e o compartilhamento de dados de terceiros.

Quando Usar

• O usuário pergunta "isto está pronto para produção", "o que falharia em produção", "o que perdemos", "audite este repositório" ou "pronto para lançar?"
• Uma funcionalidade foi mesclada e precisa de uma análise de risco pré-implantação ou pós-mesclagem.
• Um lançamento público, demonstração, implantação para clientes ou apresentação para investidores está próximo.
• O CI está verde, mas o usuário quer o risco de produção, não apenas o status do teste.
• Um URL implantado, branch de lançamento, PR ou checkout atual está disponível para coleta de evidências.

Quando Não Usar

• Durante a implementação ativa, quando a perspectiva correta é codificação segura em nível de linha; use security-review primeiro.
• Para bibliotecas puras, templates, repositórios apenas de documentação ou scaffolds, a menos que o usuário queira prontidão de empacotamento/lançamento em vez de prontidão de aplicativo.
• Quando o usuário pede uma auditoria formal de conformidade. Esta habilidade é 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 tempo de execução.

Como Funciona

Construa a auditoria a partir de evidências locais e autorizadas pelo usuário. Não execute código remoto sem fixação, não carregue conteúdos de repositório em serviços de terceiros, nem 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 do branch atual.
3. Inspecione os limites de tempo de execução, autenticação, dados, pagamentos, jobs em segundo plano, IA e implantação que realmente existem no repositório.
4. Verifique o CI, testes, migrações, documentação do ambiente e caminho de rollback.
5. Produza uma recomendação curta de lançamento/bloqueio com correções específicas.

Checklist de Evidências

Comece com sinais baratos e locais:

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 lançamento, 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 integridade e dashboards.
• Instruções de rollback, seed, migração e backfill.
• Cobertura E2E para os caminhos do usuário que mais importam.

Se um URL implantado estiver em escopo, use apenas verificações de navegador ou HTTP nesse 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 administrador estão claramente separadas?
• A autenticação e autorização são aplicadas no lado do servidor?
• Os segredos são mantidos fora dos pacotes do cliente, logs, saídas de exemplo e arquivos commitados?
• 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 rodam para frente de forma limpa e têm um plano de rollback ou recuperação?
• Migrações destrutivas, backfills e importações de dados são preparadas com segurança?
• As políticas de banco de dados, concessões e limites de função de serviço correspondem ao modelo de tenancy do aplicativo?
• As retentativas são idempotentes para escritas, 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?
• Replay, entrega duplicada e entrega fora de ordem são tratadas?
• Credenciais de modo de teste e modo ativo 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 integridade que prova que as dependências são alcançáveis?
• Os caminhos de implantação, rollback e proprietário de incidentes sã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 estão cobertos em desktop e mobile?
• Os formulários são utilizáveis em dispositivos móveis sem zoom de entrada, sobreposição de layout ou estados de envio bloqueados?
• Os estados de carregamento, vazio, erro e permissão negada informam ao usuário o que