Feche um bug direto do ticket

Quando usar a squad de bug a partir do ticket?

Use para bugs que já estão descritos num tracker e dá para reproduzir no código. A squad impõe a disciplina que a maioria das correções rápidas pula: provar o bug com um teste falhando, corrigir a causa e deixar outro ler a correção.

• Encaixa bem: bug de backend com passos claros, como duplicidade, total errado ou corrida em retry.
• Encaixa bem: regressão com referência conhecida do tipo "funcionava na versão X".
• Não encaixa: relato vago ("o checkout está lento"). Transforme numa meta mensurável e use a melhor de três.

Como montar a squad?

Abra Squads → Nova squad, escolha Personalizado e cole a URL do ticket em Link da tarefa (opcional). O campo aceita links do GitHub, GitLab, Linear e Jira; qualquer outro mostra "Use um link do GitHub, GitLab, Linear ou Jira." O Personalizado começa com um membro vazio, então adicione três e escreva a função de cada um.

Qual objetivo colar?

Reescreva o bug em poucas linhas, mesmo com o link, e deixe clara a ordem do trabalho. Depois escreva as Instruções do líder: o Personalizado não traz nenhuma por padrão.

Corrigir ENG-482: retries do webhook criam pedidos duplicados.

O que sabemos
- O provedor de pagamento reenvia order.paid quando nosso endpoint demora.
- Cada reenvio cria um pedido novo com o mesmo id de evento.

Pronto quando
- Um teste de regressão envia o mesmo evento duas vezes e gera um pedido só.
- Os testes de pedido existentes passam. Sem sleeps nem gambiarras de retry.
- O relatório diz a causa raiz em uma frase.

Instruções do líder
Reproduza primeiro. Só inicie quem corrige depois que o teste de quem
reproduz falhar pelo motivo descrito no ticket. Depois mande a correção
e o teste para o revisor. Se o revisor pedir mudanças, devolva para quem corrige.

Quais limites definir?

Coloque 4 rodadas e 3 membros ao mesmo tempo. O trabalho é quase todo sequencial, então rodadas pesam mais que vagas em paralelo: uma para reproduzir e corrigir, uma ou duas para o feedback da revisão, uma de folga.

Cole o link do próximo ticket numa squad e deixe ela reproduzir o bug primeiro.

Baixar o Tallos →

Como a execução acontece?

Uma execução de exemplo com um ticket do Linear. Ticket, código e diff são ilustrativos.

1. 1

   O líder lê o ticket

   Abre o ENG-482 e planeja: reproduzir primeiro, depois corrigir, depois revisar.

2. 2

   Reproduzir

   Quem reproduz escreve um teste que falha: o mesmo id de evento cria dois pedidos.

3. 3

   Corrigir

   Quem corrige adiciona uma chave de idempotência na criação do pedido. O teste passa.

4. 4

   Revisar

   O revisor aprova e sugere um índice único no banco como proteção extra.

5. 5

   Uma pergunta para você

   O índice único entra nesta mudança ou numa migration separada? Você responde: separada.

6. 6

   Relatório

   O líder entrega o relatório com tallos squad report e a execução espera a sua revisão.

O que o líder pode te perguntar?

Squads de bug perguntam sobre escopo e sobre fatos que o ticket deixou de fora. O líder pergunta com tallos squad ask; você escolhe uma opção ou digita a sua.

• "Coloco o índice único nesta mudança ou numa migration separada?"
• "Os passos do ticket não reproduzem localmente. Você tem um payload de exemplo?"
• "Já existem duplicados em produção. Limpo aqui ou deixo para o time de operações?"

O que você recebe no final?

• Relatório final: causa raiz, correção, teste de regressão e riscos em aberto. No exemplo: a criação de pedido não tinha chave de idempotência, então cada reenvio criava um pedido; teste de regressão adicionado; índice único deixado para uma migration separada.
• Resultados por worktree: o worktree de quem corrigiu, marcado como Recomendado, com Ver alterações.
• Aceitar ou Descartar: Aceitar transforma a linha recomendada em Abrir para criar PR. Vincule o PR ao ticket como você já faz.

Antes de aceitar, confira se o teste falha sem a correção. O guia de como revisar código gerado por IA mostra o que mais olhar.

Quais variações funcionam bem?

• Dois membros corrigindo. Quando a causa raiz não é clara, coloque Quantos = 2 em quem corrige e peça ao líder para comparar, como na melhor de três.
• Sem quem reproduz. Para um bug que já tem teste falhando, use a construir e revisar com o link do ticket.
• Salve uma vez. Salvar como squad guarda os três papéis. No próximo bug, mude só o link e o objetivo.

Quais são os erros mais comuns?

• Colar só o link. Se o agente não consegue ler o ticket, o líder está chutando. Reescreva o bug no objetivo.
• Corrigir antes de reproduzir. Sem um teste falhando, não dá para diferenciar correção de coincidência. Diga a ordem nas instruções do líder.
• Aceitar remendo de sintoma. Proíba no objetivo sleeps, retries e try/catch que engole erro.
• Confiar cegamente no ticket. O texto do ticket entra no contexto do líder. Leia antes de começar.

Primeira vez? Siga sua primeira squad, veja como as squads funcionam ou como o líder conversa com o Tallos pela CLI do Tallos.