SOL · pilar único SDR

Central completa da revisão. Página gerada por scripts/gerar-sol-sdr.py lendo a API do n8n PROD e os artefatos aprovados da revisão — nenhum número é digitado à mão.

Os três eixos — independentes

vida = pertencimento arquitetural (tag vida:*, só muda com evidência de aposentadoria). n8n = estado de runtime (campo active). revisão = varredura Workplace (tag workplace:*). Nenhum é derivado do outro.

Revisão Workplace — onde estamos

Acompanhamento por estado, não por conversa. O progresso é acumulado: uma regressão vira REABERTO e incrementa o contador, sem apagar o que já foi feito.

Por workflow

Bloqueadores reais

Só o que de fato impede fechar. Descoberta lateral vai para backlog e não trava o selo.

• Ingestão Landing: contact_id fica NULL — o nó Krolik GET contact nao devolve id; a resposta do envio ja traz contactId (correcao pendente)
• WHATSAPP DIRETO: leitura e ingestao ainda dentro do sol.inbound.whatsapp
• Credencial morta Meta Page Token SOL: 1 referencia no [SOL] Meta Leadgen arquivado

Placar da CAPTAÇÃO

A cadeia não fecha porque "o workflow roda". Fecha quando se responde, sem inferência: quantos entraram, por qual caminho, quantos viraram registro válido, quantos chegaram ao SolarMarket, quantos receberam a primeira abordagem, quantos ficaram pendentes, e se existe backlog.

Caminhos de entrada — estado real

Entradas por dia

Entrada = telefone que não existia antes. META_LEAD_ADS + LANDING_PAGE + WHATSAPP_DIRETO. A última coluna, respostas, é mensagem de lead que já existia — isso é início da QUALIFICAÇÃO e está fora da conta de aquisição, de propósito. Linha marcada = nenhum lead do formulário Meta naquele dia.

Backlog do formulário Meta

No instante da quebra a conta fechava exata: 162 meta_ads no Supabase = 120 reais do form (122 menos 2 leads de teste da propria Meta) + 42 do backlog do form anterior. Zero represado. Depois de 16/08 00:20 UTC nao ha como contar: a Graph nao responde para a credencial do poll, entao todo lead que entrou no formulario desde entao esta invisivel para nos.

Regra: Entrada da CAPTACAO = META_LEAD_ADS + LANDING_PAGE + WHATSAPP_DIRETO. Resposta de lead que ja existia NAO entra na contagem de entrada: e inicio da QUALIFICACAO. A coluna "respostas" abaixo esta fora da conta de aquisicao, de proposito.

QUALIFICAÇÃO NORMAL 100%

A regra que essa cadeia inteira defende: valor informado no formulário não é conta validada. O valor declarado é sinal comercial; a conta de energia é prova. Só o OCR abre o gate.

Gates e garantias

Prova ponta a ponta — lead 612449 / projeto SM 14770

Consumo lido na conta

Cobertura do backend

Nenhum evento de IA sem precificacao: todo uso registrado tem custo calculado.

1 leads historicos ainda tem ts_handoff anterior a ts_qualificado. Sao anteriores a correcao e nao foram saneados — o saneamento so entra depois que o escritor esta certo, e agora esta.

SLA do handover — série histórica

O writer antigo gravava ts_handoff no início do handover, em ramo paralelo, enquanto o filho regravava ts_qualificado no fim. Resultado: 34 leads com SLA fisicamente impossível — handover antes da qualificação.

Distribuição do ts_handoff − ts_qualificado reconstruído: mín 0.656s · mediana 2.853s · p95 5.717s · máx 10.86s. Nenhum outlier absurdo.

Regressão no writer novo: 612453 +11.108s · 612457 +12.27s · 612449 +11.585s — todos positivos.

Ressalva de leitura: Os historicos foram reconstruidos pelo instante da TRANSFERENCIA DO CHAT ao closer. O writer novo carimba ts_handoff quando o handover INTEIRO termina (SolarMarket + Krolik + gestao), alguns segundos depois. As duas metades da serie medem pontos ligeiramente diferentes do mesmo evento.

Regra de encerramento — quando a SOL para

Regra auditada nos 26 em 13/08/2026: o filtro de elegibilidade do sol.followup.janela-24h exige status in (ABERTO,QUALIFICACAO) e ts_qualificado is null e ts_transferido is null e ts_desqualificado is null — quatro guardas. Nenhum fluxo de SDR ou FUP retoma atuação depois do FIM SOL. Exposição residual: sol.followup.reprocessa-parados e sol.ops.altera-status-lead são webhooks sem autenticação que conseguem reescrever status e ressuscitar um lead encerrado.

Nas duas saídas a atuação da SOL como SDR termina naquele lead. Depois do handoff quem conduz é o closer, e o desfecho comercial mora no SolarMarket — não na SOL. ts_transferido não serve como prova de handoff: está em 153 leads contra 57 reais.

Jornada — CAPTAÇÃO → QUALIFICAÇÃO → HANDOVER → FIM SOL

Visão canônica da SOL. OPS e OBSERVABILIDADE são camadas de suporte, não etapas da jornada. Continua pilar único SDR — as divisões abaixo são cadeia:*, não pilares. Elo marcado NÃO ANALISADO não foi provado.

Workflows · 27

Linha enxuta; a ficha completa abre abaixo, na seção de fichas.

Aposentados · 1

Arquivados no n8n em 14/08/2026 — fora da contagem, dentro da memória. Continuam exportados em Sol-estrategia/n8n/workflows/ e o arquivamento é reversível.

Fichas — 23 de 27 revisadas

Clique para abrir. Workflow ainda não revisado mostra só o que o n8n PROD sabe.

Funil real — medido no Supabase

Período 2026-07-01 a 2026-08-18. Toda linha vem de contagem sobre a base, não de estimativa.

Tempos

A mediana é a leitura honesta: a média é distorcida pelo lote de reparo manual de 17/07.

Meta — form e page reais, provados na Graph API

CONFLITO RESOLVIDO 17/08: houve divergencia sobre qual seria o form atual (1355008362677886 x 4509544755984242). A propria Meta decide, e ela carimba form_id e campaign_id em cada lead. Na ultima leitura boa (exec 872671, 16/08 00:15 UTC): 122/122 leads com form_id=1355008362677886 e 120/122 com campaign_id=120248170693270511 (os 2 sem campanha sao leads de teste da propria Meta). Ou seja, a campanha 120248170693270511 entrega NESTE form. O 4509544755984242 e o form ANTERIOR, de onde vieram os 42 leads do backlog de julho. Ressalva honesta: essa prova vale ate 16/08 00:15; depois disso a credencial OAuth caiu e nao ha como ver a Graph — se o formulario do anuncio tiver sido trocado depois, so saberemos ao reconectar. PROVADO por leitura da Graph API em 13/08/2026. O nome "Formulário com Lógica Condicional" é da CAMPANHA, não do formulário — foi essa a armadilha que levou à leitura errada anterior. Os 42 leads meta_ads que não estão neste form são o backlog do form anterior, injetado em 17/07 pelo poll hoje morto.

Correções aplicadas — 13/08/2026

Executadas com GO explícito, protocolo desativa → edita → valida → ativa, com golden provado antes de fechar. Todo o resto da auditoria segue sem correção.

Anomalias — 13

Cada uma foi comprovada por leitura direta do PROD nesta auditoria. Nenhuma foi corrigida.

Não mensurável hoje

O que a operação ainda não consegue responder, e o campo que falta para conseguir.

• Conversao resposta->qualificacao: os 12 leads validados a mao em 17/07 viraram QUALIFICADO sem passar pelo funil automatico, o que faz a taxa passar de 100%. Falta marcar a origem da qualificacao (automatica x manual).
• Conversao por formulario/campanha: nao existe coluna com form_id, campanha ou leadgen_id no lead. Impossivel segmentar sem backfill via Graph API.
• Tempo qualificacao->handoff: ts_handoff e ts_qualificado nunca coexistem nos leads de captacao. Amostra zero.
• Taxa de erro real do Ads Capture: a retencao de 85 minutos torna qualquer percentual de erro sem significado estatistico.
• Atribuicao de midia (gclid/utm): 0% preenchido — custo por lead por campanha nao e calculavel hoje.
• Entrega efetiva do template: template_entregue 100% NULL; so ha inferencia via tabela conversa.

Saúde do backend — o E2E deixou telemetria?

A operação funcionar não basta: ela precisa deixar rastro suficiente para administrar o produto. Auditoria do lead 612449 (execuções 890615 e 890617), campo a campo. Ausência de dado aparece como NÃO MENSURÁVEL, nunca como número bonito.

Cobertura de campos — lead

❌ Gaps reais (writer ausente)

• ts_primeira_resposta — respondeu=true mas o campo fica NULL: NENHUM writer o grava
• tempo_resposta_seg — idem
• template_msg_id — o endpoint do Krolik não devolve id de mensagem (NULL estrutural)
• client_id_sm — 0% na base inteira, nenhum writer
• whatsapp_valido — nenhum writer
• total_mensagens_ia = 0 apesar de 1 chamada real ao Claude

✅ NULL legítimo (não é falha)

• todos os meta_* (lead é Landing, não Meta) — 5 campos
• utm_*/gclid/fbclid (não há tagging no site)
• campos de OCR/consumo (cliente não enviou conta)
• ts_resposta_closer e afins (closer ainda não respondeu)

SLA

Custo de IA

Observado na execução (evidência efêmera, não persistida): Anthropic · claude-sonnet-4-6 · input 315 · cache-creation 3894 · cache-read 0 · output 349.
Gap: Para responder "quanto custou este lead" seria preciso persistir usage por conversa + tabela de preço por modelo. NÃO criado neste turno.

Dados que existem só no visual

• Nenhum. Todo número do placar e do funil sai de contagem sobre lead/conversa. Os KPIs de workflow saem da API do n8n.

Supabase — contrato de dados SOL

A · Tabelas

B · Campos de lead por responsabilidade

IDENTIDADE · 13 campos

CAPTAÇÃO · 15 campos

QUALIFICAÇÃO · 30 campos

HANDOVER · 9 campos

INTEGRAÇÕES · 9 campos

OPERAÇÃO / SLA · 11 campos

C · Os três canais da CAPTAÇÃO — leitura e ingestão

Mapeamento do que já existe. Onde leitura e ingestão vivem no mesmo workflow, está mostrado como está — nada foi separado por estética.

D · Contrato de saída — cobertura por canal

E · Funil derivado dos dados

F · Não mensurável hoje

• Evidencia da 1a abordagem no historico: template_entregue so passou a ser gravado em 18/08, entao 274 dos 275 leads tem NULL. Writer: sol.captacao.entrada-lead.
• IDs Meta no historico: meta_form_id/leadgen/campaign so existem em 11 leads (os capturados apos 17/08). Backfill possivel via Graph, ainda nao feito.
• canal_aquisicao do WhatsApp direto: 0/71 — nao existe referral na base. NULL legitimo, nao falha.
• template_msg_id: o endpoint chats/create-new do Krolik nao devolve id de mensagem. NULL estrutural.
• config: 35 colunas com a configuracao real da operacao e ZERO leitores. A configuracao efetiva esta hardcoded nos nos 00_CONFIG.

Supabase SOL — snapshot da auditoria

o que a auditoria provou

• COBERTURA META 100%: dos 112 leads reais do form 1355008362677886, 112 estao no Supabase. Os 2 ausentes sao leads de teste da propria Meta, filtrados por desenho.
• ZERO DUPLICATA em 277 leads — o gate atomico da RPC capture_lead funciona, e e a unica coisa segurando as 32.256 reinjecoes diarias.
• ts_transferido CORROMPIDO: 206 preenchidos, mas apenas 84 handoffs reais. 122 foram escritos pelo FUP como marcador de saida da regua, nao como handoff.
• etapa_funil MENTE: 23 dos 33 leads de site (google_site) estao marcados TRAFEGO PAGO. Campo write-only: 2 escritores, 0 leitores no n8n.
• canal_origem com 2 convencoes: os 206 do Fluxo 01 em minusculo, os 71 do inbound em MAIUSCULO.
• INCIDENTE 13/08 (auto-reportado): o PUT da API publica do n8n normaliza nos e quebrou o IF via webhook (typeValidation loose->strict), derrubando as duas lanes por ~2 minutos. Uma execucao do cron da planilha (861418, 23:35 UTC) falhou por isso. Corrigido e provado no ciclo seguinte (861443 success). Licao: o PUT da API publica NAO preserva nos — usar update parcial, ou reaplicar e conferir o diff.
• RASTREIO DE ORIGEM AUSENTE: campanha, form_id e leadgen_id chegam no payload e sao descartados. gclid 0%, utm_source 0%, fbclid 1/182. Nao existe chave lead->formulario.
• ENTREGA DO TEMPLATE NAO REGISTRADA: template_entregue, template_msg_id e whatsapp_valido sao 100% NULL nos 182 leads. Quem recebeu a 1a mensagem so se sabe por inferencia na tabela conversa.
• client_id_sm 0% preenchido; project_id_sm 40%. Colunas vivas parcialmente escritas.
• valor_conta 100% numerico (206/206) — o bug de valor cru de 17/07 nao deixou residuo.
• 49 leads com transferido_comercial=true SEM ts_handoff.

Prosa completa em Sol-estrategia/docs/AUDITORIA-SOL-13-08.md.

Agentes · 14

⚠️ Este bloco não vem do n8n — vem do censo de 08/08/2026 e é mantido à mão.