← Todos os agentes / 📞 Dev Ligação
📞

Dev Ligação

Cérebro do agente · cerebro.rendacomanderson.com/dev-ligacao

📞 DEV LIGAÇÃO WA — Cérebro da Missão


🔄 EM ANDAMENTO

<!-- sem tarefa em andamento -->

Status: aguardando

Atualizado: —


🔄 ESTADO ATUAL


Status: ✅ concluido

Atualizado: 2026-06-18 20:36 (Recife)

Tarefa: Nenhuma tarefa ativa


Detalhe: Estado inicial — aguardando tarefa


_Próxima sessão: tarefa encerrada, sem pendências desta etapa._



Mini-cérebro carregado pelo agente Dev Ligação WA em TODA sessão.

Cada sessão é nova — este arquivo é a MEMÓRIA PERSISTENTE e o NORTE da missão.

Criado: 2026-05-30 pelo ⚙️ Executor.


IDENTIDADE

Sou o agente 📞 Dev Ligação WA. Sou DEV dedicado a UMA missão só.

Toda mensagem que mando no Telegram começa com: 📞 Dev Ligação WA:

(no tópico 749 do grupo Operação LED). NUNCA uso "🟢 Claude:" nem "⚙️ Executor:".

NÃO ponho meu prefixo em código, commits ou conteúdo — só em mensagens de Telegram.


MISSÃO (não desviar até estar 100% funcional)

Implementar chamada de voz REAL no WhatsApp disparada do CRM do Anderson:

Funcionário clica no botão "Ligar" ao lado do lead no CRM →
o microfone do navegador dele captura o áudio (WebRTC / getUserMedia) →
esse áudio vira uma ligação de voz real no WhatsApp que toca no celular do lead →
os dois conversam em tempo real (full-duplex).

Trabalho SÓ nisso. Nunca paro até funcionar de ponta a ponta. Quando travar em algo

que só o Anderson resolve (conta, credencial, decisão de produto), reporto no tópico 749 e

sigo no que dá pra avançar em paralelo — não fico parado esperando.


⚠️ REALIDADE TÉCNICA (ler com atenção — não chutar caminho impossível)

WhatsApp usa WebRTC com mídia criptografada ponta-a-ponta para chamadas, e o protocolo

de mídia de chamada NÃO é implementado pelo Baileys (@whiskeysockets/baileys 6.7.9).

O Baileys hoje:


Caminhos a investigar (ordenar por viabilidade real, validar cada um)

1. WhatsApp Business Calling API (oficial Meta/WABA) — a Meta lançou Business Calling API

(voz) na Cloud API. O Anderson JÁ TEM WABA ativo (954352426953402, phone +5519 3097-2295,

app "Claude API WPP"). ESTE é provavelmente o caminho CERTO e suportado: ligação de voz

via API oficial + bridge WebRTC no browser. Checar disponibilidade/habilitação da feature

no número dele e os webhooks de call. Ver mini-cérebro de WABA (waba-config).

2. Baileys + camada de mídia externa — investigar forks/libs que implementem o stack de

chamada do WhatsApp (raro, instável, alto risco de ban). Tratar como plano B experimental.

3. Ponte WebRTC genérica — definir como o áudio do browser (getUserMedia → RTCPeerConnection)

chega ao backend (servidor Node intermediário com wrtc/mediasoup) e dali ao transporte WA.

O backend WebRTC é necessário em QUALQUER caminho que envolva áudio do browser.


⚠️ ANTI-BAN: ligações automatizadas/em massa são gatilho FORTE de ban no número WA. Whatever

o caminho, respeitar limites, ser conservador, e o número de testes NÃO pode ser o de produção

do wa-service sem o Anderson saber. Falar com ⚙️ Executor / 🧭 Coordenador antes de testes em volume.


ARQUITETURA ATUAL — wa-service (Baileys)


STACK DO CRM (frontend onde fica o botão "Ligar")


ARQUITETURA-ALVO (esboço a validar e refinar)


[Browser do funcionário]                 [VPS]                         [WhatsApp]
 botão Ligar  ──HTTP──▶  endpoint /call/start no backend
 getUserMedia(audio)                        │
 RTCPeerConnection  ◀──WebRTC(SRTP)──▶  servidor WebRTC (wrtc/mediasoup)
                                            │
                                            ▼
                              ponte p/ transporte de voz WA
                              (Business Calling API  OU  camada Baileys/experimental)
                                            │
                                            ▼
                                     toca no celular do lead ──▶ conversa full-duplex

REGRAS HERDADAS (valem pra mim também)


COMO REPORTO / PEÇO AJUDA


PROGRESSO DA MISSÃO (eu mantenho atualizado — append, não apagar histórico)












Plano coexistente: Twilio Voice AGORA + Calling API Meta quando tier abrir. Os 2

providers convivem no wa-call-service. Botão "Ligar" no CRM escolhe roteamento.


✅ Scaffold backend Twilio pronto e ATIVO no wa-call-service (desligado por flag):






































📞 Status da pipeline de Ligação WhatsApp
(rode com --no-color pra usar em scripts/logs)

Infra local
  ✅ wa-call-service systemd — porta 4000, isolado do wa-service
  ✅ wa-call-service /health — calling_enabled=False test_mode=true
  ⚠️  Twilio Voice (fallback) — scaffold só, sem credenciais

Túnel HTTPS público
  ✅ call.rendacomanderson.com — tunnel Cloudflare → wa-call-service
  ✅ waba-webhook GET verify — Meta consegue verificar o webhook

Supabase
  ✅ waba_calls_log alcançável — HTTP 200
  ✅ call_permissions alcançável — HTTP 200

Meta WhatsApp Calling API
  ❌ Calling habilitada na Meta — status=NOT_SET — Anderson precisa subir o tier (≥2000 conversas/24h)
  ✅ App subscrito na WABA — Claude API WPP

Template solicitar_ligacao
  ❌ Template solicitar_ligacao — Anderson precisa criar no BM (ver runbook)

Crons (todos silenciosos em condição normal)
  ✅ healthcheck infra (diário) — ~/bin/calling_pipeline_check.py
  ✅ auto-prober Meta tier (horário) — ~/bin/meta_calling_prober.py
  ✅ missed call (*/2min) — ~/bin/missed_call_alerter.py
  ✅ permissão revogada (*/5min) — ~/bin/permission_revoked_alerter.py
  ✅ permissão expirando <24h (11h Recife) — ~/bin/permission_expiring_soon.py
  ✅ auto-revoke expiradas (01h Recife) — ~/bin/expire_call_permissions.py
  ✅ resumo diário (00:30 Recife) — ~/bin/calling_daily_summary.py
  ✅ vigia local (*/5min) — ~/bin/wa_call_service_vigia.py
  ✅ housekeeping (00:45 Recife) — ~/bin/cleanup_waba_calls_log.py

Frontend (verificação leve)
  ✅ Repo cerebro-claude — último commit: ae16e4e sync mini-cérebros + aprendizados (2026-05-31 03:45:02)

Detalhe completo de cada bloqueio: ~/.config/claude-media/LIGACAO_WA_RUNBOOK.md

Pipeline healthcheck: 5/5 OK. Repo cerebro-claude: clean, sem pending.


Estado real: o sistema está construído fim a fim e os 2 ❌ visíveis exigem

ações que SÓ o Anderson resolve (Meta tier ≥2000 conversas + template

solicitar_ligacao aprovado no BM). Nenhum trabalho de código adicional

destrava algo enquanto esses 2 estiverem pendentes.


Triggers reais que vão mover a missão:


Pra futuros agentes: NÃO adicionar features novas até um dos triggers acima

acontecer. O risco de gold-plating excede o valor marginal.






Estado final da missão (steady-state):

Tudo o que dependia de mim está pronto, testado e silencioso. As 4 unlock-actions

ficam exclusivamente com o Anderson (Meta tier, template BM, META_APP_SECRET, Twilio

credentials). Não adicionar features — risco de gold-plating > valor marginal.

Crons silenciosos = sinal de saúde. Próximo movimento real só sobe quando um

trigger externo disparar.







Implicação: quando Meta destravar Calling e enviar eventos REAIS

de call (field=calls), o webhook vai pra função whatsapp-webhook-meta

do Lovable, não pra nossa waba-webhook. Pra eventos chegarem em

waba_calls_log, é preciso UMA das três:

(a) Lovable's whatsapp-webhook-meta faz fan-out POST p/ nossa waba-webhook

(preciso ver código deles pra confirmar — não tenho acesso ao projeto deles)

(b) Trocar o override do phone pra apontar pra nossa waba-webhook —

mas isso quebraria mensagens normais do Lovable; nicht.

(c) Ler waba_calls_log direto do schema do projeto Lovable

(precisa credencial cross-project)


Como tudo o que testei até agora funcionou: TODA traffic em

events.log do wa-call-service é de origem INTERNA (simulate_incoming

TEST_MODE OU calling_pipeline_check cron injetando local). NENHUMA prova

de fan-out Meta→Lovable→nós ainda. Apenas confirmei que NOSSA edge function

recebe POSTs da nossa pipeline interna (calls/eventos sintéticos).


Logs últimos 24h de Supabase edge functions confirmam: nenhuma row no

log corresponde a evento real do Meta (todas têm assinatura de smoke-test

ou pipecheck).


Ação: issue #5 pro Anderson — confirmar se Lovable forwarda eventos

field=calls pra nossa waba-webhook, OU dar acesso ao projeto Lovable

pra eu mesmo checar/adicionar o forward. Reportando no tópico agora.




Confirmação: a função processa SOMENTE change.messages e change.statuses.

Para qualquer payload com change.calls (que será o caso quando Meta destravar),

ela cai no return new Response("ok") sem fazer nada. Meu achado anterior foi

100% correto.


Preparei o patch (NÃO commitado, ~12 linhas dentro de try/catch isolado):

arquivo: ~/.config/claude-media/wa-call-service/PATCH_PROPOSTO_whatsapp-webhook-meta.md

diff: adiciona handler if (change.calls || field==="calls") que faz POST

bruto pra nossa waba-webhook (mrwayofjenublgtkbqze).

Risco BAIXO (não toca o handler de messages, fica em try/catch, falha silenciosa).


Por que não comitei direto: não sei se o repo cerebro-claude sincroniza

com Lovable inclusive em supabase/functions/, ou só com frontend (src/).

O frontend que comitei está em produção (Anderson confirmou Realtime funcionar),

mas backend edge function pode ter sync diferente. Editar e push errado podia

ter zero efeito (frustrante) ou pior, conflitar com a versão deployada no

Lovable. Vou aguardar Anderson confirmar.


Próxima ação minha: mandar mensagem no tópico explicando que o patch está

pronto e perguntando se o sync cerebro-claude → Lovable deploya

edge functions ou só frontend. Se sim, push e fica resolvido. Se não, Anderson

precisa copiar o snippet manualmente no Lovable Studio (UI).



Existe agora uma 2ª função no projeto do Lovable chamada também waba-webhook

(não confundir com a NOSSA waba-webhook em mrwayofjenublgtkbqze v12).

Ambas funções do Lovable (whatsapp-webhook-meta E waba-webhook cópia)

são IDÊNTICAS em comportamento: só processam messages/statuses, jogam

fora calls.


Significado: o setup do executor em 27/maio prova que outros agentes

ASSUMEM que commits em supabase/functions/* deployam pro Lovable. Se

isso é verdade na prática (Lovable tem CI git→deploy ativo), basta editar

o whatsapp-webhook-meta deles + push e fica. Se NÃO é verdade, o executor

commitou em vão e existe um stale source desalinhado. Confirmação só com

Anderson respondendo.


Continuo NÃO commitando o patch até ouvir dele.






Investigação:


1. waba-webhook na nossa Supabase (mrwayofjenublgtkbqze) NÃO é mais v12.

É v14, deployada 2026-06-03 02:50 UTC. Substituída pelo agente da

Recepção WA. v14 é uma função COMPLETAMENTE DIFERENTE: só handlea

change.messages (com mídia + storage upload) e change.statuses.

change.calls cai no fall-through e devolve "ok" silenciosamente.

Toda lógica de calls/permissões que eu tinha em v10-v12 SUMIU.


2. Existe uma 2ª função separada chamada waba-calling v5

(slug 8d68691a..., deployada 2026-05-25 pelo executor). Essa SIM tem

handler de calls — mas com 2 bugs:

a) Lê call.type na linha 49 enquanto Meta sends call.event.

→ real call payloads sempre cairiam como type="unknown".

b) Insere to_phone: phone onde phone = call.from em incoming,

então o lado "to" vira o vendedor e o "from" tá sumido.


3. Schema do waba_calls_log tem AMBOS conjuntos de colunas

(meta_call_id, direction, lead_id do meu design + `to_phone,

phone_number_id, initiated_by, conversation_id` do design do executor).

Coexistem.


4. Frontend CallVoiceDialog/IncomingWhatsappCallAlert/dashboard

/whatsapp-calls do meu stack ainda existem em main do cerebro-claude

(verifiquei git log: nenhum delete recente). Mas dependem do meu

webhook → estão tocando no vácuo.


Impacto prático:


Origem do problema: O executor reescreveu waba-webhook do zero

pro recepção WA sem checar que ela tinha outra responsabilidade (calls).

Slug colide. Brain anterior ([[recepcao-wa-identity-send]]) menciona

whatsapp-send v20 mas não fala que tocou waba-webhook.


Por que NÃO vou consertar agora:


Próximo passo: reportar tudo isso no tópico 749 com detalhe suficiente

pra Anderson escolher entre: (A) reservar waba-calling pra calls e eu

consertar os 2 bugs dele, (B) ressuscitar v12 como waba-calls-webhook

separada, (C) deixar a Recepção WA agent restaurar a parte de calls em

waba-webhook seguinte.



  "calls": [{
    "id": "<call-id>",
    "from": "15551234567",
    "to": "12345678900",
    "event": "connect",
    "timestamp": "1762216151",
    "direction": "USER_INITIATED",
    "session": { "sdp": "<offer>", "sdp_type": "offer" }
  }]

Meu simulate em wa-call-service/server.js linhas 383-390 usa exatamente

esse formato (event: "connect"). Meu waba-webhook v12 lia esse campo

certo. A função waba-calling v5 do executor lê call.type na linha 49

— definitivamente errado. Bug confirmado, não chute meu.


Significa que mesmo se Anderson resolver a routing question (qual função

recebe os events do Meta), a função waba-calling PRECISA ser corrigida

pra:


Anderson não respondeu ainda. Continuo standby.



Significa: meu stack inteiro (wa-call-service + 3 componentes

frontend) continua sendo o caminho oficial usado pelo CRM. A função

waba-calling v5 do executor é ÓRFÃ — existe mas ninguém chama. As

rows BUSINESS_INITIATED em waba_calls_log de 2026-05-30 quase

certamente vieram do meu fluxo (vendedor clicou "Ligar" no CRM → meu

/call/start → Meta API → falhou 138015 porque tier não destravou).


**Reforça que Opção B (criar waba-calls-webhook slug separado,

ressuscitando minha v12) é a saída mais limpa:**


Continuo SEM mexer em código até Anderson responder. Mas agora a

recomendação tem evidência clara.



git log em cerebro-claude entre 00:00 e 03:00 UTC do dia 03 mostra só

commits "sync mini-cérebros + aprendizados" mexendo em ja_postado.md,

CARROSSEL_CEREBRO.md, REELS_CEREBRO.md, estruturas_virais.md. **Zero

commits tocaram supabase/functions/waba-webhook/.**


Significado: o deploy v14 foi feito via MCP deploy_edge_function

direto, BYPASSANDO o git mirror. Source do v14 só existe dentro do

Supabase. Cerebro-claude/Lovable git tem source obsoleto (v12-era).


Lição operacional: mudanças em edge functions via MCP não

aparecem no git e não disparam diff visíveis. Próximo agente que

mexer numa função compartilhada DEVE checar:

1. list_edge_functions versão atual antes de overwritar

2. get_edge_function source atual pra preservar handlers

3. Commitar source novo no git mirror pra auditabilidade


Vetor de detecção que faltaria sem smoke test:

Meu status_check só faz GET verify do webhook (que retorna 200 sempre)

e checa HTTP code do tunnel. NÃO detecta que POST handler foi nuked.

Único jeito de detectar: smoke test (POST simulate + verificar row).

Idealmente esse smoke test estaria automatizado em cron — mas isso é

hardening que SÓ faz sentido após Anderson decidir A/B/C, senão é

smoke test contra função quebrada.



Validei schema das 2 tabelas antes de finalizar:

• waba_calls_log: tem to_phone (não from_phone), sdp_offer/sdp_answer

(não session_sdp). Corrigi insert.

• call_permissions: NÃO tem coluna status — granted vs revoked é

implícito (granted_at setado vs revoked_at setado). Unique idx

é (phone_number_id, phone), não só phone. Corrigi upsert.


Estado do PREP:

• GET verify (token hardcoded "aceleradores_waba_2026")

• POST com change.calls → mapeia event (connect→ringing, terminate→ended),

faz find_lead_by_phone, insert/update em waba_calls_log

• Auto-grant em call_permissions pra USER_INITIATED incoming

• Handler de change.user_preferences/permissions pra permission events


Quando Anderson disser "B":

1. mcp__supabase__deploy_edge_function slug=waba-calls-webhook

source=<arquivo do PREP>

2. Editar wa-call-service/server.js linha 355-356 WABA_WEBHOOK_URL

pra /functions/v1/waba-calls-webhook

3. sudo systemctl restart wa-call-service

4. curl simulate_incoming → SELECT waba_calls_log deve mostrar row

fresca com meta_call_id="test_..."

5. Reportar verde no tópico 749


Continuo SEM deployar. PREP só serve pra cortar tempo de fix quando

Anderson decidir.


[decisão Anderson 2026-06-21] CRM agora se chama Hub

Por decisão do Anderson, o CRM (painel.rendacomanderson.com) passa a ser chamado de Hub.

Termo oficial daqui pra frente. Substituir gradualmente em UI/textos quando fizer sentido.


VOCABULÁRIO (Anderson 2026-06-24)


[vocab-subdominios] 2026-06-24 04:55 (Anderson travou)


cerebro.rendacomanderson.com · Anderson Ferreira Conceição