Merge remote-tracking branch 'origin/main' into tri-w538

Author: melgarafael

.changes/a-chave-da-openrouter-passa-a-ser-conferida-de-verdade.md

@@ -0,0 +1,34 @@
+---
+impacto: nada_mudou
+secao: corrigido
+titulo: A chave da OpenRouter passa a ser conferida de verdade antes de a tela dizer que está validada
+---
+
+Ao cadastrar uma chave da OpenRouter em **Agente de IA › Credenciais**, o sistema conferia
+a chave contra o catálogo de modelos do provedor — um endereço que responde a
+qualquer um, com chave errada ou sem chave nenhuma. Na prática, qualquer texto
+colado ali era gravado como credencial validada, e o cartão passava a mostrar
+"Validada" com o final da chave ao lado.
+
+O erro só aparecia depois, na primeira mensagem que o agente tentava responder,
+e aparecia como "User not found." — um texto que não fala em chave nem em
+credencial. Quem procurava a causa olhava o modelo, o provedor, o próprio
+atendimento; a tela, enquanto isso, afirmava que a peça quebrada estava boa.
+
+Agora a prova é feita contra o endereço que exige a credencial. O catálogo
+continua sendo lido em seguida, porque é dele que sai a lista de modelos que a
+tela mostra — ali ele é dado, não prova. E catálogo fora do ar não recusa mais
+uma chave que já provou ser válida: seria trocar um erro de credencial por um de
+indisponibilidade, e mandar quem opera caçar defeito na chave certa.
+
+Uma ressalva sobre em que versão isto entrou: a correção já está no ar desde a
+**1.13.0**. O que chega atrasado é esta nota — a mudança foi publicada sem ela,
+e por isso não apareceu na lista daquela versão.
+
+Chave boa continua sendo aceita do mesmo jeito, e não há passo de atualização.
+A única coisa que vale conferir é o que foi cadastrado antes: se a sua chave da
+OpenRouter é anterior à 1.13.0 e o atendimento falha sem motivo aparente, abra
+**Agente de IA › Credenciais** e use o botão de revalidar — as setas em círculo, no
+cartão da credencial. A resposta que ele dá agora é real.
+
+Isto veio da contribuição de **@Elevstudio-Dev**.

.changes/a-troca-de-senha-pela-linha-de-comando-acha-o-usuario.md

@@ -0,0 +1,26 @@
+---
+impacto: nada_mudou
+secao: corrigido
+titulo: A troca de senha pela linha de comando volta a encontrar o usuário
+---
+
+Quem perde o acesso a uma instalação sem SMTP — o estado normal de um self-host
+recém-instalado — só tem um caminho de volta: o `reset-password.sh` do kit. Ele
+não funcionava para **ninguém**. Não era intermitente nem dependia do e-mail:
+qualquer endereço, existente ou não, recebia a mesma resposta seca de "usuário
+não encontrado", e a pessoa ficava trancada do lado de fora do próprio sistema.
+
+A causa era uma consulta escrita na sintaxe errada. O script pedia ao servidor de
+autenticação um filtro no formato do banco (`email.eq.<endereço>`), e esse
+servidor não fala esse formato — ele usa a expressão inteira como texto de busca.
+Como nenhum e-mail contém o pedaço `email.eq.`, a busca não achava nada, sempre.
+
+Agora a consulta vai no formato que o servidor entende. E, como a busca dele é por
+trecho do endereço, o script passou a exigir o e-mail **inteiro** antes de aceitar
+o resultado: pedir `ana@empresa.com` também traz `mariana@empresa.com`, e entregar
+a pessoa errada a um comando que TROCA SENHA seria pior que não achar ninguém. Na
+dúvida ele não devolve nada — quem chama vê "não encontrado", que é ruim mas se
+resolve; a senha de outra pessoa trocada, não.
+
+Quem opera uma VPS não precisa fazer nada além de atualizar. Nenhuma configuração
+muda, nenhum arquivo precisa ser editado à mão.

.changes/anonimizar-um-contato-retoma-de-onde-parou.md

@@ -0,0 +1,27 @@
+---
+impacto: nada_mudou
+secao: corrigido
+titulo: Anonimizar um contato retoma de onde parou, em vez de dizer que já foi
+---
+
+A anonimização de um contato remove os dados pessoais em três lugares: o
+cadastro do contato, os títulos dos negócios dele e o histórico de atividades.
+Se a operação era interrompida no meio — o navegador desistindo, o servidor
+reiniciando —, o primeiro lugar ficava pronto e os outros dois não.
+
+E não havia como terminar: clicar em "Anonimizar" de novo respondia **"já anonimizado"**
+e não fazia mais nada. O contato ficava para sempre com nome de
+cliente visível dentro dos negócios e do histórico — que é exatamente o dado que
+a anonimização existe para remover, e que a lei dá prazo para remover.
+
+Pior: nesse estado a tela **não mostra botão nenhum** — assim que o contato
+consta como anonimizado, o botão dá lugar a um aviso. Não havia como pedir a
+retomada nem sabendo que ela era necessária.
+
+Agora a verificação diária do sistema encontra sozinha as anonimizações que
+ficaram pela metade e termina o serviço, sem ninguém precisar procurar contato
+por contato. Como a lei dá prazo, esse conserto não podia depender de alguém
+lembrar de clicar. Rodar de novo num contato já inteiro não escreve nada, e o
+registro de auditoria mostra o que foi realmente feito, em qual contato e em que
+dia — separado da execução original, para a data em que o titular exerceu o
+direito não ser sobrescrita.

.changes/elegibilidade-da-ia-por-origem-do-lead.md

@@ -0,0 +1,34 @@
+---
+impacto: capacidade_nova
+secao: adicionado
+titulo: A IA pode ser limitada a atender só leads de origem conhecida
+---
+
+Num número de WhatsApp que também é usado para falar com clientes, fornecedores
+e contatos pessoais, a IA respondia todo mundo assim que um agente era
+publicado. Agora dá para ligar, por canal, o modo "só atende quem eu autorizei":
+a IA fica em silêncio por padrão e só assume a conversa quando o lead veio de
+uma origem elegível — uma submissão nova de formulário, uma campanha
+identificada, ou uma liberação manual pela tela. Histórico antigo, existência do
+contato, conversa anterior ou reinício de um worker nunca autorizam sozinhos.
+
+Esse limite vale para TODOS os caminhos de resposta automática — o motor do
+agente, o follow-up, o texto fixo de fluxo, o worker de resposta legado e a
+passagem para humano por sentimento. Não há atalho: nenhum deles envia mensagem
+de IA para uma conversa não autorizada.
+
+Além disso, e independentemente desse modo: quando você responde um cliente à
+mão pelo próprio WhatsApp (celular, ou outra plataforma na mesma conta), a IA
+para naquela conversa para não responder junto.
+**Essa pausa dura uma hora, e se renova a cada mensagem sua.**
+Enquanto você estiver atendendo, a IA continua calada; quando você para, a hora
+corre e ela volta a atender aquela conversa sozinha. Você não precisa lembrar de
+religar nada.
+
+Se quiser a IA de volta antes da hora, é o botão "devolver ao automático" na
+conversa. E se quiser que ela fique parada por tempo indeterminado, é o mesmo de
+sempre: assumir a conversa pela tela — aí ela só volta quando você devolver.
+Nenhuma dessas coisas apaga a origem do lead.
+
+Quem não ligar o modo "só atende quem eu autorizei" mantém o comportamento de
+antes para todo o resto.

.changes/o-aquecimento-aceita-a-data-de-hoje.md

@@ -0,0 +1,24 @@
+---
+impacto: nada_mudou
+secao: corrigido
+titulo: A proteção de envio volta a aceitar a data de hoje
+---
+
+Em **Conexões › Proteção de envio**, informar hoje em "este número é usado
+desde" era recusado durante a manhã inteira: até as 9h no relógio de quem
+opera no Brasil, salvar devolvia *"Campos inválidos."* e não gravava nada — nem
+a janela de horário, nem o intervalo entre envios, nem o teto diário que você
+tinha acabado de mudar na mesma tela.
+
+O motivo: o campo pergunta um DIA, mas a verificação o comparava com a hora
+exata em Londres. Um dia não tem hora — ele começa em horários diferentes em
+cada parte do mundo —, e por isso "hoje" só era aceito depois do meio-dia
+londrino. Agora a verificação compara dias com dias, e só recusa a data que
+ainda não chegou em canto nenhum do planeta.
+
+O calendário do campo também parou de oferecer o dia errado: depois das 21h ele
+mostrava amanhã como escolha possível.
+
+Data futura continua recusada, e data antiga continua sendo o caso normal — é
+informando a data antiga que um número usado há meses deixa de ser tratado como
+recém-criado e sai do teto de 20 envios por dia.

.changes/o-rascunho-superado-para-de-ser-regravado.md

@@ -0,0 +1,43 @@
+---
+impacto: nada_mudou
+secao: corrigido
+titulo: Salvar o rascunho de um agente para de escrever por cima de um rascunho antigo
+---
+
+Na tela de um agente, "Salvar rascunho" podia gravar numa versão **diferente**
+da que estava aberta na tela — e apagar, no caminho, um rascunho antigo que a
+própria tela prometia estar guardado.
+
+O estado que produzia isso é comum e tem um gatilho conhecido: quem tinha
+trabalho em andamento num rascunho e usou o botão **Reverter**, na aba
+Histórico. Reverter cria uma versão nova e a publica na hora; o rascunho que
+existia fica, a partir dali, "atrás" da versão publicada. A tela sabe disso e
+avisa, no selo ao lado do nome do agente: *"o rascunho v5 é anterior a esta
+versão e foi superado por ela — ele continua no Histórico."*
+
+Só que o servidor não sabia. Ele procurava "o rascunho de maior número" e
+gravava ali. Duas consequências, nenhuma delas com mensagem de erro:
+
+- **O trabalho parecia sumir.** O aviso verde dizia "Rascunho v5 salvo.", a
+  página recarregava, e a tela voltava a mostrar o texto anterior — porque ela
+  não reabre um rascunho superado, e o botão de publicar também não o oferece.
+  Quem estava editando via "salvo" e nada mudando, sem ter o que fazer a
+  respeito.
+- **O Histórico perdia conteúdo, em silêncio.** Aquele rascunho v5 é um
+  retrato: a linha dele no Histórico existe para mostrar o que estava escrito
+  ali. Regravá-lo trocava esse conteúdo por um texto que ninguém rascunhou
+  naquele momento, sem aviso e sem volta.
+
+Agora o servidor decide em qual versão escrever pela **mesma regra** que a tela
+usa para decidir qual versão abrir. Quando o rascunho existente está superado,
+a gravação nasce numa versão nova — que é a que a tela reabre e o botão publica
+— e o rascunho antigo fica intacto no Histórico, como estava prometido.
+
+Junto vem um cuidado que não aparece na tela mas decide o resultado: quem é a
+versão publicada passa a ser sempre o **ponteiro que o atendimento executa**, e
+não o rótulo "publicada" gravado na linha da versão. Os dois já se contradizem
+em instalações reais, e a resposta otimista era a errada.
+
+Para quem opera uma instalação, nada muda no dia a dia: nenhuma configuração
+nova, nenhum passo de atualização, nenhuma mudança no banco. O que muda é que
+"salvei" volta a significar "está salvo onde você está vendo".

.changes/os-emails-de-acesso-deixam-de-apontar-para-localhost.md

@@ -0,0 +1,32 @@
+---
+impacto: nada_mudou
+secao: corrigido
+titulo: Os e-mails de acesso deixam de apontar para um endereço que não existe
+---
+
+Numa instalação feita pelo caminho documentado, os e-mails de recuperação de
+senha, de confirmação de cadastro e de aceite de convite chegavam com um link
+para `localhost:3000` — um endereço que só existe na máquina de quem programa.
+O e-mail chegava, a pessoa clicava, e o navegador dizia que a página não existe.
+Na prática, **ninguém conseguia redefinir a própria senha.**
+
+O endereço certo mora no painel do Supabase, e o instalador já sabia configurá-lo
+sozinho — só que precisava de um token que ele nunca pedia. O aviso existia, mas
+saía no meio de um registro de dez minutos, logo antes de uma tela verde dizendo
+"Instalação concluída". Ninguém voltava para ler.
+
+Agora o instalador pergunta esse token. Ele é opcional e **não fica salvo** —
+abre a conta inteira do Supabase, então é usado uma vez e descartado, e nem
+sequer entra no rascunho que guarda suas respostas para o caso de a instalação
+ser interrompida. Por isso, se você recomeçar uma instalação, ele é a única
+pergunta que volta a ser feita; a tela diz isso na hora, e apertar Enter pula.
+
+Quem preferir pular continua podendo: a instalação termina repetindo o passo que
+falta, com o seu domínio já preenchido, em vez de deixar a descoberta para o dia
+em que alguém esquecer a senha. E quando o passo automático roda mas o endereço
+não fica como este sistema precisa — porque o seu projeto já tinha outro
+endereço escolhido, por exemplo —, ele passou a dizer isso em vez de terminar
+com um "pronto" verde.
+
+**Se você já tinha instalado antes desta versão**, a próxima atualização mostra
+esse mesmo passo uma vez, com o seu domínio preenchido, e não repete depois.

.env.example

@@ -152,6 +152,15 @@ AI_BUDGET_ENFORCEMENT=on
 EVENT_LOG_DRAIN_INTERVAL_MS=2000
 EVENT_LOG_DRAIN_IDLE_INTERVAL_MS=10000
 EVENT_LOG_DRAIN_BATCH_SIZE=50
+
+# --- Elegibilidade da IA por origem do lead ----------------------------------
+# Vale SÓ nos canais em que você ligou o modo "só atende quem eu autorizei"
+# (Configurações do canal › ai_gate = allowlist). Nesses canais, um contato fica
+# elegível para a IA quando vem de uma origem conhecida (formulário do Respondi,
+# campanha, liberação manual). Este número é por quantos DIAS essa autorização
+# vale — depois disso, uma submissão antiga não reativa a IA sozinha. Uma
+# conversa que segue viva renova o prazo a cada turno. Vazio = 21 dias.
+AI_ALLOWLIST_TTL_DAYS=21
 # Stub do endpoint de teste do agente: 'true' devolve trace fabricado em vez de
 # executar o agente. Deixe false — o runtime real já existe. Só ligue para
 # exercitar o render da UI sem gastar token.

.github/workflows/e2e.yml

@@ -179,6 +179,8 @@ jobs:
         agenda-tela-do-produto.spec.ts
         notificacoes-diz-o-que-falta.spec.ts
         relogio-http-cron-externo.spec.ts
+        j20-elegibilidade-respondi.spec.ts j20-elegibilidade-followup.spec.ts
+        j20-elegibilidade-atendimento-manual.spec.ts
       # ⚠️ A ORDEM DESTA LISTA NÃO DECIDE A ORDEM DE EXECUÇÃO. O Playwright
       # ordena os arquivos por CAMINHO, não pela ordem em que são passados na
       # linha de comando. Medido no run 31838253496: `marca-logo.spec.ts` estava