---
name: sessao-2026-05-12
description: "Sessao 2026-05-12 — URA token sync, badge WA stale e blindagem total do LID resolution"
metadata: 
  node_type: memory
  type: project
  originSessionId: 3cc4e2da-474d-47ee-96aa-7e15c6fdf186
---

# Sessao 2026-05-12

## 1. URA campanhas nao discavam

Token `CRON_TOKEN_SECRETO` dessincronizado entre `.env` da intranet e `TOKEN_SECRETO` do `/home/customer/ura_api.py` no Magnus. Toda chamada `/ura/ligar` voltava 403. Mesmo padrao do incidente do `cobranca_api.py` no dia 11. Detalhes: [[ura_token_sync_2026_05_12]].

## 2. Badge WA mostrando msg quando nao tinha

Backend retornava 1 legitimamente (Fabiane com 6 msgs `is_read=0`). Causa: user leu no celular mas Baileys nao mandou read-receipt pro webhook. Cleanup pontual (UPDATE is_read=1). Detalhes: [[wa_badge_mobile_read_gap_2026_05_12]].

## 3. WhatsApp LID atribuindo mensagens ao contato errado (CRITICO)

Bug grave: webhook chutava LID para "unica conversa recente sem pushName", causando mistura de clientes em producao. Confirmado nos logs: caso Bruna/Monique (07/05) e caso Juliana/SS Qualita-Clarice (11/05).

**Fix em 3 fases**:
1. DB cleanup — limpou LID errado da Juliana (id=108), restaurou SS Qualita (id=488), moveu 46 msgs historicas misturadas
2. Patch v1 — removeu fallback "via unica conversa recente sem pushName"
3. **Blindagem total v2** (a pedido do usuario) — desligou TODOS os caminhos heuristicos de auto-bind LID (steps 5, 6, 7). Agora so resolve via metodos confiaveis (Baileys resolvedPhone, LID direto no banco, micro-server Baileys, tabela clientes). Resto cai em `lid_xxx` para associacao manual.

Validacao real apos blindagem: msgs 7818-7833 (11:24-11:38) da SS Qualita entraram CORRETAMENTE no chat dela, nao vazaram pra Juliana. Detalhes: [[whatsapp_lid_chute_fix_2026_05_12]].

## 4. Inversao da identidade Juliana vs Clarice (tarde 15:30-15:55)

Cedo o usuario respondeu (na minha pergunta) que 553196001399 era da Clarice. Eu agi em cima disso por horas — soft-deletei contato 108 (Juliana), movi 287 msgs pra 488 (SS Qualita). Tarde o usuario corrigiu: "a JULIANA usa o 31 996001399" e "o SS qualita usa o 11 997300033". TIVE QUE REVERTER tudo:
- Restaurei contato 108 com nome JULIANA MARIA RAIA + LID 75917909086445 (multi-device dela)
- Atualizei contato 488 phone para 5511997300033 (real da Clarice) + LID 68749575119071 mantido
- 287 msgs voltaram pra 108 (Juliana)

**Estado final correto**:
| Contato | Phone | LID | Cliente |
|---|---|---|---|
| 72 Ana | `553191387708` | NULL | (sem cadastro) |
| 108 Juliana | `553196001399` | `75917909086445` | id=30 |
| 488 SS Qualita (Clarice) | `5511997300033` | `68749575119071` | id=27 |

LICAO PRA MIM: SEMPRE confirmar com o usuario QUEM e dono do numero antes de mover dados em volume. A primeira resposta dele estava errada, eu agi, depois reverti.

## 5. Schema improvement: cliente_id formal em whatsapp_contatos

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. Permite frontend evoluir e mostrar `cliente.nome` quando houver link. Demais contatos (Ana, leads sem cadastro) ficam com cliente_id=NULL.

## 6. UI fix: highlight do grupo/contato selecionado

`abrirGrupo()` e `abrirChatDireto()` setavam o `currentGroupJid`/`currentPhone` mas nao re-renderizavam a lista — highlight `.active` so aparecia apos AJAX (~2s lag). Fix: aplicar `.active` via jQuery imediatamente no item clicado, antes do AJAX. Usuario reclamou "o zebrado naõ funciona corretamente para mostrar qual grupo cliquei!!!".

## Lessons da sessao

- **NUNCA mexer em cadastro de clientes sem confirmacao explicita** — usuario reforcou "se for mexer so no whatsapp pode resolver tranquilamente so nao pode afetar cadastros". Tabelas `whatsapp_*` autorizadas; tabela `clientes` proibida.
- **Heuristicas de matching por nome sao perigosas em sistemas multitenant** — pushName partial/exato podem parecer seguras mas sao bombas-relogio quando 2+ contatos compartilham nome ou padroes. Melhor cair em fallback explicito (`lid_xxx`) do que chutar.
- **NUNCA apagar mensagens** — sempre mover via UPDATE de `contact_id` + `phone_number`. Nao perder historico mesmo quando esta em contato errado.
- **Validar tudo no servidor online via SSH/MySQL** — local nao reflete producao real.
- **CONFIRMAR identidade ANTES de mover em volume** — uma pessoa pode ter multiplos LIDs (multi-device), mesmo pushName em devices diferentes, e o usuario pode dar resposta errada em pergunta inicial. Mover dados sempre apos certeza tripla (cadastro + LID + conteudo).
- **`cliente_id` na whatsapp_contatos** e o caminho profissional pra resolver mistura — sem essa coluna, o sistema dependia de match implicito por phone (frágil quando phone troca de dono fisicamente). Agora ha link formal.