Sobre o projeto

Bug Manager é uma demonstração totalmente simulada, baseada em navegador, de gerenciamento de bugs por agentes, publicada como o complemento público de um estudo de caso. Nada na demonstração varre código real, chama um modelo de linguagem ou faz uma requisição de rede: cada repositório, achado, pull request e ticket é gerado no navegador, e uma semente fixa sempre produz os mesmos 156 achados. O que a demonstração mostra - Agentes varrem doze repositórios fictícios e classificam o que encontram. - Para cada achado que o agente consegue corrigir, ele abre um pull request com uma correção proposta e registra um ticket. - Uma equipe então trabalha na lista classificada ao longo de uma única sprint. Executando O projeto inclui um pequeno servidor estático sem etapa de instalação e sem dependências: python3 serve.py # http://0.0.0.0:8430/ python3 serve.py --port 9000 # outra porta Apenas o diretório public/ é servido, listagens de diretório estão desabilitadas e o servidor envia uma Content-Security-Policy estrita. Uma unidade de usuário systemd está incluída para mantê-lo em execução, com lingering ativado para que o serviço inicie no boot. Como o servidor aceita qualquer cabeçalho Host, um proxy reverso pode mapear um nome de domínio diretamente para ele. Todas as URLs de recursos são relativas, então public/ também pode ser colocado em qualquer pasta de um host estático. Estrutura - public/index.html — o shell do aplicativo (barra superior, barra de status, cartões, workspace, gaveta, diálogo Sobre) - public/assets/app.js — gerador de dados, varredura, classificação, filtros, gaveta, sprint de burn-down - public/assets/app.css — todos os estilos, temas claro e escuro, sem fontes externas - public/assets/theme-init.js — aplica o tema salvo ou do sistema antes da primeira renderização - serve.py — servidor estático com uma Content-Security-Policy estrita - bug-manager.service — unidade de usuário systemd O aplicativo é autocontido: não carrega fontes, scripts ou imagens de outra origem, e a CSP (default-src 'self', connect-src 'none', sem estilos inline) impõe isso. Usando - O aplicativo abre com uma varredura concluída; Run scan reproduz a varredura do zero. - Clicar em um repositório filtra os achados; clicar em um achado abre uma gaveta de detalhes com código, raciocínio, pull request, ticket e explicação da classificação. - Play sprint fecha os achados de maior classificação ao longo de dez dias, e a aba Burn-down compara isso com fechar o mesmo número sem ordem específica. - About explica o que é simulado e vincula ao estudo de caso. Como a simulação funciona - Achados: 156 achados são gerados a partir de modelos que cobrem consistência de dados, risco de falha, segurança e code smell, em 12 repositórios fictícios, usando uma semente aleatória fixa. - Classificação: apenas ilustrativa — pontuação de risco = peso da severidade × (1 + a exposição de clientes do repositório) × a confiança do agente. - Pull requests: um achado recebe um pull request simulado a menos que a confiança do agente seja baixa ou a correção exija uma decisão de design; nesse caso, ele é sinalizado para um engenheiro. - Burn-down: uma sprint de dez dias fecha primeiro os achados de maior classificação, e o gráfico compara isso com fechar o mesmo número sem ordem específica. O sistema real por trás do estudo de caso executou agentes Claude em repositórios reais, e seus achados são confidenciais; esta demonstração reproduz o fluxo de trabalho e a apresentação, não a análise subjacente.