Documentação / Como trabalhar

Anti-padrões

Os erros de orquestração que já custaram caro — o sintoma, por que acontece e o que fazer no lugar.

Cada item abaixo aconteceu num board de verdade. Nenhum é hipotético, e quase todos parecem razoáveis na hora.

Aceitar o relatório como fato

Sintoma: o card diz “todos os testes passam” e a árvore está vermelha.

Relatório é registro, não verificação. Quando a afirmação tem consequência, confira: o diff, o gate rodado de novo, a linha no banco. Revisar o diff pessoalmente acha defeito que os testes do próprio card não pegam — o teste que confere a presença de um mecanismo passa com o mecanismo errado.

Rodar a suíte na árvore compartilhada e acreditar

Sintoma: falha que não é sua, ou verde que não é real.

Com vários cards editando o mesmo repositório, a árvore é a soma do trabalho de todos, pela metade. Uma falha suspeita se refaz num worktree limpo no HEAD, com só os arquivos da fatia aplicados.

Mutar código na árvore compartilhada

Sintoma: o card testa se o teste pega o defeito, e três outros cards ficam vermelhos no meio do caminho.

Prova de mutação é boa prática; fazê-la onde os outros estão trabalhando não é. Mutação sempre numa cópia — worktree ou diretório descartável.

Mexer no que é do dono

Sintoma: um diagnóstico lê o banco vivo, um smoke abre a instância que o dono está usando, uma busca varre o diretório pessoal inteiro.

Diagnóstico em cópia do banco, apagada depois. Smoke em instância isolada, com perfil temporário destruído no fim. Busca mirando o arquivo declarado, nunca recursiva no $HOME — um card já despejou log de sessão alheio assim.

Brief sem “como”

Sintoma: “meça X” vira doze sondas em vinte segundos; “mexa só nesta região” vira uma segunda fonte de verdade ao lado da primeira.

O contrato diz o defeito medido, a fronteira, a decisão que você ainda não tomou e a forma do relatório. Ver Escrever um contrato.

Repetir o enunciado a cada mensagem

Sintoma: o orquestrador reescreve o brief inteiro para cada card, e duas versões da mesma task divergem.

A task é a fonte. A mensagem ao card aponta para ela e traz só o que o enunciado ainda não tem.

Pedir uma confirmação que o card não consegue dar

Sintoma: o mesmo relatório chega duas, três vezes, cada uma pedindo para ignorar a anterior.

Se o card não tem como saber que a entrega chegou, ele repete para ter certeza. Um relatório, por um canal que funciona para aquele provider — e não uma verificação que sempre dá timeout.

Confiar no rótulo depois de um crash

Sintoma: a próxima task vai para o card certo pelo nome e cai na sessão errada.

Depois de um crash ou restart, confira o scrollback de cada card antes de mandar a próxima mensagem: a sessão restaurada pode não ser a daquele card, ou pode ter voltado de um ponto antigo.

Fechar o card morto sem ler

Sintoma: o substituto refaz do zero um achado que o primeiro já tinha.

Card que morre por cota não reporta, mas o trabalho está no scrollback. Leia antes de fechar e passe o achado adiante, marcado como “confirmar”.

Um veredito que ninguém deu

Sintoma: a task aparece aprovada, e quem aprovou foi o próprio implementador.

Autoavaliação não é revisão. Quando a task pede review, só um card ligado como revisor fecha — e o orquestrador que revisou se liga como revisor para assinar, em vez de escrever done por fora.