O segundo terminal

Eu costumo trabalhar com duas sessões do Claude Code abertas ao mesmo tempo. A primeira implementa. A segunda recebe o diff pronto e tenta encontrar o que a primeira deixou passar.

Faço essa separação porque um agente pode entregar código que parece certo, com testes verdes e um resumo convincente, e ainda assim errar. Quem acabou de escrever também tende a enxergar a própria solução com menos distância.

Papéis separados#

O primeiro terminal é o builder. Ele recebe a tarefa, escreve o código e roda os próprios testes. O segundo é o verificador. Ele não altera o código de produção; começa pelo diff e revisa o resultado por conta própria.

Essa distância muda a revisão. O verificador não acompanhou cada escolha do builder e não precisa defender o caminho usado. Ele segue uma lista simples:

• roda typecheck, lint, testes e build de novo;
• lê cada linha alterada em vez de usar o resumo como prova;
• repete auditorias de Lighthouse, contraste e links quando elas fazem parte da tarefa;
• confere se cada arquivo alterado tem relação com o pedido.

Depois dessa revisão, eu decido se o trabalho pode virar commit ou se precisa voltar para o builder.

Regras compartilhadas#

Os dois terminais recebem as mesmas regras do projeto. A fonte canônica é o AGENTS.md, espelhado em CLAUDE.md para as ferramentas que usam esse arquivo. A base tem quatro princípios:

## Camada base
 
1. Think before coding: não assuma, exponha tradeoffs, pergunte
2. Simplicity first: o mínimo que resolve, nada especulativo
3. Surgical changes: toque só no que o pedido exige
4. Goal-driven: defina o critério de sucesso, faça loop até verificar

Depois vêm as regras específicas do site: decisões já tomadas, antipadrões, i18n simétrico, preferência por Server Components, tokens do design system e os hot files, que exigem confirmação antes de qualquer edição.

Manter isso no repositório evita depender da memória de uma sessão. Cada agente começa com as mesmas restrições e os mesmos critérios de pronto.

Decidir antes de implementar#

Quando uma escolha muda o resultado, eu resolvo antes de abrir o diff. O builder faz uma pergunta por vez, explica a recomendação e espera a decisão. O que pode ser descoberto no repositório não vira pergunta; ele investiga primeiro.

Isso reduz o risco de implementar uma interpretação inteira e descobrir no final que o pedido era outro.

O que vira proteção automática#

Regras mecânicas ficam em hooks e permissões, não em lembretes:

// .claude/settings.json
"deny": [
  "Bash(rm -rf *)",
  "Bash(git push --force*)",
  "Bash(git reset --hard*)"
]

Os hooks confirmam hot files antes da edição e rodam lint e formatação depois de cada escrita. Assim, a proteção continua funcionando mesmo quando ninguém lembra de mencioná-la no prompt.

Um caso que justificou o fluxo#

Em uma auditoria do Lighthouse, as páginas passaram o limite de 95 em todas as categorias. O verificador abriu os resultados individuais mesmo assim e encontrou dois problemas de acessibilidade que a nota agregada não deixou claros. Um comentário de código estava em 3.74:1, abaixo dos 4.5:1 exigidos pelo WCAG AA. Três controles tinham texto visível diferente do nome acessível.

Um problema tinha peso zero no cálculo da nota. O outro reduziu uma página apenas para 96. Os dois passaram pelo builder e pelo score, mas apareceram quando a segunda sessão leu as verificações com mais cuidado.

Foi por isso que mantive o segundo terminal. Eu leio o resumo do agente para entender o que ele tentou fazer, mas decido pelo diff e pelos checks repetidos.