Diretrizes de Desenvolvimento com AI
5. Code Review Obrigatório

5. Code Review Obrigatório

100% do código gerado por IA DEVE passar por code review. Não há exceções. Esta seção estabelece o processo obrigatório de revisão.

5.1. Política de Code Review

5.1.1. Obrigatoriedade Universal

  • ✅ 100% do código AI-generated passa por review
  • ✅ Sem exceções, independente do nível do desenvolvedor
  • ✅ Review por desenvolvedor Sênior para código crítico
  • ✅ Aprovação formal documentada antes de merge

5.1.2. Co-Responsabilidade do Reviewer

⚠️ CRÍTICO: O reviewer é CO-RESPONSÁVEL por qualquer vulnerabilidade, violação ou incidente causado pelo código que aprovar.

Isso significa:

  • Penalidades idênticas: Reviewer recebe as MESMAS penalidades que o autor do código
  • Suspensão compartilhada: Se autor for suspenso por 90 dias, reviewer também será
  • Rescisão compartilhada: Se código causar incidente grave resultando em rescisão do autor, reviewer também pode ser rescindido
  • Responsabilização legal: Em casos de violação LGPD, reviewer é co-responsável perante a ANPD
  • Multas compartilhadas: Responsabilidade financeira pode ser compartilhada em casos de negligência grave

Exemplos de co-responsabilidade:

  1. Autor expõe dados sensíveis em código AI, reviewer aprova:

    • ❌ Autor: Suspensão 90 dias + possível rescisão
    • ❌ Reviewer: Suspensão 90 dias + possível rescisão
    • ❌ Ambos: Responsabilização legal LGPD

  2. Autor comita "fucking code" vulnerável, reviewer aprova:

    • ❌ Autor: Suspensão + retrabalho
    • ❌ Reviewer: Suspensão + perda de privilégio de review por 6 meses

  3. Código com SQL Injection aprovado vai para produção:

    • ❌ Autor: Advertência + retrabalho emergencial
    • ❌ Reviewer: Advertência + obrigatoriedade de treinamento de segurança

Justificativa:

O reviewer tem a responsabilidade FINAL de validar segurança e conformidade. Aprovar código inadequado é negligência equivalente a escrevê-lo.

5.1.3. Responsabilidades do Autor

Antes de submeter PR:

  • Marcar explicitamente código AI-generated em comentários
  • Executar todos os testes localmente
  • Validar com ferramentas de análise estática
  • Garantir compreensão 100% do código
  • Declarar que nenhum dado sensível foi exposto
  • Preencher template de PR completamente

5.2. Template de Pull Request

## Descrição
[Descrição clara da mudança]
 
## Tipo de Mudança
- [ ] Nova funcionalidade
- [ ] Correção de bug
- [ ] Refatoração
- [ ] Melhoria de performance
 
## Código AI-Generated
- [ ] Este PR contém código gerado por IA
- Ferramenta utilizada: [GitHub Copilot/Claude/ChatGPT/Cursor]
- Percentual de código AI: [XX%]
 
## Declaração de Conformidade
- [ ] Nenhum dado sensível foi utilizado em prompts
- [ ] Código revisado e compreendido completamente
- [ ] Testes criados e passando
- [ ] Documentação atualizada
- [ ] Checklist de segurança validado
 
## Checklist de Segurança
- [ ] Validação de input
- [ ] Sanitização de output
- [ ] Proteção SQL Injection
- [ ] Proteção XSS
- [ ] Auth/authz validadas
- [ ] Sem secrets hardcoded
 
## Notas para Reviewer
[Informações relevantes, áreas de atenção especial]

5.3. SLA de Review

  • Código não-crítico: 24 horas
  • Hotfixes: 4 horas
  • Código crítico: 48 horas (revisão aprofundada)

Se SLA não cumprido → Escalar para Tech Lead

5.4. Critérios de Aprovação

Aprovar SE e SOMENTE SE:

  • ✅ Todos os itens do checklist validados
  • ✅ Testes automatizados 100% passing
  • ✅ Sem vulnerabilidades conhecidas
  • ✅ Código compreensível e bem documentado
  • ✅ Performance aceitável
  • ✅ Conformidade com todas as Diretrizes de Desenvolvimento

Rejeitar SE:

  • ❌ Qualquer vulnerabilidade de segurança
  • ❌ Código incompreensível ou excessivamente complexo
  • ❌ Testes faltando ou falhando
  • ❌ Suspeita de uso de dados sensíveis
  • ❌ Violação de diretrizes de vibecoding
  • ❌ Não conformidade com diretrizes de desenvolvimento

5.5. Proteção do Reviewer - Aprovação Forçada

5.5.1. Cenário: Reviewer Obrigado a Aprovar Código Reprovado

Situação:

Você, como reviewer, identificou violações nas diretrizes e REPROVOU formalmente um Pull Request. Porém, você está sendo PRESSIONADO ou ORDENADO a aprovar o código mesmo assim.

Quem pode pressionar:

  • Diretor ou sócio da empresa
  • Gerente direto
  • Cliente interno com poder hierárquico
  • Qualquer pessoa em posição de autoridade

O que fazer:

⚠️ NUNCA APROVE código reprovado sem documentação formal. Você será co-responsável por qualquer incidente.

PROCEDIMENTO OBRIGATÓRIO:

  1. REPROVAR formalmente o Pull Request (manter reprovação)
  2. Documentar TODAS as violações identificadas
  3. Enviar email obrigatório para toda a diretoria (template abaixo)
  4. AGUARDAR decisão formal antes de qualquer ação
  5. NÃO APROVAR até ter ordem POR ESCRITO

5.5.2. Template de Email de Proteção

IMPORTANTE: Este email protege você legalmente e documenta que está sendo coagido a violar diretrizes.

Destinatários:

  • TODOS os membros da diretoria (sem exceção)
  • DPO (Data Protection Officer)
  • CTO / Tech Lead
  • ti@toolzz.me (compliance)

Assunto:

CÓDIGO REPROVADO - Aprovação ORDENADA por [CARGO/NOME] - ALERTA DE COMPLIANCE

Corpo do email:

Prezados Membros da Diretoria,

Eu, [NOME DO REVIEWER], [CARGO], realizei o code review do Pull Request #[NÚMERO]
submetido por [NOME DO AUTOR] em [DATA].

## ⚠️ SITUAÇÃO CRÍTICA

O código foi **FORMALMENTE REPROVADO** por mim conforme os critérios estabelecidos
nas Diretrizes de Desenvolvimento da empresa (disponíveis em /guidelines/).

**PORÉM, estou sendo ORDENADO/PRESSIONADO a APROVAR o código mesmo com as
violações identificadas.**

**Ordem recebida de:** [NOME], [CARGO]  
**Data da ordem:** [DD/MM/AAAA HH:MM]  
**Forma da ordem:** [Verbal/Email/Chat/Reunião]

Este email é enviado como **PROTEÇÃO LEGAL e REGISTRO DE COMPLIANCE** conforme
procedimento documentado em "5.5. Proteção do Reviewer" das Diretrizes de
Vibecoding Seguro.

## VIOLAÇÕES IDENTIFICADAS

Conforme as [Diretrizes de Desenvolvimento](/guidelines/introduction), o código
apresenta as seguintes não-conformidades:

### Segurança:
- [ ] Vulnerabilidades OWASP Top 10 identificadas: [Detalhar com exemplos]
- [ ] Validação de input inadequada: [Detalhar]
- [ ] Sanitização de output ausente: [Detalhar]
- [ ] Proteção SQL Injection inadequada: [Detalhar]
- [ ] Proteção XSS inadequada: [Detalhar]
- [ ] Secrets hardcoded: [Detalhar]
- [ ] Outras vulnerabilidades: [Detalhar]

### Qualidade:
- [ ] Código não segue padrões do projeto: [Detalhar]
- [ ] Complexidade ciclomática excessiva: [Detalhar]
- [ ] Código duplicado: [Detalhar]
- [ ] Tratamento de erros inadequado: [Detalhar]
- [ ] Performance inadequada: [Detalhar]

### Testes:
- [ ] Testes unitários ausentes ou inadequados: [Detalhar]
- [ ] Cobertura de testes abaixo de 80%: Atual: [XX%]
- [ ] Testes falhando: [Listar quais]
- [ ] Edge cases não cobertos: [Detalhar]

### Conformidade LGPD:
- [ ] Exposição de dados sensíveis: [Detalhar]
- [ ] Uso inadequado de dados pessoais: [Detalhar]
- [ ] Não conformidade com LGPD Art. [X]: [Detalhar]
- [ ] Falta de anonimização: [Detalhar]

### Conformidade Vibecoding:
- [ ] "Fucking code" detectado: [Detalhar complexidade excessiva]
- [ ] Uso de ferramenta não aprovada: [Qual ferramenta]
- [ ] Evidência de dados sensíveis em prompts: [Detalhar]
- [ ] Código não compreendido pelo autor: [Evidências]

## ANÁLISE DE RISCOS

### Risco de Segurança: [BAIXO/MÉDIO/ALTO/CRÍTICO]
**Descrição:** [Detalhar impacto potencial]  
**Probabilidade de exploração:** [Percentual ou qualitativo]  
**Impacto se explorado:** [Detalhar danos possíveis]

### Risco LGPD: [BAIXO/MÉDIO/ALTO/CRÍTICO]
**Artigos violados:** [Listar]  
**Dados em risco:** [Quantidade e tipo]  
**Multa potencial:** [Estimar valor conforme Art. 52]  
**Responsabilização:** [Criminal/Civil/Administrativa]

### Risco Operacional: [BAIXO/MÉDIO/ALTO/CRÍTICO]
**Impacto em produção:** [Downtime, perda de dados, etc.]  
**Sistemas afetados:** [Listar]  
**Clientes impactados:** [Quantidade estimada]

### Risco Reputacional: [BAIXO/MÉDIO/ALTO/CRÍTICO]
**Impacto na imagem da empresa:** [Detalhar]  
**Exposição midiática:** [Avaliar]  
**Perda de clientes:** [Estimar]

## DECLARAÇÃO DO REVIEWER

Eu, [NOME DO REVIEWER], declaro formalmente que:

1. ✅ Realizei code review completo e detalhado
2. ✅ Identifiquei e documentei TODAS as violações acima
3. ❌ **NÃO APROVO este código** em seu estado atual
4. ⚠️ Estou sendo **ORDENADO a aprovar** mesmo com violações
5. ⚠️ Compreendo que aprovar código inadequado me torna **CO-RESPONSÁVEL**
6. ⚠️ Este email serve como **ISENÇÃO DE RESPONSABILIDADE** caso seja ordenado a aprovar
7. ⚠️ Solicito **ORDEM POR ESCRITO** para qualquer aprovação forçada

## SOLICITAÇÃO FORMAL À DIRETORIA

Solicito formalmente que a diretoria:

### Opção 1: Corrigir Violações (RECOMENDADO)
- [ ] Retornar PR ao autor para correção
- [ ] Implementar todas as correções necessárias
- [ ] Submeter novamente para review
- [ ] Aprovar apenas se 100% conforme

### Opção 2: Aprovar com Ciência de Riscos (NÃO RECOMENDADO)
- [ ] Emitir **ordem formal POR ESCRITO** para aprovação
- [ ] Assumir integralmente os riscos identificados
- [ ] Registrar em ata de diretoria
- [ ] Implementar plano de mitigação emergencial
- [ ] **ISENTAR reviewer de co-responsabilidade**

### Opção 3: Cancelar Implementação
- [ ] Fechar PR sem merge
- [ ] Planejar solução alternativa
- [ ] Documentar lições aprendidas

## CONSEQUÊNCIAS PREVISTAS

**Se aprovado com violações:**
- Potencial incidente de segurança em [PRAZO estimado]
- Possível multa LGPD de até R$ [VALOR]
- Rescisão de contratos de clientes afetados
- Processo legal contra a empresa
- Danos à reputação irreversíveis

**Responsáveis legais:**
- Quem ordenou aprovação: [NOME]
- Autor do código: [NOME]
- Reviewer: [ISENTO se ordem por escrito]

## PRAZO PARA RESPOSTA

Aguardo decisão formal da diretoria em até **48 horas**.

Após este prazo sem resposta, considerarei o PR **REPROVADO DEFINITIVAMENTE**
e encerrarei o processo de review.

## REFERÊNCIAS

- [Diretrizes de Desenvolvimento](/guidelines/introduction)
- [Diretrizes de Vibecoding Seguro](/vibecoding/introduction)
- [Critérios de Code Review](/vibecoding/code-review)
- [Processo de Aprovação](/vibecoding/approval-process)
- [Restrições e Proibições](/vibecoding/restrictions)

## ANEXOS

- [ ] Screenshots do código com violações
- [ ] Logs de ferramentas de análise estática
- [ ] Relatório de testes (cobertura, falhas)
- [ ] Print da ordem recebida (se por escrito)

---

Atenciosamente,

[NOME DO REVIEWER]  
[CARGO]  
[EMAIL]  
[DATA E HORA]

---

⚠️ **ESTE É UM EMAIL DE COMPLIANCE OBRIGATÓRIO**  
⚠️ Enviado automaticamente conforme Diretrizes de Code Review (Seção 5.5)  
⚠️ Cópia permanente arquivada em ti@toolzz.me  
⚠️ Resposta obrigatória em até 48 horas

5.5.3. Após Envio do Email

O que acontece:

  1. Código permanece REPROVADO até decisão formal por escrito
  2. Reviewer está PROTEGIDO - não pode ser penalizado por reprovar
  3. Aguardar resposta da diretoria (SLA: 48 horas)
  4. Documentar tudo - manter prints, emails, mensagens

Possíveis Resoluções:

Resolução 1: Correção (Ideal) ✅
  • Autor corrige todas as violações
  • Código resubmetido para novo review
  • Aprovação normal se 100% conforme
  • Reviewer não tem responsabilidade adicional
Resolução 2: Ordem Formal de Aprovação ⚠️
  • Diretoria emite ORDEM POR ESCRITO
  • Ordem deve incluir:
    • Ciência completa dos riscos
    • Plano de mitigação
    • Isenção explícita do reviewer
    • Registro em ata de diretoria
  • Reviewer aprova sob ordem (isento de responsabilidade)
  • Toda responsabilidade recai sobre quem ordenou
Resolução 3: Cancelamento ❌
  • PR fechado sem merge
  • Solução alternativa planejada
  • Lições aprendidas documentadas

5.5.4. Sua Proteção Legal

Se você enviar o email conforme template:

✅ Você está PROTEGIDO de:

  • Co-responsabilidade por incidentes
  • Suspensão ou rescisão
  • Multas LGPD
  • Processos legais
  • Penalidades administrativas

✅ Você demonstrou:

  • Due diligence profissional
  • Conhecimento técnico
  • Cumprimento das diretrizes
  • Postura ética

⚠️ Proteção VÁLIDA apenas se:

  • Email foi enviado ANTES de aprovar
  • Todas as violações foram documentadas
  • Não houve negligência na identificação de problemas
  • Ordem formal por escrito foi recebida

5.5.5. O que NÃO fazer

❌ NUNCA:

  • Aprovar código reprovado sem enviar o email
  • Ceder a pressão verbal sem documentar
  • Aceitar "aprovar só dessa vez"
  • Confiar em promessas de "corrigir depois"
  • Ter medo de "desagradar" superiores
  • Pensar "não vai dar em nada"

💡 LEMBRE-SE: Sua carreira e liberdade valem mais que agradar um superior. Diretrizes existem para proteger você, a empresa e os clientes.

5.6. Consequências de Aprovação Inadequada

Para Reviewer que aprova código com violações SEM proteção formal:

SeveridadePrimeira VezReincidênciaGrave/LGPD
LeveAdvertência formalSuspensão 30 diasSuspensão 90 dias
ModeradaSuspensão 30 diasSuspensão 90 diasRescisão
GraveSuspensão 90 diasRescisãoRescisão + ação legal

Exemplos de severidade:

  • Leve: Aprovação de código sem testes adequados (sem impacto em produção)
  • Moderada: Aprovação de código com vulnerabilidade XSS em área não-crítica
  • Grave: Aprovação de código com exposição de dados LGPD ou SQL Injection

Isenção de responsabilidade:

O reviewer NÃO será penalizado SE:

  • Seguiu o procedimento de proteção (seção 5.5)
  • Enviou email de compliance ANTES de aprovar
  • Recebeu ordem formal POR ESCRITO
  • Documentou todas as violações

⚠️ REVIEWER: Você é responsável pelo código que aprova. Em caso de dúvida, REJEITE.

⚠️ SE FOR PRESSIONADO: Envie o email de proteção IMEDIATAMENTE. Sua carreira depende disso.

📋 DIRETORIA: Código de qualidade é não-negociável. Ordenar aprovação de código inadequado é assumir responsabilidade integral.

4. Boas Práticas de Vibecoding6. Exemplos de Uso