Toda equipe tem uma versão desta história. Alguém relata que o PDF da fatura sai com o logo errado. O designer joga o arquivo certo no Slack. O QA grava a tela e coloca o vídeo no drive compartilhado. O cliente manda o manual da marca por e-mail. Três semanas depois o ticket volta, e os quatro arquivos que o explicam estão em quatro lugares, dois dos quais já expiraram.
O relatório de bug está no tracker. As evidências estão em todo o resto.
Por que os anexos se espalham
Os arquivos acabam fora do bug por motivos que, cada um no seu momento, fazem sentido.
O arquivo chega antes do bug. Um designer manda a especificação enquanto o problema ainda é uma conversa num canal. Ainda não existe ticket onde anexá-la, então ela fica onde caiu.
A ferramenta atrapalha. Se anexar significa baixar de um app e subir em outro, as pessoas colam um link. Links para threads de chat apodrecem mais rápido que qualquer outra coisa num fluxo de trabalho.
O chat parece o caminho mais rápido. E é, para quem envia. O custo cai em quem pegar o bug no mês que vem.
Ninguém nunca decidiu onde os arquivos ficam. Sem uma regra, cada um aplica a sua, e cada uma delas, isoladamente, é razoável.
Quanto custa essa dispersão
O custo óbvio é tempo. Alguém pede de novo um arquivo que já existe, e espera.
O segundo custo é pior: uma correção é feita com base na referência errada, porque a certa estava numa thread que ninguém encontrou. O código está certo e o resultado continua errado.
O terceiro custo é silencioso. Um bug difícil de reconstruir é adiado em vez de corrigido e depois reabre com ainda menos contexto do que tinha da primeira vez.
O que deve ficar no bug
Nem tudo. Uma tarefa com vinte anexos é quase tão útil quanto uma sem nenhum. O teste é se o arquivo responde a uma pergunta que a próxima pessoa vai de fato ter.
A referência. O design, o mockup, o parágrafo da especificação que diz qual comportamento é o correto. A maioria das divergências sobre um bug acaba sendo divergência sobre a intenção.
Evidências que a captura automática não alcança. Uma foto da tela de um celular, um vídeo de uma interação com hardware, o PDF que o seu app gerou.
Dados que reproduzem o bug. O CSV que quebra o importador, a configuração que provoca o crash, depois de limpos de dados sensíveis.
Contexto do servidor. O log da aplicação do mesmo minuto do relatório, quando o lado do navegador sozinho não explica o que aconteceu.
O que não deve ficar
Segredos. Tokens, credenciais, registros reais de clientes. Um anexo é exatamente tão visível quanto a tarefa em que está, e tarefas são compartilhadas.
Qualquer coisa que se gera de novo sem esforço. Uma captura de tela de uma página que qualquer pessoa abre em cinco segundos é ruído na lista.
Arquivos compactados inteiros. Uma pasta de 200 MB anexada «só por garantia» é um arquivo que ninguém nunca vai abrir. Extraia a parte que importa e anexe só ela.
Quatro hábitos que mantêm isso funcionando
Anexe na hora de pedir. Quando você pedir a especificação a um colega, peça para ele colocá-la na tarefa em vez de mandar para você. Uma frase a mais, e o arquivo fica onde a próxima pessoa vai procurar.
Dê aos arquivos nomes que se expliquem sozinhos na lista. correct-invoice-logo.svg é melhor que Screenshot 2026-03-04 at 14.22.11.png. Alguém deveria conseguir passar os olhos pela lista de anexos sem abrir nada.
Diga por que o arquivo está ali. Uma linha na descrição que cita o anexo transforma uma pilha de arquivos num argumento. «O cabeçalho deve ficar igual ao segundo frame do arquivo de design» vale muito mais que o arquivo de design sozinho.
Remova arquivos que deixaram de ser verdade. Um mockup ultrapassado que continua anexado vai acabar sendo usado por alguém. Excluí-lo faz parte de terminar a correção.
Como isso funciona no BugDump
Os relatórios chegam com as evidências já anexadas: logs do console, requisições de rede, replay de sessão, uma captura de tela, o ambiente em que o usuário estava. Isso cobre o que aconteceu no navegador. Não cobre o que deveria ter acontecido, e essa é a metade que os seus próprios arquivos fornecem.
Toda tarefa tem uma seção Anexos abaixo da descrição. Você pode anexar arquivos ao criar a tarefa, adicionar mais depois pela página da tarefa ou pelo painel lateral do quadro, ou arrastar um arquivo da área de trabalho e soltá-lo em qualquer lugar da tela da tarefa.
Os arquivos que vivem dentro da descrição (uma imagem que você colou, um chip de documento no texto) também aparecem ali, agrupados à parte, porque são removidos editando o texto a que pertencem, e não pela lista.
Há um benefício menor que acabou importando mais do que eu esperava. Quando um agente de IA lê um bug pelo servidor MCP, ele agora vê os anexos da tarefa além dos relatórios. Um agente que consegue ler a especificação que você anexou argumenta com as mesmas evidências que você usaria.
A regra por trás de tudo
Coloque o arquivo onde a pergunta vai ser feita.
«Como isso deveria ficar?» é uma pergunta feita no bug, meses depois de o design ter sido enviado, por alguém que não estava na conversa original, no momento em que essa pessoa está decidindo o que construir. É o único lugar onde a resposta serve para alguma coisa.
Leia também
Como escrever um bom relatório de bug (com checklist) — o que separa um relatório que é corrigido de um que é fechado como «não reproduzível».
O que fazer com um relatório de bug que você não consegue reproduzir — as causas mais comuns e o contexto que resolve a maioria delas.
Campos personalizados no bug tracker: o que adicionar e o que evitar — o teste que separa um campo que vale a pena de um que vai estar vazio em seis semanas.