Agente de Ticket de Bug — Triagem Automatizada com IA para Notion

Agente de Ticket de Bug — Triagem Sentry com Poder de IA no Notion

Esta é uma submissão para o Desafio MCP do Notion.

O que eu construí

Toda vez que um erro ocorre em produção, alguém da sua equipe precisa abrir o Sentry, ler o stack trace, decidir quão urgente é e escrever manualmente um ticket. Isso acontece às 2 da manhã. As pessoas pulam etapas. Duplicatas se acumulam.

Agente de Ticket de Bug automatiza todo o fluxo de triagem. Ele escuta os webhooks do Sentry, executa um agente de IA Claude para analisar cada erro e escreve um ticket estruturado e priorizado diretamente em um banco de dados do Notion — incluindo deduplicação, resumos gerados por IA e sugestões de correção.

Principais Capacidades

• Recepção automática — recebe eventos de webhook do Sentry e os coloca em fila para processamento
• Deduplicação inteligente — pesquisa no Notion antes de criar qualquer coisa; atualiza tickets existentes em vez de duplicar
• Atribuição de prioridade por IA — Claude atribui P0–P3 com base no ambiente, impacto no usuário e frequência
• Tickets estruturados — cada ticket recebe um tipo de erro, stack trace, usuários afetados, resumo da IA e uma sugestão de correção concreta
• Alertas de escalonamento — erros de produção P0/P1 são sinalizados imediatamente para notificação no PagerDuty/Slack
• Processamento baseado em fila — fila de trabalho serializada previne condições de corrida quando o Sentry dispara rajadas de eventos

Demonstração

[Terminal A — servidor em execução]
🐛 agente-ticket-bug em execução em http://localhost:3000

[Terminal B — enviar um P0]
$ npm run demo -- --scenario p0

→ Webhook recebido: "TypeError: Não é possível ler propriedades de indefinido (lendo 'charge')"
→ Triagem iniciada...
→ Pesquisando no Notion por duplicatas... nenhuma encontrada
→ Atribuindo prioridade: P0 (serviço de pagamento, 247 usuários afetados, produção)
→ Escrevendo resumo e sugestão de correção...
→ Criando ticket no Notion... ✓ page_id: abc123

⚠️  ALERTA DE ESCALONAMENTO: P0 detectado em produção — notificar imediatamente o responsável

[Banco de dados do Notion — ticket aparece]
Título:    TypeError: Não é possível ler propriedades de indefinido (lendo 'charge')
Prioridade: P0
Env:      produção
Usuários:    247
Resumo:  "O processamento de pagamento falhou devido a uma referência nula no objeto charge..."
Correção:      "Adicione uma verificação nula para stripe.charge em src/payments/processor.ts:88"

[Enviar o mesmo erro novamente]
$ npm run demo -- --scenario duplicate

→ Pesquisando no Notion por duplicatas... ticket existente encontrado (page_id: abc123)
→ Atualizando frequência: 12 → 18 ocorrências, última vista: agora
→ Pronto. Nenhuma duplicata criada.

Mostre-nos o Código

GitHub: agente-ticket-bug

Webhook do Sentry
     │
     ▼
Servidor Express  ──→  Fila de Trabalho (serializada)
                          │
                          ▼
                   Agente de Triagem Claude
                    ├── Pesquisar Notion (verificação de duplicata)
                    ├── Atribuir prioridade P0–P3
                    ├── Escrever resumo + sugestão de correção
                    └── Criar ou Atualizar página do Notion
                              │
                              ▼
                       Banco de Dados do Notion
                     (Rastreador de Bugs, ao vivo)

Pilha tecnológica: TypeScript · Express · Claude claude-sonnet-4-6 · Servidor MCP do Notion · Zod

Como eu usei o Notion MCP

1. Claude Descobre Ferramentas em Tempo de Execução

Em vez de codificar chamadas à API do Notion, eu inicializo o servidor oficial do Notion MCP via stdio e deixo Claude buscar as ferramentas disponíveis na inicialização. Claude então decide quais ferramentas chamar e em que ordem — search-database, create-page, update-page — com base no que encontra.

Isso significa zero código de wrapper da API do Notion do meu lado. Se o Notion adicionar novas ferramentas MCP, o agente as obtém de graça.

2. Deduplicação via Pesquisa MCP

A primeira coisa que Claude faz em cada loop de triagem é chamar a ferramenta de pesquisa do Notion com o título do erro. Se encontrar um ticket correspondente, atualiza a frequência e a última vista em vez de criar um novo. Essa lógica vive inteiramente no prompt do agente — não em código escrito à mão:

1. Pesquisar o banco de dados por um ticket existente correspondente a este título de erro.
2. Se duplicata encontrada: atualizar frequência e última vista. Reportar o ID da página.
3. Se nenhuma duplicata: atribuir prioridade, escrever resumo e correção, criar uma nova página.

3. Tickets Estruturados via Criação MCP

Quando Claude cria um ticket, ele mapeia os dados do erro para o esquema de propriedades do Notion — prioridade como uma seleção, ambiente como uma seleção múltipla, stack trace como um bloco de código, resumo e correção como texto rico. O servidor MCP do Notion lida com toda a formatação de propriedades; Claude apenas preenche os valores.

4. O Rubrica de Prioridade

Claude não adivinha — ele aplica uma rubrica determinística do prompt do sistema:

O que isso desbloqueia

Antes disso: um engenheiro é chamado, abre o Sentry, lê o erro, cria manualmente um ticket no Notion, atribui uma prioridade com base na intuição e espera não ter perdido uma duplicata.

Depois disso: o ticket já está no Notion quando o engenheiro abre o Slack. Ele tem uma prioridade, um resumo, uma sugestão de correção e nenhuma duplicata. O engenheiro pode ir direto para a correção em vez de triagem.

O servidor MCP do Notion tornou isso possível sem construir uma integração personalizada do Notion. Claude lidou com toda a orquestração das ferramentas — eu apenas descrevi o que queria no prompt do sistema.