Construir + revisar: refatore com um revisor de olho

Quando usar uma squad construir + revisar?

Use quando a mudança é arriscada a ponto de você querer que outro agente leia antes de você. Um constrói, o outro questiona, e o ciclo roda sem você até ter algo que valha o seu tempo.

• Refatorações e migrações: autenticação, camada de dados, upgrade de framework.
• Mudanças sensíveis de segurança: tokens, permissões, tratamento de entrada.
• Qualquer coisa que você nunca mesclaria sem review de alguém do time.
• Não serve para explorar várias abordagens. Para isso existe a melhor de três.

Como montar a squad?

Abra Squads → Nova squad e escolha Construir + revisar. O template já vem com quem constrói ("Faz o trabalho descrito no objetivo") e um revisor ("Revisa o resultado e lista o que precisa mudar antes de ser aprovado"). Mantenha o primeiro como está. Deixe o revisor específico: diga o que ele deve procurar.

Qual objetivo colar?

Descreva o estado final, as restrições e o que o revisor precisa checar. Quanto mais claro o critério de revisão, menos rodadas você gasta.

Migrar a autenticação de sessões no servidor para JWTs assinados.

Escopo
- Emitir e validar tokens em src/auth. Substituir o middleware de sessão.
- Atualizar todos os pontos que leem req.session.user.

Restrições
- As chaves de assinatura vêm do carregador de segredos atual. Nunca commitar chaves.
- O logout precisa invalidar o token no servidor.
- Todos os testes de auth passam; adicionar testes de expiração e logout.

Critério de revisão
- O revisor só aprova quando expiração, rotação de chaves e
  invalidação no logout estiverem cobertas por testes.

As Instruções do líder do template já descrevem o ciclo: enviar para quem constrói, pedir a revisão, devolver as mudanças, repetir até aprovar. Pode manter.

Quais limites definir?

Mantenha 5 rodadas e coloque 2 membros ao mesmo tempo. Cada passada de construir → revisar consome uma rodada, então cinco dão espaço para duas ou três voltas de feedback e uma de folga.

Coloque um revisor na sua próxima refatoração. Monte no Tallos em poucos minutos.

Baixar o Tallos →

Como a execução acontece?

Uma execução de exemplo, passo a passo. A contagem de pontos alterados e os apontamentos são ilustrativos, não medições.

1. 1

   O líder envia o objetivo para quem constrói

   Quem constrói começa no próprio worktree, separado do seu checkout.

2. 2

   A entrega

   No exemplo: emissão e validação de JWT, middleware novo, 42 pontos de chamada atualizados.

3. 3

   O revisor questiona

   Três mudanças obrigatórias: rotacionar as chaves de assinatura, encurtar a validade do access token, revogar tokens no logout.

4. 4

   Rodada 2

   O líder devolve as três mudanças para quem constrói, que aplica e adiciona testes.

5. 5

   Uma pergunta para você

   O líder pergunta se as sessões atuais continuam válidas durante uma janela de migração de 24 horas. Você responde: sim, 24h.

6. 6

   Rodada 3: aprovado

   O revisor aprova. O líder entrega o relatório com tallos squad report e a execução mostra Pronto para sua revisão.

O que o líder pode te perguntar?

As perguntas numa construir + revisar costumam ser de rollout e de política, coisas que o revisor aponta mas não decide. Você escolhe uma opção ou escreve a sua.

• "Manter as sessões antigas válidas por uma janela de 24h ou forçar todo mundo a logar de novo?"
• "O revisor quer uma lista de revogação. Guardar no Redis ou no banco?"
• "Dois pontos de chamada ficam num módulo obsoleto. Atualizo ou apago o módulo?"

O que você recebe no final?

• Relatório final: o que mudou, o veredito do revisor, riscos em aberto e o que conferir. No exemplo: rotação de chaves com access tokens de vida curta, lista de revogação no logout, janela de 24h para as sessões atuais.
• Resultados por worktree: o worktree de quem construiu, marcado como Recomendado, com Ver alterações.
• Aceitar ou Descartar: Aceitar transforma a linha recomendada em Abrir para criar PR. Descartar mantém os worktrees, a menos que você escolha apagar os dos membros.

A aprovação do revisor não é a sua. Leia o diff na revisão de diff com o checklist de como revisar código gerado por IA.

Quais variações funcionam bem?

• Dois revisores. Adicione um revisor de performance ao lado do de segurança e suba para 3 membros ao mesmo tempo.
• Revisor que roda os testes. Escreva na função do revisor: "Roda a suíte completa e cola a saída. Só aprova com tudo verde."
• Coloque numa agenda. Salve a squad e rode todo dia útil, como a squad de manutenção agendada.
• Parta para uma divisão maior. Para uma mudança com várias partes independentes, use a squad de entregar uma feature e adicione um membro revisor.

Quais são os erros mais comuns?

• Revisor sem critério. "Revise o código" abre espaço para detalhismo infinito que come rodadas. Diga o que bloqueia a aprovação.
• Poucas rodadas. No limite, o líder reporta o que tem, mesmo sem aprovação. Procure apontamentos em aberto no relatório.
• Escopo crescendo na revisão. Se o revisor pedir limpezas sem relação com a tarefa, responda ao líder: fora do escopo.
• Achar que aprovação é merge. Nada é mesclado até você aceitar e abrir o PR.

Chegando agora? Comece por sua primeira squad ou pela visão geral de squads.