Pular para conteúdo

Pendências operacionais

Doc evergreen com ações identificadas + estado dos dados + backlog de aplicação. Atualizar ao concluir item ou ao descobrir novo.

⏰ Backlog imediato — aguardando aplicação manual

Itens prontos no código (commit feito, push feito) que dependem de você executar uma ação operacional pra ficar 100% no ar. Marcar [x] ao concluir.

A. Migrations Supabase (aplicar no SQL Editor)

  • 022_tenant_isolation_guards.sql — CHECK constraint client_name not blank + 3 índices (Fase 1 isolamento)
  • 026_seed_gita_onboarding.sql — INSERT gita-onboarding + 5 tools (Onda 1 · 1/5)
  • 027_seed_gita_success_checkin.sql — INSERT gita-success-checkin + 2 tools (Onda 1 · 2/5)
  • 028_seed_gita_success_nps.sql — INSERT gita-success-nps + 2 tools (Onda 1 · 3/5)

B. Preencher placeholders após cada migration de agente

Toda migration de agente novo deixa 4 campos pra preencher no provider_config + crm_config. Padrão pra cada um:

Agente Campos a preencher
gita-onboarding provider_config.token (copiar do gita-router) · gemini_api_key · webhook_secret (openssl rand -hex 16) · crm_config.token Chatwoot · variables.clickup_onboarding_list_id
gita-success-checkin mesmos 4 (sem list_id, não usa criar_card_clickup)
gita-success-nps mesmos 4

Localização: admin do gita-agents → editar agente → Variables / Provider config.

C. Ativar agentes pra clientes reais (manual SQL)

Quando o gita-onboarding for usado pelo primeiro cliente real, atualizar qualified_data do lead pra ativar checkin + NPS:

UPDATE leads
SET qualified_data = qualified_data || '{"checkin_active": true, "nps_active": true}'::jsonb
WHERE remote_jid = '<jid_do_cliente>@s.whatsapp.net';

(Após v2 do gita-onboarding, isso vira automático via tool ao final do fluxo.)

D. DNS / Domínios

  • equipamentos.grupogita.com.br — adicionar registro A apontando pra 76.76.21.21 no Cloudflare. Marcar como "DNS only" (sem proxy laranja). Vercel detecta e emite SSL.
  • (opcional) og.jpg 1200×630 pra preview WhatsApp da landing de equipamentos. Pode ser gerado a partir do PDF capa.

E. Configurar Chatwoot Automation pra chatwoot/inbound-message (Fase 1.4 follow-up)

  • Settings → Automation → New automation
  • Condição: Label is "pausar-ia" + Event: Message Created
  • Action: Send a webhook → https://<engine-host>/webhook/chatwoot/inbound-message
  • Aplicar nos 3 tenants (Janaina, Gita Agentes, Denise)

F. Hooks de git (proteção pre-push)

  • Rodar npm run hooks:install na pasta ~/projetos/gita-agents/ (uma vez por clone do repo)

G. Onboarding Tay no Claude Code (squad completo)

  • Slash command /lancamento-janaina criado em ~/gita/.claude/commands/
  • Agente launches-janaina em ~/gita/agents/launches-janaina/ com AGENT.md + 3 templates + runbook
  • Templates versionados: drive-structure.md, clickup-tasks.md, briefing-resumo.md
  • RUNBOOK-PRIMEIRO-USO.md específico do lançamento Janaina
  • GUIA-TAY.md na raiz do repo — onboarding 5min com curadoria de 8 comandos + 6 agentes do squad
  • /tay-dia — snapshot operacional consolidado (RESTART + BACKLOG + clientes + lançamento + tráfego)
  • /ceo atualizado — menu com 9 opções priorizando contextos comerciais
  • squad-gita.md atualizado — agentes Tay-friendly marcados com 🎯
  • CLAUDE.md atualizado — primeiro link aponta pra GUIA-TAY pra Tay
  • Smoke test pelo Junior antes da Tay rodar (sessão simulada com /ceo, /tay-dia, /lancamento-janaina --dry-run)
  • Tay dá git pull na máquina dela e abre GUIA-TAY.md
  • Tay roda /lancamento-janaina <URL-do-briefing-real> — primeiro lançamento real
  • Validar fluxo end-to-end: pasta Drive criada + lista ClickUp + resumo estruturado salvo
  • Tay valida modos do agente: status, próxima entrega, gerar copy, atualizar tarefa

📋 Estado da Squad Gita (Onda 1 em execução)

Ver squad-gita.md pra visão completa. Status dos agentes da Onda 1:

# Agente Código Migration Aplicado Em uso
1 gita-onboarding ✅ ✅ 026 ⏳ aguardando ⏳
2 gita-success-checkin ✅ ✅ 027 ⏳ aguardando ⏳
3 gita-success-nps ✅ ✅ 028 ⏳ aguardando ⏳
4 gita-kickoff ⏳ próximo — — —
5 gita-base (RAG) ⏳ — — —

Estado atual dos dados (snapshot 2026-04-22)

Após entrega da Fase 1 (isolamento) + Fase 2 (observabilidade) + cleanup de leads sintéticos da Denise (31 deletados).

Totais em produção

Métrica Valor Observação
Leads totais 30 Pós-cleanup
Leads new 16 Entrantes aguardando primeira interação de qualificação
Leads qualified 12 Responderam SPIN mas ainda ~8 são sintéticos (ver P1)
Leads scheduled 1 1 lead END em varejo agendado (cluster Gita)
Leads converted 1 1 venda registrada via registrar_compra (Janaina)
Agentes ativos 15 9 do cluster Gita Agentes + 4 Janaina + 1 Denise + 1 vagas
Agentes inativos 2 moleiro, oraculo-pinzon (desativados Fase 1)
Cross-tenant legítimo 1 556196701770 (Junior) em Gita + Denise

Distribuição de fit (qualified_data)

Tenant fit qtd
Gita Agentes end_qualificado 2
Denise Ramos — (agente único, sem FIT_ROUTING) —
Janaina Ortiga — (legacy, não salva fit estruturado) —

Atividade 24h (após cleanup dos test_scenario_*)

Tenant Pipelines Msgs (user+model+function) Erros Tools chamadas
Denise Ramos 57 165 13 (resíduo) qualificar_lead × 30
Gita Agentes 18 56 0 qualificar_lead × 7, reportar × 1, agendar_reuniao × 1, consultar_disponibilidade × 1
Janaina Ortiga 19 38 0 (legacy)

FIT_ROUTING disparou 11x no cluster Gita nas últimas 24h — todos end_qualificado → gita-end-proposta (bateria v16 de testes).

Ruídos identificados no dashboard

P1 — 🟡 8 leads sintéticos restantes na Denise

Primeiro cleanup (31 leads test_scenario_001..031) deixou passar 8 com padrões diferentes: - test_scenario_032 / 033 / 034-midia-* (3 leads — cenários de mídia) - test_scenario_FU-001..005-* (5 leads — cenários de follow-up)

Todos marcados como qualified, inflam "Denise qualified=10" pro número real de ~2.

Ação: rodar delete em lote com padrão mais permissivo (ilike 'test_scenario%' já pega; usar o script scripts/delete-denise-testscenarios.ts que já filtra assim).

Prevenção: commit 2cc6f76 (aguardando deploy) já bloqueia follow-up de JIDs test_*. Novos cenários não vão gerar erro. Cleanup manual é pra resíduo histórico.

P2 — 🟡 Tenant "Adriano Moleiro" aparece no dashboard

Agentes moleiro e oraculo-pinzon estão is_active=false (Fase 1). Mas 2 leads antigos (5511953266999, 5511934811681) com status=new e follow_up_stage=1 permanecem na tabela leads, fazendo o tenant aparecer no dashboard.

Impacto: estético — dashboard mostra tenant como se fosse produção.

Ação proposta: filtrar dashboard/funnel pra ocultar tenants cujos agentes estejam 100% inativos (adicionar WHERE ai_agents.is_active = true no JOIN). Ou deletar leads órfãos.

P3 — 🟠 1 lead preso em gita-captacao com status=qualified

Esperado: status=qualified dispara FIT_ROUTING pra gita-conversao / gita-downsell / etc no próximo turno. Esse lead ficou preso — ou não respondeu próxima msg (sticky preso), ou Gemini não marcou fit corretamente no qualified_data.

Ação: inspecionar o lead via scripts/analyze-dashboard.ts (já criado) e ver qualified_data.fit. Se for null, é bug de prompt. Se lead parou de responder, é comportamento esperado.

Prioridade: baixa — caso isolado. Se padrão se repetir, virá fix de prompt.

P4 — 🟢 2 leads "esquecidos" do Moleiro com follow-up ativo há 9 dias

5511953266999 e 5511934811681 com follow_up_stage=1 e updated_at de 13/14-abril. Como agente moleiro está is_active=false, follow-up não processa (já estava filtrando por agent_id de agente ativo). Ficam pendurados.

Ação: pausar com follow_up_stage=-1 ou deletar leads órfãos. Baixa prioridade.

Lições aprendidas (padrões a aplicar)

Cleanup de leads de teste é obrigatório após cada bateria

Sessões v15 e v16 usaram JIDs test_v15_* e test_v16_* — limpos via scripts dedicados. Mas a Denise tinha leads test_scenario_* antigos de validação da época da migração que ficaram. Resultado: follow-up tentou processar, gerou 49+ erros em 24h, disparou primeiro alerta ClickUp da Fase 2.3.

Regra: toda sessão que cria leads de teste em produção deve ter cleanup explícito. O commit 2cc6f76 adiciona proteção estrutural (follow-up ignora test_*), mas o cleanup continua sendo obrigatório pra não poluir dashboard/funnel/métricas.

Dashboard revela problemas que logs não mostram

Os 49 erros/24h da Denise passaram despercebidos até a Fase 2.1 expor via /metrics. Visibilidade agregada mostrou padrão que linha-a-linha no agent_logs não gritaria.

Regra: antes de afirmar "sistema saudável", checar /metrics ou dashboard. Zero errors em metrics é mais confiável que "não recebi alerta" (porque alerta tem threshold).

Alertas funcionam mas precisam de contexto no cleanup

Primeiro alert ClickUp da Fase 2.3 chegou como esperado (36 erros em 5min), mas era ruído de leads sintéticos — não bug real. Se o cleanup tivesse sido feito antes, o alert não teria disparado.

Regra: após implantar alerta novo, sempre limpar resíduos históricos que possam disparar falso positivo.

Checklist de ações pendentes

  • P1 Rodar cleanup dos 8 leads test_scenario_* restantes na Denise (npx tsx scripts/delete-denise-testscenarios.ts)
  • P2 Decidir: filtrar dashboard pra tenants com agente ativo, OU deletar leads órfãos do Moleiro
  • P3 Investigar lead preso em gita-captacao com status=qualified — checar qualified_data.fit
  • P4 Pausar ou deletar 2 leads "esquecidos" do Moleiro com follow_up_stage=1 há 9 dias
  • Deploy pendente do commit 2cc6f76 — fix estrutural follow-up ignora test_* (Easypanel)
  • Adicionar seção no runbook-novo-cliente.md lembrando do cleanup obrigatório pós-bateria

Histórico de limpezas

Data Ação Impacto
2026-04-21 Cleanup bateria v15 (test_v15_*) 179 msgs + 1142 logs + 21 leads
2026-04-22 Cleanup bateria v16 (test_v16_*) 170 msgs + 704 logs + 20 leads + 2 da rerun A3
2026-04-22 Cleanup Denise test_scenario_001..031 574 msgs + 1445 logs + 31 leads
2026-04-22 Cleanup 1770 (teste Junior) × 2 48 msgs + 5433 logs + 3 leads · 46 msgs + 275 logs + 2 leads