code-review-b2

name	code-review-b2
description	Revisão de código no padrão B2 Tech. Use quando o usuário pedir "revise o código", "code review", "audite essas mudanças" ou ao final de feature/PR. Aplica checklist de Vertical Slice Architecture, DDD, Security by Design e qualidade da stack Python/Flask + Next.js/TypeScript.
allowed-tools	Read, Grep, Glob, Bash

Code Review — Padrão B2 Tech

Esta skill orienta a revisão de código nos projetos da B2 Tech. Aplique o checklist abaixo de forma sistemática e objetiva, sem inventar problemas. Se algo está bom, diga que está bom.

Como conduzir a revisão

1. Identifique o escopo da mudança (git diff ou arquivos modificados).
2. Rode o checklist abaixo, anotando achados como 🔴 BLOCKER, 🟡 MAJOR, 🟢 NIT.
3. No fim, gere um sumário com decisão: APROVAR, APROVAR COM RESSALVAS, ou MUDANÇAS NECESSÁRIAS.

Checklist

1. Arquitetura (Vertical Slice + DDD)

• A mudança está num único slice/feature? Ou cruza fronteiras de forma indevida?
• Domain logic está isolado de infra (sem chamadas a banco/HTTP dentro de entities)?
• Application services orquestram, não implementam regras de domínio.
• Repositórios têm interface no domínio e implementação na infra.
• Sem leakage de detalhes de framework (Flask request, Next.js Request) no core.

2. Security by Design

• Inputs externos são validados na borda (Pydantic, Zod, etc).
• Queries usam parametrização (sem string interpolation em SQL).
• Secrets vêm de env/Secret Manager — nunca hardcoded.
• AuthN/AuthZ aplicada antes do business logic, não depois.
• Logs não expoem PII, tokens ou segredos.
• Headers de segurança presentes em endpoints públicos (CSP, HSTS, X-Content-Type-Options).

3. Qualidade da stack

Python/Flask:

• Type hints em funções públicas.
• ruff check passa sem warnings.
• Sem mutable default args.
• Context managers em recursos (DB, files, locks).

Next.js/TypeScript:

• Tipos explícitos nas APIs públicas (sem any).
• Server Components onde faz sentido (não força "use client" sem necessidade).
• Sem fetch sem error handling.
• Edge cases de loading/error tratados.

4. Testes

• Cobre o caso feliz e ao menos um edge case por nova função pública.
• Testes lêem como spec (nome do teste descreve o comportamento, não a implementação).
• Sem mocks excessivos (sinal de acoplamento).

5. Operacional

• Observabilidade: logs estruturados em pontos de decisão.
• Errors propagam com contexto (não engole exceção sem logar).
• Migrations reversíveis (UP + DOWN).
• Feature flags para mudanças de risco em prod.

Formato do output

## Code Review — <branch/PR>

**Escopo:** <breve descrição em 1 linha>

### 🔴 Blockers
- [arquivo:linha] descrição + sugestão

### 🟡 Major
- [arquivo:linha] descrição + sugestão

### 🟢 Nits
- [arquivo:linha] descrição

### ✅ Pontos positivos
- <o que ficou bem feito>

### Decisão
**APROVAR | APROVAR COM RESSALVAS | MUDANÇAS NECESSÁRIAS**

O que NÃO fazer

• Não invente problemas pra parecer rigoroso.
• Não reescreva o código todo — sugira a mudança mínima.
• Não bloqueie por estilo se prettier/ruff já aceita.
• Não duplique o que linters/typecheck já pegam — foque no que humano precisa ver.

Referências adicionais

Para regras específicas de stack, consulte:

• references/python-flask-checklist.md (se existir)
• references/nextjs-checklist.md (se existir)
• references/security-deep-dive.md (se existir)