RA1000
Agente Reclame Aqui — varredura, classificação, resposta humanizada, roteamento e escalação automática
RA1000 é o agente que monitora o perfil Ícaro Express no Reclame Aqui, classifica reclamações, posta respostas humanizadas (assinadas como "Cláudio"), roteia pro líder de filial certo, e escala automaticamente se ninguém responder.
Toda reclamação tem histórico append-only com timestamp BRT e cada notificação inclui o histórico cumulativo (anteriores + novo evento).
Estado atual (4 maio 2026)
- ✅ Pipeline rodou ponta-a-ponta pela primeira vez com a reclamação #247604999 (Wallace Murillo)
- ✅ 13 eventos registrados no histórico_log da reclamação
- ✅ Email cumulativo enviado pra base SAO + Jimmy CC + Rubens BCC
- ✅ Magic link Kevin emitido (válido 7d)
- ✅ OAuth Gmail
ra1000@zzyon.com100% configurado - ✅ Token GraphQL ESL Cloud no Supabase Vault
- ✅ Chrome MCP no Mac mini logado no painel RA Business
1. Visão Geral em 1 Diagrama
ENTRADA: Cliente abre reclamação no Reclame Aqui
↓
RA dispara EMAIL → ra1000@zzyon.com + fica no painel "Não Respondidas"
↓
├─ SKILL inbox-watch (cron */5min, OAuth Gmail)
└─ SKILL ra1000-watcher (cron */15min, Chrome MCP painel RA)
↓
SCRAPE detalhe: CPF, telefone, email, pedido, embarcador, motivo
↓
UPSERT cs_ra_reclamacoes (Trigger auto-atribui filial via cs_ra_find_lider)
log_event(reclamacao_aberta, dados_extraidos)
↓
TENTATIVA LOOKUP ESL Cloud GraphQL (token Vault)
log_event(tentativa_lookup_esl, resultado)
↓
CLASSIFICAÇÃO: Fluxo A (no prazo) / B (intercorrência) / C (falha) / D (faltam dados)
↓
GERAÇÃO DRAFT via LLM Sonnet 4.6 (assinatura "Cláudio · Atendimento Ícaro Express")
↓
├─ Fluxo A* (promete data) → AGUARDA OK GESTOR via WA, 1h30 timeout → escala Rubens
└─ Fluxo B/C/D (sem promessa de data) → AUTO-POSTA
↓
POSTAGEM no painel RA via Chrome MCP (24/7)
log_event(resposta_postada_no_ra)
↓
NOTIFICAÇÃO multi-canal cumulativa (sempre histórico append-only):
• EMAIL: TO base filial · CC Jimmy · BCC Rubens
• WHATSAPP: líder filial + Kevin + Rubens + (Jimmy se TI)
• Subject canônico: CPF | Nome | Embarcador | NF | RA #ID
↓
CLIENTE RESPONDE NO RA
↓
SKILL ra1000-replier */15min:
• Se passou NF → query freight{invoiceKey} no ESL → status real
• Gera follow-up Fluxo A/B/C apropriado
• Se promete data: aciona gestor pra confirmar
• Posta + email cumulativo (todos eventos anteriores + novos)
↓
CASO RESOLVIDO → RA pede 3 campos nativos: resolvido / nota 0-10 / voltaria
↓
SKILL ra1000-avaliador */30min:
• Captura avaliação
• Se nota baixa → ALERTA + tréplica pública (botão tréplica RA, 30d janela)2. Padrão de assunto (todos os emails RA1000)
CPF NNN.NNN.NNN-NN | Nome Completo | Embarcador | NF NNNNNN | RA #IDEx: CPF 424.428.158-42 | Wallace Murillo de Oliveira Rodrigues | Terabyte | NF pendente | RA #247604999
3. Histórico append-only
Cada evento na vida da reclamação vira uma entrada em
cs_ra_reclamacoes.historico_log (JSONB array):
{
"ts": "2026-05-04 11:36:42 BRT",
"actor": "sistema:claudio_ai",
"event": "resposta_postada_no_ra",
"source": "painel_ra_business",
"details": {
"via": "chrome_mcp",
"painel_url": "https://www.reclameaqui.com.br/area-da-empresa/...",
"confirmacao": "Resposta enviada com sucesso"
}
}Função: cs_ra_log_event(ra_id, actor, event, details, source) — append-only,
nunca apaga, nunca edita.
Eventos canônicos
reclamacao_aberta cliente abre no RA
detectada_no_painel_ra SKILL watcher captura
detectada_no_email SKILL inbox-watch captura
dados_extraidos CPF, telefone, NF, embarcador via scrape
tentativa_lookup_esl queries GraphQL + resultado
fluxo_detectado A/B/C/D + severidade C1-C5
draft_gerado LLM Sonnet 4.6 + custo_usd
draft_aprovado humano: rubens / gestor
data_proposta_gestor quando Fluxo A pede data ao gestor
data_confirmada_gestor gestor responde via WA
escalacao_rubens timeout 1h30 sem resposta gestor
resposta_postada_no_ra Chrome MCP via painel
gestor_alertado WA pra líder filial
email_base_filial email cumulativo TO+CC+BCC
kevin_acionado WA pra Kevin com link
jimmy_acionado_ti escalation TI se RA não sync
rubens_copia cópia executiva
cliente_respondeu mensagem nova no thread RA
followup_postado nova resposta nossa após dado novo
avaliacao_recebida cliente fechou: nota+resolvido+voltaria
treplica_postada nota baixa → resposta pública4. Schema Supabase (project hbrvoairynwsliyxxgsg)
Tabelas
| Tabela | Papel |
|---|---|
cs_ra_reclamacoes | Canonical RA1000 (uma linha por RA) |
reclamacoes_ra | Legacy — alimentada por SKILLs antigas |
cs_ra_routing_rules | 7 regras: SAO/RIO/CPQ/CWB/BHZ/JOI + FALLBACK |
cs_ra_drafts | Drafts LLM antes de postar |
cs_ra_publicacoes | Auditoria de postagens |
cs_ra_avaliacoes | Notas/feedback |
cs_ra_replicas | Tréplicas públicas |
cs_ra_acoes | Ações operacionais |
cs_ra_esl_lookups | Cache de queries ESL |
cs_ra_emails_recebidos | Inbox watcher events |
cs_ra_metricas_diaria | Agregações |
cs_ra_lider_perfil | Cadastro completo dos líderes (CPF validado módulo-11) |
cs_ra_magic_sessions | Tokens magic-link 7d para acesso ao site |
Coluna nova
cs_ra_reclamacoes.historico_log JSONB— append-only
Functions
fn_validar_cpf(text) → bool -- algoritmo módulo-11
cs_ra_find_lider(uf, cidade) → record -- prioridade cidade > UF > FALLBACK
cs_ra_atribuir_filial_auto() -- TRIGGER BEFORE INSERT/UPDATE
cs_ra_log_event(ra_id, actor, event, details, source) → jsonb
cs_ra_lider_precisa_atualizar(lider, max_dias=30) → boolViews (8)
vw_cs_ra_pulso_hoje · vw_cs_ra_aging_pendentes · vw_cs_ra_filial_score ·
vw_cs_ra_ar_realtime · vw_cs_ra_top_origem_problema ·
vw_cs_ra_alertas_pendentes_escalacao · vw_cs_ra_notifications_abertas ·
vw_cs_ra_stats_filial
5. Edge Functions
| Edge Function | Versão | Cron | Papel |
|---|---|---|---|
ra-upsert | v2 | event | Insert/update single reclamação canonical |
cs-ra-router | v2 | event | Roteia WhatsApp via cs_ra_find_lider |
ra-sync-xlsx | v2 | event | Batch upsert XLSX → ambas tabelas |
cs-ra-escalation | v1 | */15min | Escala alertas pendentes 1h/3h sem resposta |
cs-ra-magic-auth | (planejada) | event | Validar token + criar session 7d |
6. Integrações Externas
| Integração | Endpoint | Auth | Uso |
|---|---|---|---|
| Reclame Aqui — Painel Business | /area-da-empresa/... | Email + senha (Cloudflare) | Scrape + post via Chrome MCP |
| Reclame Aqui — Email | ra1000@zzyon.com | Gmail OAuth (refresh_token) | Inbox watch |
| ESL Cloud TMS | https://icaro.eslcloud.com.br/graphql | Bearer (Vault ESL_TOKEN) | freight/cte/individual |
| Evolution API | 100.65.23.99:8080 | API key | WhatsApp icaro-claudio |
| Gmail API | googleapis.com | OAuth zyon-ra1000 | Send email cumulativo |
| Chrome MCP | extensão local | sessão Mac mini | Driving navegador logado |
| Anthropic LLM | api.anthropic.com | API key | Drafts via Sonnet 4.6 |
7. Roteamento — 7 Filiais
| Filial | UF | Líder | Email base | |
|---|---|---|---|---|
| SAO | SP | Gabriel | +5511960930058 | gabriel.araujo@icaroexpress.com |
| CPQ | SP/Campinas | Rafael | +5511981490167 | rafael.gomes@icaroexpress.com |
| RIO | RJ | Davi | +5521980452711 | atendimentorj@icaroexpress.com |
| CWB | PR | Emerson | +5541988791939 | emerson.pauletti@dibasetransportes.com.br |
| BHZ | MG | Renato | +5531991168906 | renatosoares.bhz@gmail.com |
| JOI | SC | Jimmy (TI+filial) | +5547988146171 | frota@icaroexpress.com |
| FALLBACK | * | Kevin | +5547997571032 | (sem) |
Sempre CC: Jimmy frota@icaroexpress.com
Sempre BCC: Rubens rubens@icaroexpress.com.br
CPQ é override por cidade=Campinas, prioridade 10 > regra SAO prioridade 5.
8. Fluxos A/B/C/D
| Fluxo | Quando | Aprovação Gestor? | Auto-posta? |
|---|---|---|---|
| A — No prazo | ESL com previsão futura | Sim (1h30 timeout → escala Rubens) | ❌ |
| B — Intercorrência | Cliente ausente, SEFAZ, etc. | — | ✅ |
| C — Falha nossa | Atraso reconhecido / entregue tarde | — | ✅ |
| D — Dados faltando | ESL sem match → pede NF/CPF | — | ✅ |
Regra de ouro: "A única resposta que precisa de confirmação do gestor é a data de entrega" — Rubens, 2026-05-04.
9. Janelas operacionais
- Postagem RA: 24/7 (RA aceita posts a qualquer hora)
- WhatsApp/Email pro CLIENTE: 08h-20h BRT
- WhatsApp/Email INTERNO (líder, Jimmy, Rubens, Kevin): 24/7
10. Magic Link + Cadastro Líderes
Acesso → https://ra.zzyon.com/m/<token-32chars>
↓
Verifica cs_ra_magic_sessions (token + expira_em > now)
→ renova expira_em +7d a cada acesso
↓
cs_ra_lider_precisa_atualizar(lider, 30d) ?
├─ TRUE: form obrigatório (CPF módulo-11 + RG + endereço + CNH...)
│ persiste em cs_ra_lider_perfil + ultima_atualizacao=now()
│ a cada 30d revalida
└─ FALSE: dashboard direto
↓
Dashboard mostra reclamações da filial do líder + açõesCampos obrigatórios do cadastro
- Nome completo
- CPF (validado módulo-11)
- RG · Data nascimento · Nome da mãe
- Endereço completo (CEP, rua, número, complemento, bairro, cidade, UF)
- WhatsApp + telefone fixo + email
- Cargo · Data admissão · Matrícula
- CNH (número, categoria, validade)
11. Validação CPF (testada)
| Input | Esperado | Resultado |
|---|---|---|
424.428.158-42 (Wallace) | válido | ✅ |
111.111.111-11 (repetidos) | inválido | ✅ rejeitado |
123.456.789-09 | válido (algoritmo) | ✅ |
'' (vazio) | inválido | ✅ rejeitado |
NULL | inválido | ✅ rejeitado |
12. Templates aprovados
Todas as respostas são assinadas como "Cláudio · Atendimento Ícaro Express".
Anti-padrões banidos no prompt LLM
NUNCA usar:
- "Conforme nosso sistema..."
- "Aguardamos sua compreensão"
- "Sua reclamação é importante para nós"
- "Pedimos a gentileza de aguardar"
- "Em breve" / "Logo" / "Brevemente"
- "Prezado(a) cliente" → usar primeiro nome
- "Conforme procedimento"
- Qualquer emojiRegras importantes nos templates
- Motorista NÃO faz contato proativo — não prometer ligação prévia
- Endereço de NF não pode ser alterado pelo transportador — se diferente, cliente aciona embarcador (regra fiscal/contratual)
- Janela de retorno: até 2h durante horário comercial após receber dados (não 30min)
- NUNCA pedir nota 10 — pedir sinceridade na avaliação
- Pedido de avaliação: condicional (não pedir se cliente saiu irritado, >7d, >3 mensagens)
13. Onde está
- Schema: zyon-agents/ra1000/migrations/ (001 schema base, 002 routing, novas migrations Supabase MCP)
- Helpers Python:
zyon-agents/ra1000/lib/gmail_ra1000.py— OAuth Gmail (read inbox, send email)zyon-agents/ra1000/lib/inbox_watcher.py— polling RA emailszyon-agents/ra1000/lib/sync_xlsx_to_supabase.py— batch upsert XLSXzyon-agents/ra1000/scripts/oauth_setup.py— one-time refresh_token
- SKILLs:
~/.claude/scheduled-tasks/reclameaqui-*(Mac mini) - Secrets:
~/.zshrcMac mini (RA_INGEST_TOKEN,RA1000_GMAIL_*)- Supabase Vault (
ESL_TOKEN,ICP_A1_PFX_*futuro)
- Supabase Vault (
14. Pendências pra próxima sessão
| # | Item | Responsável | Estimativa |
|---|---|---|---|
| 1 | Frontend /m/<token> em torre-ra | frontend chat | 2h |
| 2 | Edge function cs-ra-magic-auth | backend | 1h |
| 3 | Magic links pros 6 líderes restantes | esta sessão (1 INSERT cada) | 5min |
| 4 | SKILL ra1000-watcher cron */15min | esta sessão | 1h |
| 5 | SKILL ra1000-replier (cliente respondeu → ESL → followup) | esta sessão | 1h |
| 6 | SKILL ra1000-avaliador cron */30min | esta sessão | 30min |
| 7 | Cadastrar SKILLs como Scheduled Tasks no Mac mini | user (1 click cada) | 15min |
15. Painel ao vivo
ra.zzyon.com — Torre RA1000 com:
- Aba RA1000 Pulso (default): visão canônica nova com KPIs hoje, pendentes por filial, aging, score por filial
- Aba Tratativa: visão legada com texto integral + status ESL
16. ⚠️ Pegadinha importante — escrita em DUAS tabelas
O painel ra.zzyon.com lê das views vw_ra_monitor / vw_ra_tratativa,
que derivam da tabela legacy reclamacoes_ra. A canonical nova
cs_ra_reclamacoes NÃO alimenta o painel atual.
Toda nova reclamação processada precisa escrever em DUAS tabelas:
-- 1) Legacy (alimenta painel ra.zzyon.com)
INSERT INTO reclamacoes_ra (numero_ra, data, cliente, ...)
-- 2) Canonical (alimenta vw_cs_ra_pulso_hoje + futuro UI v2)
INSERT INTO cs_ra_reclamacoes (ra_id, cliente_nome, ..., historico_log)Constraint check em reclamacoes_ra.status_ra:
'aberta' | 'respondida' | 'resolvida' | 'nao_resolvida' | 'em_replica' | 'aguardando'
Sem o INSERT na legacy, a UI atual não enxerga a reclamação. Pendente:
trigger bidirecional cs_ra_reclamacoes ↔ reclamacoes_ra pra evitar
dessincronia (próxima migration).
17. Aba "Configurações → Notificações" (especificação do frontend)
Pedido Rubens 2026-05-04: aba no ra.zzyon.com pra cadastrar emails e
selecionar regras de quem recebe cada tipo de evento.
Backend (já aplicado)
Tabelas:
cs_ra_evento_tipos (10 eventos canônicos)
cs_ra_notification_rules (regras selecionáveis por filial+evento+canal)
cs_ra_emails_extras (emails/whatsapps adicionais por filial+evento)Função helper:
SELECT * FROM cs_ra_resolver_destinatarios('reclamacao_nova', 'SAO');
-- retorna: lider_filial + jimmy_cc + rubens_bcc + extras configuradosEventos canônicos (10)
reclamacao_nova Nova reclamação detectada
resposta_postada Resposta postada no RA
cliente_respondeu Cliente respondeu na reclamação
aguardando_data_gestor Aguardando confirmação de data (Fluxo A)
escalacao_rubens Timeout 1h30 sem resposta gestor
avaliacao_alta Cliente avaliou nota >= 8 + Voltaria=Sim
avaliacao_baixa Cliente avaliou nota < 5 OU Voltaria=Não
treplica_disparada Resposta nossa em avaliação negativa
reincidencia_cliente Cliente já tinha reclamação anterior sem resposta
falha_tecnica Erro de scraping/API/OAuthFrontend pendente (torre-ra)
Aba Configurações → Notificações deve mostrar:
1. Tabela de emails extras (cs_ra_emails_extras)
- Colunas: rótulo · email · whatsapp · filial · eventos · ativo · ações
- Botão "Adicionar email extra"
- Modal: nome do contato, email/WA, filial (dropdown — filial específica ou todas), eventos (multi-select dos 10) — ativo
2. Regras de notificação (cs_ra_notification_rules)
- Lista por evento → filial → canal (email/whatsapp/ambos)
- Toggle "Incluir líder filial automático"
- Toggle "Incluir Jimmy em CC"
- Toggle "Incluir Rubens em BCC"
- Custom CC/BCC adicionais
3. Preview de resolução
- Selecionar
evento + filial→ mostrar quem RECEBERIA usandocs_ra_resolver_destinatarios() - Útil pra validar antes de salvar
4. Permissões
- Apenas líder com perfil
cargo='admin'ouRubenspode editar - Outros líderes só visualizam
Validações no frontend
- Email format (regex padrão)
- WhatsApp format BR (E.164:
+55XXXXXXXXXXX) - Pelo menos 1 canal preenchido (email OU whatsapp)
- Filial: dropdown com codes de
cs_ra_routing_rules.filial_codigo
Endpoints sugeridos (a criar como edge function ou Supabase RPC)
GET /api/ra/eventos → lista eventos canônicos
GET /api/ra/notification-rules → lista regras configuradas
POST /api/ra/notification-rules → criar regra
PUT /api/ra/notification-rules/:id → editar
DELETE /api/ra/notification-rules/:id → desativar (soft delete: ativo=false)
GET /api/ra/emails-extras → lista emails extras
POST /api/ra/emails-extras → adicionar
PUT /api/ra/emails-extras/:id → editar
DELETE /api/ra/emails-extras/:id → desativar
GET /api/ra/resolver?evento=X&filial=Y → preview destinatários18. Caso de referência: Wallace Murillo (RA #247604999)
Primeira reclamação processada fim-a-fim com o pipeline novo:
- Cliente: Wallace Murillo de Oliveira Rodrigues
- CPF: 424.428.158-42 (validado)
- Embarcador: Terabyte (pedido 8036412)
- Filial: SAO → Gabriel
- Cenário: 3 tentativas falhas com motorista marcando "endereço não localizado"; 2ª reclamação RA do mesmo cliente (1ª ficou sem resposta)
- Fluxo aplicado: C grave + pedido de dados (limite operacional NF)
- Resposta postada: 2026-05-04 11h36 BRT
- Histórico: 13 eventos registrados em
historico_log - Notificações: Email pra base SAO + Jimmy CC + Rubens BCC + WhatsApp pra Gabriel/Kevin/Jimmy/Rubens