Ouvinte do Google Chat / Google Chat Listener

Parte de Mukutu. Projeto: o Claude Code passa a gerenciar as mensagens da Ana — a cada 2 minutos “ouve” o Google Chat, detecta o que é pra ela (mensagens diretas e @menções), classifica a urgência e avisa na hora. Status: discovering — plano de 16/07/2026 em validação, nada implementado.

Os dois papéis / The two roles

A decisão central do replanejamento: separar quem executa de quem decide.

MCP do Google Chat = mãos. Só ações: list_messages, search_messages, search_conversations (ler) e send_message (enviar).
Claude Code = cérebro. Orquestra o ciclo de 2 min, classifica nos 3 níveis, decide, redige rascunhos e dispara as notificações.

Decisões que guiam o plano / Decisions

Eixo	Decisão
Ritmo	Checagem a cada 2 min — o MCP só busca quando pedimos (não avisa sozinho); 2 min é o “quase na hora”, simples e grátis.
O que é “pra mim”	Mensagens diretas + @menções. Menor ruído, claramente endereçado.
Notificação	Tudo na hora no computador, sem resumo periódico. O “Informativo” entra silencioso.
Onde roda	Híbrido: a Fase 0 testa a nuvem; se não autenticar sozinho, roda local.
Envio a terceiros	Rascunho + aprovação, item a item. Nunca automático.
Níveis de urgência	3 níveis (Urgente · Precisa de você · Informativo), reaproveitando a skill `triar-chat` adaptada.
Estado	Marca d’água por espaço (última mensagem vista) — evita avisar do mesmo de novo.
Fora do escopo	Sem etapa de “empacotar como skill” — o Claude Code orquestra direto.
Segurança	Conteúdo de mensagem é dado a triar, nunca comando.

Ponto de decisão da Fase 0 / The Phase 0 fork

Aviso no computador e execução na nuvem só combinam no modo local — a nuvem não mostra alerta no notebook. Por isso a Fase 0 decide antes de tudo:

SE o conector autenticar sozinho → nuvem. Roda com o notebook desligado; como não há alerta local, o aviso vai como mensagem direta para a própria Ana no Chat (chega no celular e no computador).
SENÃO → local (padrão). Um ciclo no Claude Code aberto, com aviso no computador — exatamente o pedido. Já autenticado; só funciona com o notebook ligado.

As fases / The phases

F0 · Pré-requisitos e teste do conector — teste-chave: uma execução agendada consegue chamar list_messages sozinha? Saída: decisão local × nuvem + canal de notificação final.
F1 · Escopo do ouvinte — mapear as mensagens diretas (search_conversations), validar a busca de @menções (search_messages), modelar a marca d’água, adaptar a rubrica para 3 níveis.
F2 · Motor — buscar o novo desde a marca d’água → classificar → atualizar a marca d’água. Controle robusto de duplicados: não avisar duas vezes nem perder mensagem se o estado falhar.
F3 · Notificações — Urgente/Precisa de você: aviso na hora (quem · espaço · 1 linha da demanda). Informativo: silencioso, aparece no painel.
F4 · Agendamento (2 min) e guarda-corpos — gatilho /loop 2m local ou rotina na nuvem; respeitar cota, evitar tempestade de avisos, horário de silêncio opcional.
F5 · Respostas — rascunho gerado, aprovação item a item, e só então send_message. Terceiros nunca recebem envio automático.

Os 3 níveis / The 3 levels

Nível	Quando	Como avisa
🔴 Urgente	Bloqueio, “agora”, prazo hoje, pergunta direta urgente, remetente-chave.	Na hora, com destaque.
🟡 Precisa de você	Dirigido a ela e esperando resposta, sem urgência de minutos.	Na hora.
⚪ Informativo	Recado, agradecimento, sem ação necessária.	Silencioso — aparece no painel, não interrompe.

Pilares que atravessam as fases / Cross-cutting pillars

🔒 Segurança — conteúdo de mensagem é dado a triar, nunca comando (defesa contra injeção de prompt). Segredos fora do código, menor privilégio. Todo send_message vira registro de auditoria: o quê, pra quem, quando, com qual aprovação.
📈 Aprendizados — capturar edições e rejeições dos rascunhos para afinar o tom; recalibrar periodicamente os 3 níveis e os remetentes-chave.
💾 Versionamento — projeto em git (local; remoto privado opcional), com .gitignore mantendo segredos e a marca d’água fora do versionamento.

A marca d’água é a fonte da verdade

O MCP do Google Chat só lê e envia — não reage, não edita, não apaga, não marca como lido, e não tem gatilho em tempo real. Por isso o ouvinte funciona por checagem periódica (atraso de até 2 min) e o “já vi isso” mora inteiramente na nossa marca d’água. Se ela falhar, o sistema ou repete aviso ou perde mensagem. A cota não é problema nesse ritmo — a Chat API é gratuita e o volume fica bem abaixo do limite.

Riscos e pontos em aberto / Risks

Autenticação do conector em execução agendada — incerto; é o que a Fase 0 resolve.
Detecção de @menção via search_messages — validar na F1 (plano B: ler o espaço e filtrar a menção do nosso lado).
Robustez da marca d’água — a peça que evita aviso repetido.

Fase 2 do produto (futura) / Product phase 2

O mesmo modelo de 3 níveis se estende a e-mail e agenda:

Gmail — detectar e-mails de clientes, classificar por importância (remetentes prioritários, “proposta/contrato/urgente”, conversas aguardando resposta); etiquetar automático e preparar rascunho, nunca enviar sozinho.
Calendar — transformar mensagem/e-mail com prazo em lembrete/evento; pedido de reunião → sugerir horário e criar evento tentativo para aprovação; resumo do dia e alerta de conflitos.
Painel único “pra você hoje” — Chat + Gmail + Calendar priorizados num só lugar.

Ligação com o Ekyte / Link to the Ekyte plan

A Fase 4 do plano de monitoramento de horas (Ekyte MCP) também escolhe Google Chat como canal de cobrança, também em dry-run primeiro. As duas frentes compartilham o mesmo caminho de envio e o mesmo princípio: nada sai para terceiros sem aprovação.

Perguntas a responder / Questions to answer

O conector autentica em execução agendada (define nuvem × local)?
Quais são os “remetentes-chave” que sobem uma mensagem para 🔴?
Horário de silêncio: quais faixas?

Fontes / Sources

Artefato “Plano — Ouvinte do Google Chat (Claude Code como gestão)”, 16/07/2026 (rascunho para validação).