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

derivado do backend em 21/08

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

retrato de 18/08 — 6 dias

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.

HANDOVER ENTREGA FECHADA

derivado do backend em 21/08

Qualificou → closer → SolarMarket → Krolik → whisper/resumo → gestão → transferência do chat → ts_handoff

Fora do escopo do handover

sol.comercial.resposta-closer mede o que acontece DEPOIS que o comercial recebeu. É observabilidade comercial, frente futura — não faz parte da DoD do handover da SOL.

Os três campos existem e são escritos, mas a auditoria de schema mostrou que ninguém os lê. Hoje não sabemos medir se o closer respondeu.

FUP & FAST FORWARD IMPLEMENTADO · AGUARDANDO E2E REAL

A regra nasceu de um princípio: Fast Forward nunca dispara só porque o score ou o valor são altos. Exige que a SOL tenha perguntado o prazo, que o cliente não tenha respondido e que o primeiro áudio tenha sido entregue — áudio gerado não conta.

Régua V1

O que mudou

Estado das provas

As duas pendências dependem de operação real: um lead precisa percorrer prazo → silêncio → áudio → silêncio → Fast Forward. Não vamos fabricar esse lead.

Números

total_audios em 0 com 40 áudios entregues é esperado: o campo não tinha escritor até 21/08. O contador começa do próximo áudio em diante — o histórico não foi retroagido, porque não havia como saber quais entregas foram de qual lead sem inferir.

Fim SOL — quando a SOL para

derivado do backend em 21/08

A SOL termina em exatamente dois caminhos. QUALIFICADO sozinho não é um deles: se não entregou ao closer, existe uma anomalia intermediária, não um desfecho.

Onde estão os 285 leads

91 + 35 + 19 + 140 = 285. Conjuntos mutuamente exclusivos, zero sobreposição — conferido em query.

Não é Fim SOL

• QUALIFICADO sem handover concluído
• SOL SDR ainda qualificando
• TRÁFEGO PAGO
• FUP em andamento
• Fast Forward elegível mas não executado
• erro técnico
• template enviado
• cliente silencioso antes dos gates finais

QUALIFICADO SEM HANDOVER — 19 leads anomalia histórica

Janela: 16/07 a 05/08/2026. Assinatura idêntica nos 19: closer_id nulo em 19/19 · ts_handoff nulo em 19/19 · ts_transferido nulo em 19/19 · mas ts_qualificado e projeto SM presentes em 19/19

É o GAP-05, já documentado no próprio código: até 08/08 o fluxo PAI marcava status=QUALIFICADO ANTES do handoff assíncrono. Se o filho falhava, o lead ficava meio-qualificado. O comentário no [SOL] SDR Engine registra exatamente "GAP-05, 19 casos".

FIX-04, aplicado em 08/08: quem marca QUALIFICADO passou a ser o FILHO, junto de closer_id e transferido_comercial. Último caso em 05/08 11:52 — três dias ANTES do fix. Zero casos novos desde então.

NÃO saneado nesta rodada. A auditoria detalhada fica para o bloco ANOMALIAS.

Desqualificados — 35

antes de 13/08: 28 · 13/08 em diante: 5 · sem ts_desqualificado: 2 · com ts_desqualificado: 33 · via esteira [SOL] Desqualificar: 11

11 passaram pela esteira [SOL] Desqualificar com handoff_tipo registrado; 24 não têm origem persistida e são anteriores à revisão. Nenhum foi desqualificado por silêncio — a régua nunca chamou desqualificação até a regra de 72h, que ainda não entrou em produção. Motivo não foi inferido onde o dado não existe.

Fast Forward IMPLEMENTADO + GOLDENS ✅ · E2E REAL ⏳

Fast Forward NÃO cria um terceiro Fim SOL. É outro caminho para o mesmo desfecho: FF → QUALIFICAR → HANDOVER → Fim SOL por sucesso. Zero ocorrências reais até agora.

Depois do Fim SOL

Primeira mensagem do closer, proposta, venda e fechamento são DOWNSTREAM. Não fazem parte do critério de término da SOL. A responsabilidade da SOL acaba na entrega.

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

derivado do backend em 24/08

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 · 26

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 — 25 de 26 revisadas

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

Funil — medido no Supabase

derivado do backend em 21/08

CAPTAÇÃO → SOL SDR → QUALIFICAÇÃO → HANDOVER. Cada linha é uma contagem direta, sem inferência. Onde o número engana, a ressalva vem junto.

Ressalvas — números que enganam se lidos sozinhos

Taxa de conversão comercial (proposta, fechamento, receita) não está neste banco. A SOL entrega ao closer e o funil dela termina aí.

Tempos

derivado do backend em 21/08

Duas séries de handover, medindo eventos diferentes. A página mostra as duas separadas de propósito — juntá-las numa média só produziria um número sem evento correspondente.

As duas séries NÃO formam uma média única. Uma marca a transferência do chat; a outra, o fim de todo o handover. Somá-las produziria um número que não corresponde a nenhum evento real.

Resposta da SOL ao lead SÉRIE NOVA

ts_primeira_resposta em 13 leads · tempo_resposta_seg em 5. Os escritores nasceram em 19/08. Amostra pequena por ser recente, não por falha. tempo_resposta_seg fica NULL de propósito no WhatsApp direto: quem abriu a conversa foi o cliente, não existe abordagem anterior para medir.

SLA comercial NÃO VALIDADO

73 de 91 leads entregues têm ts_resposta_closer · tempo_resposta_closer_seg · closer_respondeu_krolik_id preenchidos.

Os campos NÃO estão vazios — 73 dos 91 leads entregues têm os três preenchidos por sol.comercial.resposta-closer. Mas esse workflow nunca passou pelo ciclo de revisão, e o detector depende de distinguir origem de mensagem e de tratar fuso do Krolik (dhMessage vem em BRT sem offset — armadilha que já nos pegou). Enquanto não for auditado, o número existe mas não vira KPI.

Não publicado por falta de escritor ou evidência:

• tempo até proposta
• tempo até venda
• tempo até fechamento
• SLA por closer

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.

Anomalias — estado de hoje

derivado do backend em 21/08

Nem tudo que é estranho é bug. Cada achado cai em uma categoria — sem isso a página volta a contar como problema atual o que já morreu.

O número antigo (13 anomalias, "nenhuma foi corrigida") era de 13/08 e a maioria já morreu. Este bloco recalcula o presente.

Não mensurável hoje

derivado do backend em 24/08

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

• Primeira resposta do closer: sol.comercial.resposta-closer preenche ts_resposta_closer, tempo_resposta_closer_seg e closer_respondeu_krolik_id em 73 dos 91 entregues — mas o detector nunca passou pelo ciclo de revisão. O número existe e não é confiável.
• Toques de FUP por tipo no dia (áudio x texto x template): a tabela lead guarda contadores acumulados, não o tipo de cada toque. Só derivável de conversa, que o briefing ainda não lê.
• Conversão comercial (proposta, fechamento, receita): não está neste banco. A SOL entrega ao closer e o funil dela termina aí.
• Custo de IA por etapa do funil: o ledger uso_ia grava etapa, mas só a partir de 19/08. Antes disso não há série.
• Origem da qualificação (automática x manual): não existe campo que distinga. Os leads validados à mão em 17/07 entram nas mesmas contagens dos automáticos.
• Uso em front ou BI: não há front conectado a este Supabase nesta árvore. Nenhum campo foi declarado "usado no front" na auditoria de schema.

Saúde do backend — o E2E deixou telemetria?

retrato de 19/08 — 5 dias

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

retrato de 19/08 — 5 dias

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 — estado do schema

derivado do backend em 21/08

Project hsnglsjmiefgxghljgsz · PostgreSQL 17.6 · 6 tabelas · 185 colunas, todas classificadas com evidência.

SUPABASE GLOBAL — 100% MAPEADO SUPABASE CAPTAÇÃO + QUALIFICAÇÃO — 100% VALIDADO

Classificação das 185 colunas

Estados conhecidos — não são dúvidas

Nenhuma coluna foi removida e nenhuma precisa ser agora. Campo sem uso hoje não é lixo — é estado conhecido e nomeado.

Evidência coluna a coluna em Sol-estrategia/docs/evidencias/auditoria-schema-sol.json.

Agentes · 14

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