Notificações Unificadas Ops

Use esta habilidade quando o problema real não for um ping ausente. O problema real é um sistema de notificação fragmentado.

O trabalho é transformar eventos dispersos em uma única superfície para o operador com:

• severidade clara
• propriedade clara
• roteamento claro
• ação de acompanhamento clara

Quando Usar

• o usuário deseja um canal de notificação unificado entre GitHub, Linear, hooks locais, alertas de desktop, chat ou e-mail
• falhas de CI, solicitações de revisão, atualizações de issues e eventos do operador chegam em locais desconectados
• a configuração atual gera ruído em vez de ação
• o usuário deseja consolidar branches de notificação sobrepostos ou propostas de backlog em um único canal nativo do ECC
• o workspace já possui hooks, MCPs ou ferramentas conectadas, mas nenhuma política de notificação coerente

Superfície Preferida

Comece pelo que já existe:

• issues, PRs, revisões, comentários e CI do GitHub
• movimento de issues/projetos no Linear
• eventos de hooks locais e sinais de ciclo de vida da sessão
• primitivas de notificação de desktop
• superfícies de e-mail/chat conectadas quando elas realmente existem

Prefira orquestração nativa do ECC em vez de pedir ao usuário para adotar um produto de notificação separado.

Regras Inegociáveis

• nunca exponha tokens, segredos, segredos de webhook ou identificadores internos
• separe:
  • fonte do evento
  • severidade
  • canal de roteamento
  • ação do operador
• padrão para resumo primeiro quando o custo de interrupção for incerto
• não distribua todos os eventos para todos os canais
• se a solução real for melhor triagem de issues, política de hooks ou fluxo de projeto, diga isso explicitamente

Pipeline de Eventos

Trate o canal como:

1. Capturar o evento
2. Classificar a urgência e o proprietário
3. Roteamento para o canal correto
4. Colapsar duplicatas e ruído de baixo sinal
5. Anexar a próxima ação do operador

O objetivo é ter menos notificações, porém melhores.

Modelo de Severidade Padrão

Se o workspace não tiver um modelo de severidade, crie um antes de propor automação.

Fluxo de Trabalho

1. Inventariar a superfície atual

Liste:

• fontes de eventos
• canais atuais
• hooks/scripts existentes que emitem alertas
• caminhos duplicados para o mesmo evento
• casos de falha silenciosa onde coisas importantes não estão sendo exibidas

Destaque o que o ECC já gerencia.

2. Decidir o que merece interrupção

Para cada família de eventos, responda:

• quem precisa saber?
• quão rápido eles precisam saber?
• isso deve interromper, agrupar ou apenas registrar?

Use estes padrões:

• interromper para eventos de release, CI, segurança e que bloqueiam o proprietário
• resumir para atualizações de sinal médio
• apenas registrar para telemetria e marcadores de ciclo de vida de baixo sinal

3. Colapsar duplicatas antes de adicionar canais

Procure por:

• o mesmo evento de PR aparecendo no GitHub, Linear e logs locais
• notificações repetidas de hooks para a mesma falha
• comentários ou mudanças de status que devem ser resumidos em vez de encaminhados brutos
• canais que se duplicam sem adicionar um caminho de ação melhor

Prefira:

• um resumo canônico
• um proprietário
• um canal principal
• um caminho de fallback

4. Projetar o fluxo de trabalho nativo do ECC

Para cada necessidade real de notificação, defina:

• fonte
• gate (portão/condição)
• shape (formato): alerta imediato, resumo, fila ou apenas dashboard
• canal
• ação

Se o ECC já possui a primitiva, prefira:

• uma habilidade para triagem do operador
• um hook para emissão/aplicação automática
• um agente para classificação delegada
• um MCP/conector apenas quando uma ponte real estiver faltando

5. Retornar um design focado em ação

Termine com:

• o que manter
• o que suprimir
• o que mesclar
• o que o ECC deve envolver a seguir

Formato de Saída

CURRENT SURFACE
- sources
- channels
- duplicates
- gaps

EVENT MODEL
- critical
- high
- medium
- low

ROUTING PLAN
- source -> channel
- why
- operator owner

CONSOLIDATION
- suppress
- merge
- canonical summaries

NEXT ECC MOVE
- skill / hook / agent / MCP
- exact workflow to build next

Regras de Recomendação

• prefira um canal forte em vez de muitos fracos
• prefira resumos para atualizações de sinal médio e baixo
• prefira hooks quando o sinal deve ser emitido automaticamente
• prefira habilidades do operador quando o trabalho for triagem, roteamento e tomada de decisão com revisão primeiro

…