# Checklists Empresariais e de Produção

## 1. Checklist Empresarial (Enterprise Architecture)

- [ ] **Multi-Tenant Activo:** O campo `tenant_id` está presente e validado (NOT NULL) em todas as tabelas de negócio?
- [ ] **Data Segregation:** O Middleware do Backend (ex: Prisma Extension ou Auth Guard) impede que pedidos sem o `Tenant-ID` consultem dados vitais?
- [ ] **Webhooks Idempotentes:** A tabela `webhook_logs` está criada com Unique Constraints na combição `(provider, external_event_id)`?
- [ ] **Lógica de Fila (Queues):** O processamento pesado (Emails Resend, Faturas Invoicexpress/Moloni) está a usar Workers/Filas (ex: BullMQ) ao invés de bloquear a request HTTP?
- [ ] **Stored Procedures para Consistência:** A atualização simultânea de Pagamento e Abate de Stock é executada de forma atómica (`sp_process_order_payment`) dentro do MySQL?
- [ ] **Permissões Desacopladas:** Foi removida a dependência lógica do Supabase Auth e substituída por JWTs independentes gerados pelo novo Backend?
- [ ] **Log de Auditoria:** Entidades e alterações sensíveis geram logs registados (ex: quem e quando reembolsou uma encomenda)?

## 2. Checklist de Segurança Máxima (DevSecOps)

- [ ] **Prepared Statements:** Nenhuma Query crua (`raw SQL`) insere variáveis concatenadas como texto, usando sempre `?` ou equivalentes seguros no ORM.
- [ ] **Rate Limiting:** Rotas sensíveis (Login, Criação de Conta, Início de Checkout, Webhooks) possuem limite rigoroso (Ex: max 10 requests / min / IP).
- [ ] **Assinatura de Webhooks:** Validação criptográfica do Header de webhook (`Stripe-Signature`, etc) implementada e validada antes de sequer processar o JSON body.
- [ ] **Passwords:** O campo `password_hash` da tabela `users` armazena passwords cifradas usando algoritmos fortes (Argon2 ou Bcrypt, NUNCA MD5 ou SHA1 simple).
- [ ] **Proteção Replay Attack:** Os eventos do Webhook validam as `Timestamps` - se o evento tem mais de 5 minutos, a API rejeita com HTTP 400.
- [ ] **Prevenção de Escalada de Privilégios (Mass Assignment):** Apenas Admins conseguem enviar a key `role` nos pedidos de edição de Perfil. O DB Trigger `trg_prevent_role_escalation` atua como salvaguarda extra.

## 3. Checklist de Produção (Infraestrutura/DevOps)

- [ ] **Backups Automáticos DB:** MySQL configurado com backups completos diários e logs binários (Binlog) guardados para Point-in-Time Recovery (PITR).
- [ ] **Testes de Rollback:** Efetuou-se uma simulação local de desastre, garantindo que se consegue restaurar a DB a partir de um backup recente sem perder chaves forasteiras.
- [ ] **Dockerização:** A aplicação backend está embalada num `Dockerfile` Multi-Stage de reduzida dimensão (usando Alpine) preparado para escalar via Kubernetes ou Docker Swarm?
- [ ] **CI/CD Integrado:** Migrações da Base de Dados rodam automaticamente (ex: Prisma Migrate / Flyway) numa CI pipeline (GitHub Actions) antes de o Backend fazer Deploy.
- [ ] **Gestão de Secrets:** Nenhuma credencial `DATABASE_URL` ou chave Stripe está num ficheiro exposto. Utiliza-se AWS Secrets Manager, GitHub Secrets ou `.env` restrito.
- [ ] **Health Checks Automáticos:** A infraestrutura vigia as portas do DB e da API e notifica via Slack/Email se a latência subir de 500ms ou existirem falhas 50x.
- [ ] **Índices de Performance:** Consultas cruciais utilizam índices (ex: procurar por `tenant_id` ou `transaction_id`).