Branch feat/conversa-vira-lead, empilhada sobre feat/tres-papeis-do-agente (spec 16, PR #181). Worktree /Users/rafaelmelgaco/DeskcommCRM-tres-papeis. Spec: docs/specs/17-spec-conversa-vira-lead.md. Antecessor: HANDOFF-tres-papeis.md — as regras de trabalho ao final daquele arquivo continuam valendo aqui.

ingest.ts → markConversation → STOP (grava is_blocked) → audit → nascimento → dispatch.

• Depois do STOP: quem acabou de pedir para sair não vira oportunidade. A função relê o contato, então a ordem é o que garante isso.
• Antes do dispatch: o turno do agente resolve o lead ativo do contato. Criar depois faria o primeiro turno rodar sem lead — o buraco que esta peça existe para fechar.
• Grupo (@g.us) nem chega aqui: ingest.ts:374 já retorna antes.

pnpm test:db — 73 arquivos / 495 testes verdes (os 2 arquivos novos são +18 casos). pnpm typecheck e pnpm lint zerados (185 warnings pré-existentes, 0 erros).

S4 é o que responde "e se o adaptador mentir?": um filtro ignorado derruba 12 dos 18 casos, e 3 deles são do teste do próprio adaptador.

S5 é o controle da prova de tela: os 3 casos passam em ~2s cada, e verde rápido demais merece desconfiança. Com o nascimento desligado eles levam 22s, 30s e 22s — o tempo do timeout — e reprovam. O spec mede o card nascendo, não outra coisa que já estivesse na tela.

A primeira rodada de S1 chamou bash scripts/test-db.sh direto — vitest não estava no PATH, o script morreu com 127, e o grep sobre a saída devolveu vazio. Vazio e "nenhum teste reprovou" têm a mesma cara. Só apareceu porque o exit code foi conferido separado da contagem.

tests/e2e/conversa-vira-lead.spec.ts — 3/3 verdes. A mensagem entra por POST /api/v1/webhooks/waha/[token], a mesma rota que o WAHA chama, sem header de assinatura (que é como o WAHA Core real chega). Nenhum insert direto em crm_leads: insert à mão mente sobre a origem e provaria só que a tela desenha uma linha que alguém pôs no banco.

Evidência: evidence/spec-17/card-nascido-da-conversa.png. Registrada no CI (e2e.yml, parte 1) e no mapa de jornadas (J4.22–J4.25).

Ambiente: Supabase local (.env.e2e, 127.0.0.1:54321) + next build + next start. Sem .env.local nesta worktree — nenhum risco de escrever na produção.

O passo 2 não era o que a spec dizia, e as medições mudaram o trabalho três vezes.

O Postgres recusa atribuição a coluna GENERATED ALWAYS … STORED (428C9) e aborta a instrução inteira. Três instâncias, cada uma provada contra Postgres real com controle positivo:

O que entra de verdade é o gate: colunas-geradas-nao-sao-escritas.test.ts PERGUNTA ao Postgres quais colunas são geradas e varre app/, lib/, scripts/. O detector custou duas versões — a primeira acusou 11 falsos positivos (declaração de tipo, montagem de resposta HTTP), e gate que grita onde não há defeito é gate que alguém desliga.

Prova de tela: evidence/spec-17/contato-com-email-salvo.png (contato-salva-email.spec.ts, J4.26–J4.27).

"_data": { "key": {
    "remoteJid":    "70192801575156@lid",
    "remoteJidAlt": "558183647258@s.whatsapp.net",
    "addressingMode": "lid" } }

A resposta estava em webhook_events_log, não na documentação. Inbound 56/56 e outbound 20/20 trazem o número — e no outbound o remoteJid é o chat do destinatário, então o telefone é do cliente, não da loja (só o nome continua bloqueado ali, porque o pushName de fromMe é do operador).

Gravar o telefone, porém, quebrava o CRM. wa_identity é gerada com o telefone na frente do lid: preencher phone_number num contato nascido lid muda a identidade de lid:X para phone:+Y, o on conflict deixa de casar e nasce um contato duplicado — o defeito que a 0027 matou. Daí contacts.wa_lid: correlação do WhatsApp que não depende do telefone, com índice único e dedup auto-curativa ANTES da constraint.

E o canal de envio não muda. resolveWahaChatId preferia telefone; com o número gravado, toda conversa @lid viva passaria a sair por @c.us — que para contato em modo privacidade frequentemente não é endereçável. O sintoma seria pior que um erro: mensagem marcada como enviada e cliente sem resposta. O lid passou para a frente, e o mesmo raciocínio estava numa quarta instância (session-reconciler.ts), que reenvia o que ficou preso — divergir ali faria o redrive mandar para um endereço diferente do envio original.

fn_upsert_wa_contact ganhou o 7º parâmetro e mudou de regra: antes só mexia em display_name no conflito, com coalesce — nome ruim congelava para sempre e nada descoberto depois entrava. Agora completa o que falta e nunca sobrescreve, e reencontra por lid ou por telefone (é isso que impede o cliente já importado de virar um segundo contato ao escrever no WhatsApp).

• Contato 543134@lid é legado, não bug vivo. Nenhum código no HEAD produz a string; o produtor morreu no commit c890b403. São 3 linhas de resíduo — backfill, não conserto de emissor.
• O pushName não está na raiz do payload. A hipótese de que o WAHA mandava o nome num campo que o código ignorava era a "causa candidata nº 1" — e é falsa: o nome vem em _data.pushName, onde o código já olha, em 341 de 343 payloads.
• O regex ^Contato colide com Contato Anonimizado #…, que a rota LGPD grava de propósito. O backfill leva and is_anonymized = false — sem isso, ele reverteria anonimizações (regra L-04, exceção "Nenhuma"). Tem caso de teste próprio.

B1 reprovou mais que o previsto, e o motivo importa: eu tinha calculado que alguns casos "passariam por acidente" ao cair no INSERT. Não passam — o índice único uniq_contacts_org_wa_lid recusa o segundo INSERT com o mesmo lid, então a função estoura. O crédito era do índice, não do lookup; os dois trabalham.

B4 reprovou ZERO na primeira tentativa — e era o teste que estava errado. Ele executava uma CÓPIA do update escrita dentro do próprio arquivo, então sabotar o baseline.sql não o afetava: eu testava a réplica, não o artefato que o self-hoster aplica. Agora o comando é EXTRAÍDO do baseline em tempo de teste (com guarda que estoura se achar zero ou mais de um).

Corrigido isso, B4 ainda passava — e a segunda razão é outra: Contato Anonimizado #<hex> não casa com o regex ancorado em dígitos, ou seja, o regex sozinho já protegia e eu creditava a proteção à guarda. Foi preciso um caso que ISOLE a guarda (contato anonimizado com nome que CASA o regex) para que ela passe a ser vigiada de fato. Dois mecanismos redundantes, e o teste apontava para o errado.

pnpm test:db 75 arquivos / 511 testes · pnpm test:unit 285 / 2935 · pnpm test:unit 284 arquivos · typecheck e lint zerados. 19 casos novos entre telefone-do-lid.test.ts (banco) e telefone-alternativo-do-payload.test.ts (unit, com payloads TRANSCRITOS da produção — ninguém teria inventado o nome remoteJidAlt).

Eram seis cópias da cadeia display_name || name || phone_number || <literal>, com quatro finais diferentes — e duas delas (ficha do contato, tabela de contatos) nem usavam o telefone: quem tinha número e não tinha nome aparecia como "Sem nome" numa tela e com o número em outra.

lib/contacts/rotulo-do-contato.ts é a decisão única, com a regra que nenhuma das seis tinha: identificador técnico não é nome de gente. E o commit traz o gate junto — um caso varre app/, lib/ e components/ atrás da assinatura da cadeia, para que a sétima cópia reprove em vez de nascer com um quinto final.

Isso destravou um defeito do passo 1: o título do card vinha do PAYLOAD. Como o WAHA manda inbound sem pushName (2 de 271) e TODO ack assim, um cliente conhecido abria card "Novo contato pelo WhatsApp". Agora vem do cadastro, pela mesma função das telas — título e inbox não podem divergir.

E o comentário que estava naquela linha mentia: dizia que "o chamador garante" que o nome não é técnico, e o chamador passava o payload cru. Typecheck e testes verdes com a afirmação falsa versionada.

Duas decisões do Rafael, registradas na spec antes de codar: (a) o dado que o cliente diz vai para uma FILA, um humano confirma; (b) a base legal ficou a meu critério.

Escolhi aplicar, não inventar. A regra L-05 já nomeia as finalidades (marketing / transactional / profiling) e o campo consent.<finalidade>.granted_at, e sua exceção já cobre o transacional iniciado pelo próprio cliente. E o formato do jsonb também já existia: export-collector.ts:197 lê {escopo:{granted,granted_at,source}} — o leitor estava lá e o escritor nunca foi escrito.

Perda de consentimento não dá erro — é a base legal de um envio futuro sumindo em silêncio. E sem o valor anterior, um e-mail dito de brincadeira apaga o correto sem volta, que é o risco que a fila existe para conter.

O adaptador pg-como-supabase ganhou update e rpc — e ganhou porque ESTOUROU ao ser chamado, em vez de devolver vazio. Se tivesse devolvido vazio, os 7 casos novos ficariam verdes medindo nada.

O from/to não é medido contra Postgres, e isso está declarado: audit() cria o próprio client admin e o config de teste aponta para porta inalcançável de propósito. Descobri porque o controle positivo ("a tabela RECEBE a linha") reprovou junto com os outros — ele separou "o campo não está lá" de "a LINHA não está lá". A cobertura foi para um unit que espia a chamada.

A fila fecha o ciclo: a IA ouve e propõe, a pessoa vê o trecho da conversa e decide, o dado entra no cadastro com base legal (transactional, L-05) e auditoria dos dois lados (L-06), e o que ninguém decide vence — porque prazo que ninguém cobre é pior que prazo nenhum: promete um limite que não existe e a pendência vira badge permanente, que simula atenção e adia a decisão.

Prova de tela: evidence/spec-17/proposta-confirmada.png (confirmar-dado-do-contato.spec.ts, J4.28–J4.30).

O e2e passou pelo motivo errado na primeira versão, e só a evidência pegou: getByText(email) casava com o TRECHO da conversa (que contém o próprio e-mail), então ficava verde sem o dado ter chegado à ficha. Descobri olhando a imagem, que mostrava o campo EMAIL vazio enquanto o teste dizia verde.

O vencimento tem cron PRÓPRIO, e não carona no risk-watcher. A tentação era pendurar no que já varre organizações no mesmo tick — mas ele lista quem tem LEAD ABERTO, e uma organização pode ter proposta pendente sem nenhum negócio no funil. Nessas, a proposta nunca venceria, e "nada venceu" tem a mesma cara de "nada vencia ainda". O gate cron-routes-scheduled garante que a rota nasceu agendada: o comentário do risk-watcher conta o que aconteceu sem isso — uma rota com teste e doc que ninguém chamou, por meses.

O adaptador de teste cresceu por PRESSÃO, três vezes. update, rpc, lt/gt e insert().select().maybeSingle() só existem porque o naoImplementado ESTOUROU quando o código real os chamou. Se ele tivesse devolvido vazio, 7 casos de vencimento ficariam verdes medindo nada — "nenhuma proposta vencida" é o resultado natural de uma lista vazia.

Errei as duas primeiras para MENOS, e a razão é a mesma nas duas: cascateamento. Sem o filtro de prazo, tudo vence e a contagem do lote quebra junto; sem o carimbo, o CHECK decisao_datada recusa o UPDATE e NADA vence, derrubando todos os casos que dependem de algo ter vencido. Prever a contagem serve justamente para isso — cada divergência ensinou onde os mecanismos se apoiam.

O desenho saiu do mapeamento e copia a forma de crm_lead_reactivations, que já é uma fila de proposta com prazo, decisão datada, decisor e idempotência por índice parcial:

Também precisa entrar no cascade de fn_lgpd_cascade_redact_contact, no mesmo commit da criação.

Uma única organização com 4 funis e 5 agentes de negócios diferentes — um SDR de vendas, dois de suporte ao produto e uma atendente de clínica. Funis: Pedidos (padrão), Comercial - Andrea, Comercial - Julia, Suporte - IA. Qualquer um dos cinco alcançava qualquer um dos quatro.

E não só "mover card": crm_close_demand dá o negócio por ganho/perdido (tira do radar e das cobranças) e crm_manage_tags marca o card alheio. Um escopo que cobrisse só a movimentação protegeria o menos importante.

Ainda não aconteceu: a IA só tocou o funil padrão (4 registros) e nenhum negócio tem a IA como dono. Porta aberta que ninguém atravessou — a melhor hora para fechá-la, sem estado sujo para migrar.

Mapeando os caminhos, achei três furos piores que o escopo de funil (a687a97c, db0e70eb):

Anti-pattern 10 do CLAUDE.md: o MCP injeta service-role, que bypassa RLS, e os handlers não filtravam organization_id. Agravante na edição: o audit era gravado no log da vítima.

Ler o código não bastava — contar menções de organization_id devolve 5 para um handler que não o usava em filtro nenhum. Só medir comportamento com dois tenants resolveu.

E meu próprio teste mentiu verde, em duas camadas: .catch(() => null) transformava exceção em lista vazia, e eu lia r.data quando o campo é r.leads. "Não vazou" passava mesmo vazando.

Conserto obrigatório que veio junto: fn_ai_agent_version_content_immutable parava no campo followup e ignorava as nove colunas posteriores — todas editáveis numa versão PUBLICADA, sem virar versão nova e sem trilha. Acrescentar uma PERMISSÃO àquela lista sem consertar isso seria a própria ausência de escopo, com aparência de controle.

Medido: 6 de 36 etapas traduzidas, e três dos quatro funis com ZERO. Neles o assistente não sabe para onde mover, e a única forma de descobrir era entrar funil por funil na tela de configuração.

O passo 3 criou o lugar certo para essa cobrança. Funil MARCADO sem tradução é promessa que não se cumpre — o dono marcou achando que o assistente ia organizá-lo. A lacuna passa a aparecer ao lado da marcação, no momento da decisão. E só ali: funil fora do escopo com a mesma lacuna fica quieto, porque ninguém prometeu nada sobre ele.

Duas distinções que evitam alarme constante: mudo ≠ incompleto (com 3 de 5 ele percorre em parte; com 0 não move nada, nunca) e won/lost fora da conta (têm coluna própria — cobrá-las inflaria a lacuna com pendência que não existe, e uma barra que nunca chega a 100% se aprende a ignorar).

Os passos 3 e 4 deram limite e visibilidade. Nenhum responde o que muda quando o assistente erra — sem isso o produto tem caminho e não tem ciclo: a IA erra igual amanhã e alguém corrige de novo, para sempre e em silêncio.

Um humano mover um card que a IA moveu por último vira atividade própria (agent_move_corrected), com dois tipos que contam: devolução (voltou para onde estava — o sinal mais forte) e redirecionamento ("não era ali", que ignorar perderia metade do sinal).

Metade dos casos de teste existe para o risco OPOSTO: se o movimento anterior foi de outro humano, mexer no card é trabalho normal de equipe. Contar isso como "a IA errou" inflaria o número com ruído — e indicador que sobe sem causa se aprende a ignorar.

E o agregado responde "e daí?" (invariante 5): não "12 correções", mas "12 em Qualificando, 11 delas devoluções" — que diz que o assistente qualifica cedo demais, e o dono sabe o que ajustar.

tests/e2e/escopo-de-funil-do-agente.spec.ts, 2/2 verde, e na lista do workflow (e2e.yml linha 243) — prova nova fora do gate seria repetir o defeito que o spec do Operador registra.

A marcação nasce fechada e a tela explica em vez de deixar em branco: evidence/spec-17/escopo-nasce-fechado.png. Depois de marcar, salvar e recarregar, ela sobrevive — e o funil marcado sem tradução mostra a cobrança do passo 4 ao lado do nome: evidence/spec-17/escopo-sobrevive-ao-reload.png.

O que as duas falhas do CI eram, e o que elas ensinaram. Nenhuma era do produto:

1. getByRole("button", {name: /operação/i}) nunca resolve — o botão diz "Organiza o sistema". A tela fala a linguagem do dono do negócio; o rótulo não é o nome interno do papel.
2. O spec logava como manager, e só admin edita agente (readOnly em page.tsx). O sintoma era check() estourando num input que existe — lê como bug de UI e é permissão funcionando.

E três defeitos de infraestrutura de teste, consertados na classe:

Sabotagem. Removi pipeline_ids da cópia de leitura (page.tsx) e previ 1 reprovação no gate de colunas: medido 1 failed | 3 passed. Não medido: a sabotagem do caso 2 do e2e (remoção de TODAS as cópias, que só a tela pega) — o login com MFA não fecha a janela de 30 s com a máquina a load 27, e o gate de colunas cobre apenas a remoção parcial.

De brinde: o banco local estava desatualizado e o sintoma foi PGRST204 num seed. Reaplicar supabase/baseline.sql em banco existente rodou com 0 erros — que é o caminho update.sh do clone, provado sem querer.

O daemon do Docker parou de responder no meio da sessão. Sintomas medidos:

• o container efêmero do test:db sobe e cai imediatamente;
• docker version não retorna em 20s;
• o Postgres local aceita conexão TCP (porta 54322 aberta) mas não completa conexão;
• curl no Supabase local (54321) devolve HTTP 000.

Consequência: pnpm test:db e toda prova de tela ficaram indisponíveis a partir daí. O que continua medido: typecheck, lint e pnpm test:unit.

O que ficou pendente na época — e como fechou (2026-08-08, Docker de volta):

Na bateria de sabotagem da Fatia C escrevi um helper de shell com git checkout <arquivo> no fim e o chamei várias vezes. O checkout ficou escondido dentro da função e apagou uma alteração que eu tinha acabado de escrever e ainda não commitado. Já tenho memória sobre isto — reincidi porque a memória falava do comando, e o que me pegou foi o FORMATO (o comando dentro de um helper repetido).

O sinal foi a sabotagem seguinte falhar ao aplicar e os testes reprovarem com o código restaurado. Lidas só as contagens, as reprovações do T1 teriam sido registradas como prova — e vieram do trabalho apagado, não da sabotagem. A memória foi reescrita com esse detalhe.

Toda organização nasce com o funil "Pedidos", de e-commerce, com 8 etapas hardcoded — fn_seed_default_pipeline_for_org no baseline: Carrinho abandonado · Aguardando pagamento · Pago · Em separação · Enviado · Entregue · Pós-venda · Cancelado.

Como o funil de entrada é is_default, numa clínica ou imobiliária recém-instalada o lead nasce em "Carrinho abandonado". Antes do passo 1 isso era invisível (nenhum lead nascia sozinho); agora é a primeira coisa que o dono vê no kanban.

Não foi mexido aqui: mudar o seed altera o comportamento de todo clone e é decisão de produto, não consequência deste passo. É insumo direto do passo 4 (a superfície precisa mostrar onde os contatos entram e permitir trocar) e candidato a item próprio: um funil neutro de entrada, ou o onboarding perguntando o nicho.