yurgeno/taut-data-community

dev-review — o revisor (estágio 3)

Olhos independentes sobre a mudança. Revise o DIFF contra a TAREFA — não o diff contra o nada.

Invocação	dev-review <TAREFA>
Entrada	diff da árvore de trabalho + memory/spec/<TAREFA>/analysis.md e implementation.md
Saída	memory/spec/<TAREFA>/review.md, status: draft, veredito approva / precisa de alterações
Portão	o proprietário aceita o veredito — veja O portão do proprietário abaixo
Próximo	precisa de alterações → dev-implement <TAREFA> novamente; aprova → o proprietário finaliza

0. Verificação de entrada

• Nenhuma <TAREFA> fornecida → pergunte.
• implementation.md ausente ou vazio → pare: ainda não há nada para revisar.
• implementation.md ainda com status: draft → informe e revise de qualquer forma se o proprietário solicitar, mas registre no veredito que o estágio 2 não passou pelo seu portão.
• Leia a análise ANTES do diff. Julgar uma mudança sem saber o que foi pretendido gera comentários de estilo e perde o achado importante.

Processo (universal)

1. Re-derive a intenção a partir da tarefa e da análise; depois julgue se o diff a alcança. Uma mudança bonita no lugar errado é um achado crítico.

2. Correção em primeiro lugar: casos de borda, caminhos de erro, concorrência, formatos de dados nas fronteiras. Depois convenções e clareza. Apenas nits de estilo por último e marcados como tal.

3. Não confie na evidência do implementador — reproduza-a. Reexecute você mesmo a verificação decisiva (delegue ao subagente dev-reviewer quando a suíte for longa). As notas de implementação dizem o que foi executado; seu trabalho é verificar se ainda é válido e se foram executadas as COISAS CERTAS.

4. Verifique o raio de impacto: o que mais consome o código alterado? Pesquise usos que o diff não tocou; alterações não intencionais em lockfile / config / arquivos gerados são achados.

5. Achados, não correções. Relate por severidade (crítico / deve corrigir / nit) com arquivo e linha; correções mecânicas triviais PODEM ser aplicadas diretamente, todo o resto volta para dev-implement. Escreva o veredito em memory/spec/<TAREFA>/review.md, começando com:

   ---
   task: <TAREFA>
   stage: review
   status: draft
   verdict: approve | needs-changes
   ---
   

Verificações de revisão específicas de stack

node: escapes de tipo (any, as, @ts-ignore) introduzidos pelo diff; cadeias de promise sem tratamento de erro; dependência não intencional ou deriva de lockfile; edições em monorepo que ignoram o gráfico do projeto (imports relativos profundos entre pacotes).

jvm: nulidade nas novas fronteiras (tipos de plataforma Kotlin, uso incorreto de Optional); gerenciamento de recursos (try-with-resources / use); escopo de transação e DI de novos beans; testes colocados para realmente executar (módulo certo, convenção de nomenclatura certa).

android: verifique o ciclo de vida, não apenas a lógica — trabalho iniciado em um composable ou Activity deve sobreviver à rotação e parar quando o escopo morrer (coletar em repeatOnLifecycle/collectAsStateWithLifecycle, cancelar coroutines com o escopo certo). Um Context mantido em um objeto de longa duração é um vazamento. Novas permissões em AndroidManifest.xml também precisam do caminho de solicitação em tempo de execução; APIs acima de minSdk precisam de um portão explícito. Builds de release diferem de debug — regras R8/ProGuard para qualquer coisa reflexiva (serialização, Room, DI) fazem parte da mudança. E pergunte se os testes instrumentados foram realmente EXECUTADOS: são os que o CI mais frequentemente pula.

php: declare(strict_types=1) e tipos de parâmetro/retorno em código novo; superfícies de injeção (SQL bruto, saída não escapada) nos caminhos tocados; supressão de erro (@) introduzida pelo diff; alterações de config/DI consistentes com as convenções do framework.

python: tipagem nas novas fronteiras (Any, tipos de retorno ausentes, # type: ignore introduzido pelo diff); argumentos padrão mutáveis e estado mutável em nível de classe; recursos fechados (with para arquivos e conexões) e chamadas async realmente aguardadas; tratamento de exceção que engole (except Exception: pass); manifesto e lock alterados juntos (pyproject.toml vs uv.lock / poetry.lock) ou nenhum; Django: uma migração para cada alteração de modelo, reversível; testes colocados onde o executor os encontra (tests/, test_*.py, fixtures conftest.py) e não pulados por um marcador desatualizado.

O portão do proprietário

PARE aqui — o revisor nunca finaliza a mudança e nunca a reimplementa. Relate o veredito em duas frases com os achados que o motivam.

• precisa de alterações → o proprietário decide; sob sua palavra, o loop volta para dev-implement <TAREFA>, que anexa a implementation.md em vez de começar do zero. review.md permanece como o registro do que estava errado.
• aprova → com a aceitação explícita do proprietário, defina status: approved. Finalizar a mudança (commit, branch, push) é um ato do proprietário sob a lei git do workspace — não desta habilidade.

Concluído quando

review.md carrega seu frontmatter e o veredito com achados por severidade, a verificação decisiva foi reexecutada POR VOCÊ, e o resumo do chat fornece o veredito em duas frases. Aprove apenas o que você defenderia em uma post-mortem de outra pessoa.