Por que criei o BugDump: «não funciona» não é um relatório de bug

ferramentas de desenvolvimentoDenis Povarov20 de agosto de 2026

Você conhece a mensagem. Ela chega numa sexta à tarde.

«Oi, o site está quebrado.»

Então você responde. Qual página? O que você estava fazendo? Qual navegador? Pode mandar uma captura de tela? Apareceu algum erro no console — na verdade, deixa para lá, vou explicar como abrir o console.

Quatro mensagens depois, você descobre que era o Safari num iPad, numa página que você nunca testou naquela largura, e que o «erro» era um 502 que se resolveu sozinho vinte minutos atrás. A informação de que você precisava existiu. Existiu no navegador do usuário, no momento em que quebrou, e depois sumiu.

A distância

Existe uma assimetria permanente no relato de bugs. Quem vive o bug tem todas as evidências e não reconhece nenhuma delas. Quem consegue corrigir o bug reconhece todas e não tem nenhuma.

Toda ferramenta de relatório de bugs é uma tentativa de cobrir essa distância. A maioria faz isso pedindo ao usuário que carregue as evidências até o outro lado, o que falha, porque o usuário não sabe o que é evidência.

Pedir a um usuário que descreva um bug é pedir que ele faça a parte mais difícil da depuração — decidir o que é relevante — sem nada do contexto que torna isso possível. Ele diz que o botão não funciona. Não diz que a requisição retornou 500, porque nunca viu isso.

O caminho inverso

Então não pergunte.

As evidências já estão no navegador. O console tem o erro. O log de rede tem a requisição que falhou. O DOM tem o layout na largura em que quebrou. O usuário está parado no meio de uma cena de crime completa, sem conseguir ver nada dela.

A premissa do BugDump é que o único trabalho do usuário deveria ser clicar num botão e dizer, com as próprias palavras, o que deu errado. Todo o resto é coletado sem perguntar:

Logs do console, inclusive de antes de o widget ser aberto
Requisições de rede, com status e tempo
Um replay de sessão do DOM
Os cliques, as entradas de texto e a navegação do usuário, em ordem
Navegador, sistema operacional, viewport, URL da página
Uma captura de tela que ele pode anotar — e desfocar antes que ela saia da máquina dele

O usuário escreve «o botão não funciona». Você recebe essa frase junto com uma resposta 500, um stack trace e um replay dos doze segundos antes de ele desistir.

O que muda

O ganho óbvio é velocidade. Relatórios que exigiam quatro idas e vindas antes de alguém poder agir já chegam prontos.

O ganho mais sutil é volume. A maioria dos bugs nunca é reportada. Não porque os usuários não se importem, mas porque reportar é caro — preencher um formulário, explicar o contexto, responder perguntas e, provavelmente, nunca ter retorno. Os usuários fazem uma conta rápida e decidem que não vale a pena. Simplesmente param de usar o recurso quebrado.

Quando reportar custa um clique, essa conta muda. Você fica sabendo dos bugs que ninguém achava que valia a pena mencionar, e muitas vezes são justamente eles que estão fazendo você perder usuários em silêncio.

Fechar o ciclo também importa. Um relatório enviado para o vazio ensina as pessoas a não reportar. Por isso o BugDump dá a cada projeto um portal público, onde quem reportou acompanha a tarefa ir de Confirmado para Concluído. Quem vê o próprio relatório ser corrigido envia o próximo.

A parte que eu não esperava

Construí primeiro a camada de captura, porque esse era o problema óbvio. Depois, outra coisa ficou óbvia.

Quando um relatório contém telemetria completa e estruturada, ele deixa de ser só documentação para uma pessoa. Vira uma entrada bem formada para um agente de IA.

Então lancei um servidor MCP. O Claude Code se conecta ao BugDump e lê tarefas, relatórios e a telemetria completa diretamente. O fluxo vira:

Veja a tarefa #42 no BugDump e corrija.

O agente puxa o erro do console, encontra a requisição que falhou, localiza o código correspondente e propõe uma correção. Você nunca abre o painel.

Isso só é possível porque o relatório está completo. Um agente não pode perguntar ao usuário qual navegador ele estava usando. Ele tem uma única chance com as evidências, o que significa que elas precisam estar lá por inteiro — a mesma propriedade que torna um relatório bom para uma pessoa o torna utilizável por uma máquina.

Em que pé está o BugDump

O BugDump v1.0 está no ar. Uma tag de script, um quadro de triagem, oito integrações, webhooks e o servidor MCP. O plano Grátis é um plano de verdade — 500 relatórios por projeto, para sempre, sem cartão.

Estou construindo isso em público. O registro de alterações é público, o roteiro é público e o quadro de feedback está aberto. Se falta à ferramenta algo de que o seu fluxo precisa, me conte — de preferência pelo widget, assim eu recebo o log do console também.