---
name: whatsapp-lid-chute-fix-2026-05-12
description: "Bug do webhook atribuindo LID a \"unica conversa recente\" sem pushName causava cross-contamination grave entre clientes (caso Juliana/SS Qualita)"
metadata: 
  node_type: memory
  type: project
  originSessionId: 3cc4e2da-474d-47ee-96aa-7e15c6fdf186
---

# WhatsApp LID chute fix (2026-05-12) — mensagens de Clarice viraram da Juliana

**Sintoma**: Valeria atendia "JULIANA MARIA RAIA" mas as mensagens reais eram de outra pessoa (Clarice Tonet Tambosi / SS Qualita da Romeo Trucks). Templates da agencia geravam "Boa tarde, SS Qualita!" no chat de Juliana. Caos completo. Usuario reportou como URGENTE.

**Causa raiz** (`app/Controllers/WhatsApp.php:919-926`): fallback step 7 da resolucao LID. Quando uma mensagem chega com `@lid` e SEM pushName, e o webhook nao consegue resolver pelos passos anteriores, o codigo CHUTAVA assumindo que o LID pertencia a "unica conversa recente" do cliente. Isso causava cross-contamination grave.

**Provas dos logs** (2 casos historicos):
- `2026-05-07 11:02:08` — LID `36661991833747` (Monique) atribuido a `5555219748520` (Bruna)
- `2026-05-11 14:10:43` — LID `68749575119071` (SS Qualita/Clarice) atribuido a `553196001399` (Juliana Maria Raia)

O comentario no codigo (`WhatsApp.php:920-921`) ja CITAVA o caso Bruna/Monique 2026-05-07 mas a correcao foi parcial — so blindou o caminho COM pushName. O caminho SEM pushName continuou bugado e queimou a Juliana.

**Why**: WhatsApp evoluiu para `@lid` em vez de `@s.whatsapp.net`. Sem pushName e sem cadastro previo, NAO existe forma segura de adivinhar de quem e o LID. Qualquer chute = mistura de clientes em producao.

**How to apply**: ao adicionar/refatorar a logica de resolucao LID em `WhatsApp.php::handleIncomingWebhookMessage`, NUNCA criar fallback baseado em "conversa recente" sem que haja match por nome OU cadastro confirmado. Sempre preferir cair em step 9 (cria `lid_xxx` temporario) a chutar — usuario consegue lidar com "contato sem nome" mas nao com "mensagem do cliente A no chat do cliente B".

**Fix aplicado** (3 acoes):

1. **DB cleanup**:
   ```sql
   UPDATE whatsapp_contatos SET lid=NULL WHERE id=108;  -- Juliana
   UPDATE whatsapp_contatos SET deleted_at=NULL, nome=REPLACE(nome,' [merged]','') WHERE id=488;  -- SS Qualita
   UPDATE whatsapp_messages SET contact_id=488, phone_number='lid_68749575119071'
   WHERE session_id=1 AND phone_number='553196001399'
     AND (message LIKE '%SS Qualit%' OR message LIKE '%Clarice%')
     AND message NOT LIKE '%Juliana Raia%';
   -- 46 mensagens historicas movidas (23 templates + 23 humanas/janela bug)
   ```

2. **Code patch v1** (`WhatsApp.php:919-926`): removido fallback "unica conversa recente sem pushName". Agora apenas loga warning e deixa cair em step 9.

2.5. **Blindagem total v2** (2026-05-12 11:36, a pedido do usuario): TODOS os caminhos heuristicos de auto-bind LID desligados — steps 5 (pushName exato), 6 (pushName parcial), 7 inteiro (conversa recente). Agora SO restam caminhos confiaveis: resolvedPhone do Baileys (1), LID direto no banco (2-3), micro-server Baileys (4), tabela clientes por nome (4.5). Qualquer outro caso cai em step 9 (cria `lid_xxx`). Trade-off: mais contatos "lid_xxx" aparecendo na lista, mas ZERO risco de roubar contato existente. Equipe associa manualmente quando souber o numero real.

3. **Deploy seguro**: backup (`WhatsApp.php.bak_20260512_lidfix`), upload CRLF→LF, `pkill php-cgi` para flush OPcache.

**Caso pratico Juliana vs Clarice**:
- Cliente id=30 "JULIANA MARIA RAIA" tel `31996001399` — usuario diz que cadastro pode estar errado (na pratica, Clarice escreve desse numero), mas explicitamente pediu para NAO mexer em cadastros
- Cliente id=27 "CLARICE TONET TAMBOSI" tel `11997300033` — Clarice da Romeo Trucks (confirmado via msg id=5195: "Aqui e Clarice da Romeo Trucks")
- Clarice tambem usa pushName "SS Qualita" via LID 68749575119071
- Mensagens template "Olá, Juliana Raia / Clarice" usam o campo `responsavel='Juliana Raia / Clarice'` do cadastro cliente id=30 — esses ficam no chat da Juliana, sao templates legitimos

**Detritos a verificar manualmente**: chat da Juliana (id=108) tem 201 mensagens; chat da SS Qualita (id=488) tem 46 mensagens. Restaram 8 templates "Olá Juliana Raia / Clarice" do cron Social Media na janela do bug — esses foram disparos automaticos do cron pra cliente Juliana (id=30, baseado no responsavel do cadastro), nao foram movidos. Notas adicionadas em `whatsapp_contatos.notas` (id=108 e id=488).

**Auditoria geral**: nos logs (todos os meses) so existem 2 casos do bug "via unica conversa recente" — Bruna/Monique (2026-05-07, corrigido na epoca) e Juliana/SS Qualita (2026-05-11, corrigido hoje). Outros contatos com LID gravado foram resolvidos via metodos seguros (tabela clientes, pushName exato). Outro caso encontrado mas DIFERENTE: cliente social "JESIEL TELLES - TESTE" disparou templates para phone 553187621248 (Crismaria) — e problema de cadastro social, nao bug LID, nao tocado por instrucao do usuario.

**CASO ANA (descoberto 2026-05-12 15:20 apos blindagem)**: contato id=72 "Ana" (phone `553191387708`) tinha o LID `75917909086445` gravado errado. Esse LID tem pushName "Juliana Raia" — e da MESMA pessoa que o LID `68749575119071` (Clarice/SS Qualita). Ela tem multi-device WhatsApp = multiplos LIDs. A partir de ~2026-05-04 14:01, msgs da Clarice via LID 75917909086445 comecaram a vazar pra Ana. **57 msgs movidas** do contato 72 para 488. LID limpo (lid=NULL no contato 72). A Ana real so tem msgs ate 2026-04-28 no chat dela (agendamentos, atendimentos).

**Lesson definitiva**: uma pessoa pode ter MULTIPLOS LIDs (multi-device WhatsApp). Cada device gera um LID. Ao corrigir um caso de vazamento, sempre rodar audit em TODOS os outros LIDs com mesmo pushName — pode haver mais vazamentos pra outros contatos.

**REVISAO FINAL 2026-05-12 ~15:55** — usuario corrigiu a informacao de quem tem qual numero:
- **JULIANA RAIA** usa o numero `31996001399` (= `553196001399`) — cadastro id=30 CORRETO
- **CLARICE TONET TAMBOSI / SS Qualita** usa o numero `11997300033` (= `5511997300033`) — cadastro id=27 CORRETO
- **LID 68749575119071** com pushName "SS Qualita" → e da CLARICE (multi-device)
- **LID 75917909086445** com pushName "Juliana Raia" → e da JULIANA (multi-device)

Earlier interpretation (que 553196001399 era da Clarice) estava ERRADA. Eu (Claude) reverti todas as movimentacoes anteriores e ajustei:

```sql
-- Restaurar contato 108 (Juliana) com TODAS as 287 msgs dela
UPDATE whatsapp_contatos SET deleted_at=NULL, nome='JULIANA MARIA RAIA', lid='75917909086445' WHERE id=108;
UPDATE whatsapp_messages SET contact_id=108, phone_number='553196001399' WHERE session_id=1 AND phone_number='lid_68749575119071';

-- Atualizar contato 488 (SS Qualita/Clarice) com numero real e LID dela
UPDATE whatsapp_contatos SET phone_number='5511997300033', nome='SS Qualita (Clarice Tonet)' WHERE id=488;
-- LID 68749575119071 mantido (e da Clarice)
```

**Estado verdadeiro final** (alinhado com clientes cadastrados e Baileys):

| Contato | Phone | LID | Msgs | Cliente |
|---|---|---|---|---|
| 72 Ana | `553191387708` | NULL | 113 | (sem cadastro) |
| 108 JULIANA MARIA RAIA | `553196001399` | `75917909086445` | 287 | id=30 ✓ |
| 488 SS Qualita (Clarice Tonet) | `5511997300033` | `68749575119071` | 0 (clean) | id=27 ✓ |

**Comportamento futuro alinhado**:
- Clarice escreve do 11997300033 ou via LID 68749575119071 → contato 488
- Juliana escreve do 31996001399 ou via LID 75917909086445 → contato 108
- Ana escreve do 31987-7708 → contato 72
- Nenhum vazamento mais possivel (blindagem + dados consistentes)

**LICAO PRA MIM (Claude)**: SEMPRE confirmar com o usuario qual a verdade ANTES de mover dados em volume. Eu agi com base em uma resposta inicial errada do usuario e tive que reverter ~290 msgs. Em vez de assumir, deveria ter procurado mais provas (cadastros, conteudo das msgs com nomes especificos, etc) antes de mover.

**Cadastros pendentes**:
- Cliente id=39 "JESIEL TELLES - TESTE" tem fone `31987621248` que e da Crismaria Telles (atendente, id=5). Cron Social Media dispara templates errados pra ela. Usuario nao autorizou apagar.

**Schema improvement 2026-05-12 16:00**: adicionada coluna `cliente_id INT(11) NULL` em `whatsapp_contatos` (+ idx). Auto-populada para 11 contatos com match por phone (DDD>=31 strip-9). Agora existe link FORMAL entre WhatsApp contact e cadastro cliente:
- 108 Juliana → cliente_id=30
- 488 SS Qualita → cliente_id=27
- 495 Fabiane → cliente_id=31
- 121 Mislene → cliente_id=25
- 302 JSF → cliente_id=18
- 329 G Closet → cliente_id=20
- 494 Daniela → cliente_id=21
- 496 Silvana → cliente_id=12
- 107 Fortinox → cliente_id=16
- 512 Cilene/Kaua → cliente_id=33
- 5 Crismaria → cliente_id=39 (JESIEL TESTE — cadastro errado conhecido)

Demais contatos (Ana, leads sem cadastro) ficam com cliente_id=NULL. Coluna existe pro frontend evoluir e mostrar `cliente.nome` em vez de `whatsapp_contatos.nome` quando houver link.

**UI fix 2026-05-12 16:04**: bug do "zebrado" do grupo/contato selecionado. `abrirGrupo()` setava `currentGroupJid` mas nao re-renderizava a lista — highlight `.active` so aparecia apos AJAX (~2s lag). Mesmo problema com `abrirChatDireto()`. Fix: aplicar `.active` via jQuery imediatamente no item clicado, antes do AJAX. Arquivo `app/Views/whatsapp_chat/index.php` linhas 1328-1333 e 2812-2818.

**Regras absolutas reforcadas**:
- Mexer em tabelas `whatsapp_*` esta autorizado em casos urgentes para resolver mistura
- NAO mexer em tabela `clientes` mesmo se parecer errado — usuario corrige manualmente
- Nao apagar mensagens — sempre re-atribuir (mover via UPDATE)

Ver tambem: [[whatsapp_chat_cliente_nome_2026_05_11]], [[whatsapp_lid_fixes_2026_03_30]], [[feedback_chat_wa_principal_only]].