type: decisions

tags: [comercialrs, decisions]

created: 2026-06-26

ComercialRS — DECISIONS

> Decisões arquiteturais e de negócio tomadas neste projeto.

2026-06-26 — Migração Vault para Estrutura de Neurônios

Contexto: Reformulação completa do vault Ultron com estrutura neuronal.

Decisões:

• - Nova estrutura: NEURONS// com MEMORY, DECISIONS, LOGS, TOOLS, DOCUMENTATION
• - Função vault: Guia e Backup
• - Regra: salvar só quando usuário mandar
• - Arquivos existentes migrados, nada apagado

---

2026-06-26 — Bug: Ocultar Canais + Template Video

Contexto: Bug onde "ocultar canais" está ON mas a mensagem enviada Still inclui "📹 Vídeo".

Diagnóstico (Ultron, 26/Jun/2026):

Fluxo de criação de reunião

1. Frontend: TaskCreateDialog.tsx → cria task → envia task_created para dispatch-automation

2. Edge Function dispatch-automation: recebe payload com channel, defaults para 'mensagem' se null

3. Template nova_reuniao_criada enviado com params: [title, responsibleName, channelName, dateStr, timeStr, link]

4. Se channel = 'video', channelName = '📹 Vídeo'

Bug identificado

• - hideChannelOnCreate é salvo em localStorage do browser (UI-only)
• - NÃO é enviado para o backend/database
• - Task criada com channel = null ou 'mensagem'
• - Mas o template enviado pode estar usando um valor hardcoded ou diferente

Solução proposta

1. Criar template nova_reuniao_criada_sem_canal (sem parâmetro de canal)

2. Adicionar campo template_sem_canal na tabela automations_config

3. Na Edge Function dispatch-automation: se channel for null ou 'sem_canal', usar template sem canal

4. Frontend: ao criar com hideChannelOnCreate=true, enviar channel: 'sem_canal' ou null de forma consistente

Status: Suspenso — aguardando correção de permissions (Nayara/Victoria sem cargo corretor).

---

2026-06-26 — CORRIGIDO: AdmGuard redirecionava admin para Dashboard (bug na query)

Problema: Admin logava mas era sempre redirecionado do /adm para o Dashboard ao clicar no escudo. Sessão funcionava, banco confirmava role=admin, mas AdmGuard sempre retornava isAdmin: false.

Causa raiz: Query usava coluna errada em AdmGuard.tsx:

`tsx

// ❌ ERRADO — 'id' do profile (UUID gerado, diferente do auth user_id)

.eq('id', session.user.id)

// ✅ CORRIGIDO — 'user_id' (foreign key que referencia o auth user)

.eq('user_id', session.user.id)

`

O profiles.id é UUID interno do banco. O session.user.id é UUID do Auth. Nunca eram iguais.

Arquivo alterado: /var/www/comercialrs/src/components/adm/AdmGuard.tsx

Build: npm run build → root-DxBQV-Zu.js (539KB)

Deploy: /var/www/comercialrs/dist/ (VPS)

Teste: Ctrl+Shift+R → login TecRocha → clicar escudo → entra no /adm ✅

Pendências:

1. Testar login de Victoria e Nayara

2. Bug "ocultar canais": template ainda envia canal mesmo quando deve ocultar — prioridade

---

2026-06-26 — PENDENTE: Bug "Ocultar Canais"

Problema: Toggle "ocultar canais" está ON mas a mensagem enviada ainda inclui "📹 Vídeo".

Causa raiz:

• - hideChannelOnCreate é salvo em localStorage do browser (UI-only)
• - NÃO é enviado para o backend/database
• - Task criada com channel = null ou 'mensagem'
• - Mas o template enviado pode estar usando um valor hardcoded

Solução proposta:

1. Criar template nova_reuniao_criada_sem_canal (sem parâmetro de canal) OU usar placeholder -

2. Adicionar campo template_sem_canal na tabela automations_config

3. Na firecrawl_server: se channel for null/vazio, usar template sem canal

4. Frontend: ao criar com hideChannelOnCreate=true, enviar channel: null ou vazio

Status: Não iniciado.

---

2026-06-26 — NOVO: Victoria e Nayara não veem reuniões (Painel ADM quebrado)

Problema: Victoria e Nayara com role "broker" no banco, mas não viam reuniões atribuídas a elas.

Diagnóstico:

• - user_roles estava VAZIA [] — não tinha nenhum registro
• - profiles.role = broker ✅ (correto)
• - team_members.role = broker ✅ (correto)
• - Mas quando user_roles está vazia, changeRole() no AdmUsers fazia DELETE + INSERT em vazio, causando comportamento inconsistente
• - O mapa authToTeamMemberId no AppDataContext linking profile.email = team_member.email parecia correto, mas o usuário reportou que não funcionava

Correção 1 — Bug nos IDs (26/jun/2026):

• - As notas de 26/jun usaram profiles.id (UUID interno) em vez de auth.users.id
• - b5962b21-1092-491a-a814-a823024c3a2e = Victoria's profiles.id ❌
• - 14af679a-c860-410d-b2d4-ce1720782635 = Victoria's auth.users.id ✅
• - 02bea24f-b246-4f07-af86-f1f04298bbac = ID antigo da Nayara ❌
• - 95cf1f71-d0d3-4f51-8dd8-5943a9296b6f = Nayara's auth.users.id ✅
• - Conclusão: O INSERT de 26/jun falhou silenciosamente por usar IDs errados

Correção 2 — Inserir Victoria e Nayara na user_roles (30/jun/2026):

`bash

Victoria (auth.users.id: 14af679a-c860-410d-b2d4-ce1720782635)

Nayara (auth.users.id: 95cf1f71-d0d3-4f51-8dd8-5943a9296b6f)

INSERT INTO user_roles (user_id, role) VALUES

('14af679a-c860-410d-b2d4-ce1720782635', 'broker'),

('95cf1f71-d0d3-4f51-8dd8-5943a9296b6f', 'broker')

ON CONFLICT DO NOTHING;

`

Correção 3 — Bug no AdmUsers.tsx (changeRole):

• - changeRole() fazia DELETE + INSERT SEMPRE, mesmo sem mudar nada
• - Se user_roles estava vazia e o role era o mesmo, não havia registro pra deletar mas o INSERT era feito
• - FIX: Adicionado guarda if (roles[userId] === newRole) return no início
• - Adicionado branch if (!oldRole) que só sincroniza profiles + team_members sem DELETE

Arquivo alterado: /var/www/comercialrs/src/pages/adm/AdmUsers.tsx

Deploy: Build feito (npm run build) + arquivos já em /var/www/comercialrs/dist/ (VPS local)

Service restart: Não necessário (é frontend estático via nginx)

Teste: Victoria e Nayara fazem login no CommercialRS e verificam se veem as reuniões atribuídas a elas.

Status: CORRIGIDO (30/jun/2026) — IDs errados na inserção de 26/jun. Reinserido com auth.users.id correto.

Pendências:

1. Testar login de Victoria e Nayara

2. Bug "ocultar canais": template ainda envia canal mesmo quando deve ocultar — prioridade

---

2026-06-26 — Investigação: Mensagens não estão chegando

Contexto: "Primeiro preciso saber como está chegando e se os buttons do template estão funcionando." — Rocha Sales

Investigação (Ultron, 26/Jun/2026):

Achados principais

#### 1. Meta Token funciona

• - Teste via curl direto para Graph API: ✅ message_status: accepted
• - Token consegue enviar template nova_reuniao_criada

#### 2. Existem DUAS VERSÕES do dispatch-automation rodando

Versão	Tipo	Status
---	---	---
dispatch-automation.py (systemd)	Python, porta 9002	✅ Rodando, mas quebrado
Edge Function TS (Supabase Edge Runtime)	TypeScript	⚠️ Provavelmente quebrado

#### 3. Python dispatcher (systemd) — problema identificado

• - Arquivo: /var/www/comercialrs/dispatch-automation.py
• - Log: /var/log/dispatch-automation.log
• - Última task_created processada: 18:06 em 25/Jun/2026 (parou)
• - Erro: [dispatch] task_created → 5511940858953: False — todas retornam False
• - Causa raiz: O dispatcher busca automations_config do banco LOCAL via Kong (http://127.0.0.1:8000/rest/v1/), mas o token JWT usado (service_role com ref=rochasales) tem assinatura que não bate com o JWT secret do PostgREST local (ref=rochasales)

- O PostgREST valida com o secret local (ref=rochasales), mas o token tem ref claim que bate... porém o sub está como 00000000-0000-0000-0000-000000000000

- Possível causa: o PostgREST está validando o JWT secret local vs o token que foi gerado com JWT secret diferente

- O anon key (ref=rochasales) funciona: retorna {"id":"a17bf11a-6e2f-4980-b8f2-5a1f7c7970a0","provider":"meta"}

- O dispatcher usa o token service_role hardcoded que foi gerado para o projeto antigo rochasal (Supabase Cloud)

#### 4. Confirmação do fluxo completo

• - Frontend (ComercialRS) → supabase.functions.invoke("dispatch-automation", ...) → Edge Function TS (Supabase Edge Runtime)
• - OU: Frontend → Kong → Python dispatcher (porta 9002) em /functions/v1/dispatch-automation
• - Edge Function TS usa banco Supabase Cloud (projeto dauftiqcvgaydddoxqhh)
• - Python dispatcher tenta usar banco Supabase local (kong → postgrest local)
• - Ambas versões enviam via Meta Graph API (token funciona)

#### 5. Últimas 48h — tasks criadas

• - 22/Jun: 48 tasks
• - 19/Jun: 21 tasks
• - 18/Jun: 21 tasks
• - Última task com message_log: 22/Jun
• - Não há tasks criadas entre 23-26/Jun no message_log

#### 6. Telefone do corretor

• - Payload inclui responsible_phone que é o telefone do team_member
• - Phone ID da Meta: 5511940858953 aparece nos logs (formato brasileiro)

#### 7. Bug crítico no código: broadcastMetaTemplate

• - Linha 277 do Edge Function TS: taskId referenciando variável não definida no escopo da função
• - broadcastMetaTemplate(config, members, templateName, langCode, params) — sem taskId
• - Usado em: meetings_overdue_summary, risk_alerts

Próximos passos (aguardo decisão do usuário)

1. Confirmar se o problema é o JWT token do dispatcher Python vs o PostgREST local

2. Decidir: usar Supabase Cloud diretamente (com token válido) ou corrigir o dispatcher Python

3. Verificar se o problema também está no Edge Function TS (Supabase Cloud tem exceed_egress_quota)

---

2026-06-26 — CORRIGIDO: Template + message_log

Contexto: WhatsApp não chegava apesar de wamid ser retornado. firecrawl_server enviava texto plano (type:text) em vez de template aprovado.

Causa raiz:

1. send_whatsapp_message() usava type: 'text' — não ativa botões, deliverability baixa

2. INSERT message_log usava nomes de coluna errados (message_id → correto é meta_message_id)

Correção em /var/www/comercialrs/firecrawl_server.py (Ultron, 26/Jun/2026):

• - Nova função send_template_message() — envia type: 'template' com 6 params nova_reuniao_criada
• - Nova função insert_message_log() — INSERT com nomes corretos via Kong REST anon key
• - dispatch_event(): task_created agora usa template, outros eventos usam texto plano
• - Placeholder - para params vazios (Meta rejeita strings vazias)
• - Data formatada dd/mm/yyyy automaticamente
• - channel emoji: video=📹, call=📞, chat=💬

Teste confirmado:

• - wamid.HBgN... enviado para 5511913412661 (Davi)
• - ✅ Chegou no WhatsApp com botões "iniciada / concluída / remarketing"
• - ✅ message_log gravado com status: sent

Reinício: sudo systemctl restart firecrawl (service name: firecrawl.service)

Pendências:

1. Adicionar telefones NULL em team_members (Pietra, Nayara)

2. Remover dispatch-automation.py (porta 9002) quebrado para evitar confusão

3. Bug "ocultar canais": template ainda envia canal mesmo quando deve ocultar — prioridade