Versión 1.82.0v1.82.0

Cada conexão de banco de dados externo passa a ter uma lista de fontes liberadas: o assistente e a grade só enxergam as tabelas e views que um administrador marcar, com a descrição que ele escrever, e só as colunas que ele liberar. Conexões que já existem continuam como estão: o assistente segue lendo tudo que o usuário do banco enxerga, até alguém marcar. Conexões novas começam com nada liberado, e o assistente avisa "nenhuma tabela foi liberada" até um administrador escolher; quem cria conexão por API marca as fontes em seguida, com PUT /api/v1/external-db/connections/:id/sources. Crédito: @paulolimajr77.

Em Dados externos, cada conexão ganha o painel "O que o assistente pode ver": o administrador marca as tabelas e views (e as colunas) que o assistente e a grade podem ler, escreve uma descrição curta para cada uma e vê quantas estão liberadas. Quem não é administrador só consulta a lista. Conexões novas passam direto a esse painel, porque nascem sem nada liberado. Crédito: @paulolimajr77.

Em Provedores de IA e no seletor do agente passam a aparecer o Claude Haiku 5.5, o Claude Sonnet 5.5 e o Claude Opus 5.5, com o custo contado em Uso e orçamento. Também deixa de falhar, com o Claude Opus 5, o que manda ajuste de temperatura, que esse modelo recusa: o medidor de clima da conversa (que falhava calado) e as organizações que configuraram temperatura. O modelo padrão não muda. Quem usa a Anthropic e não escolheu modelo para "Identificar a etapa do lead" e "Barrar tentativa de manipulação" passa a usar, nesses dois, o Claude Haiku 5.5 no lugar do Haiku 4.5, porque o sistema escolhe sozinho o modelo mais barato do provedor: custa menos, mas pode deixar a resposta ao cliente um pouco mais lenta (medido pelo @jmpo em 60 turnos reais de atendimento, a verificação que identifica a etapa do lead passou de 0,6 s para 0,9 s, na mediana); para manter o de antes, escolha o Haiku 4.5 nesses dois pontos em Provedores de IA. Crédito: @rafaelcesardev.

Com a cobrança ligada, o card Cobrança da empresa (painel › Tenants › empresa) ganhou o botão Gerar link de pagamento. É para o cliente que não vai entrar no sistema para assinar: você gera o link por ele e manda pelo WhatsApp com Copiar link de pagamento.

No Asaas, digite antes o CPF ou CNPJ de quem paga (o campo já vem com o CNPJ do cadastro quando ele confere). O documento vai direto ao Asaas e não fica guardado no sistema. O cliente no provedor é criado com o e-mail do administrador mais antigo da empresa, nunca com o seu. Por isso, na primeira vez, a empresa precisa ter um administrador que não seja você: na que você acabou de criar para outra pessoa, gere o link depois que ela aceitar o convite; na que tem só você como administrador, convide um administrador da empresa antes. Depois que o cliente existe no provedor, isso não é mais pedido.

Clicar de novo devolve o mesmo link enquanto ele vale. No Asaas, depois do aviso do provedor, a empresa vê o mesmo link em Configurações › Plano e cobrança › Pagar agora; na Stripe, o Assinar dela abre a mesma sessão. Na Stripe, o link vale 24 horas, e quem paga volta para a tela de login do sistema: o pagamento é confirmado pelo aviso do provedor, não por essa volta.

Você não precisa fazer nada.

Numa VPS ARM64, o kit confere antes da instalação ou atualização se as imagens do CRM, a WAHA escolhida e, no modo single-server, o Supabase fixado têm variante ARM64. Isso evita começar uma atualização que não poderá subir. Há também uma sonda somente-leitura para a primeira transição de kit antigo. Em AMD64 nada muda. Uma instalação existente continua exigindo atualização deliberada e backup, e quem pede construção local (DESKCOMM_BUILD_LOCAL=1) não passa por esta conferência.

Crédito: @Tanderakkkj.

Quando o agendador das janelas de manutenção não consegue pausar ou retomar uma conexão no horário marcado, a Central passa a mostrar um aviso, um só por organização e não um por conexão. A próxima batida que funcionar fecha esse aviso sozinha. O detalhe técnico da falha fica no log do agendador. Uma janela que ainda não começou pode ter os dois horários corrigidos pela API, sem cancelar e criar de novo; a janela em andamento ou encerrada não muda, e a edição fica registrada na auditoria. As telas da janela de manutenção ganham a tradução em chinês. Nenhuma configuração nova, nenhum passo manual.

Contribuição de @webtecnica (#2845), a partir da issue #2388.

Vale para quem já configurou funil de destino nas intenções do roteador, sem precisar fazer nada: na primeira atualização, o roteador deixa de transferir o card entre dois funis de produto e passa a abrir um segundo card. Antes, o cliente com negócio aberto em Consórcio que passava a falar de Investimentos tinha o card de Consórcio copiado e encerrado. Agora ele ganha um segundo card em Investimentos, e o de Consórcio continua como está: nada é encerrado e nada conta como perda. Funil de produto é o funil de destino de alguma intenção do mesmo roteador.

O cliente que já fechou um produto e fala de outro também ganha o card do novo. Quem já passou pelo funil de destino (ganhou ou perdeu lá) não ganha outro card ali, e o contato bloqueado (que pediu para parar) ou anonimizado não ganha card novo nenhum.

O card na Recepção, ou em qualquer funil que não é destino do roteador, continua sendo transferido para o funil do produto, como antes. O card novo leva só o título, o contato e a origem; etiquetas, campos, valor e responsável do outro produto não são copiados. Intenção sem funil de destino se comporta exatamente como antes.

Contribuição de @webtecnica (#2799), a partir do desenho e do patch de @InvestidorDiversificado na issue #2480.

Ao encerrar um acompanhamento de suporte, a aba vizinha recarregava duas vezes: a recarga disparada pelo aviso entre abas abria um documento que, sem carimbo próprio, caía na comparação de relógio e recarregava de novo — uma diferença de menos de um milissegundo entre o início do documento e o carimbo não dá para separar com Date.now(). Agora a aba marca, em sessionStorage, qual aviso ela já tratou, e o documento seguinte nasce sabendo que a recarga já aconteceu. Quem encerra o acompanhamento continua sem recarregar a própria aba, e um acompanhamento encerrado mais tarde ainda recarrega a vizinha uma vez.

Ao conectar uma assinatura do ChatGPT, o CRM passa a consultar o catálogo pelo endpoint oficial do Sign in with ChatGPT usando o token daquela conta. A lista segue mostrando apenas os modelos liberados para exibição; erros HTTP continuam visíveis e não apagam a lista já salva. O painel de Provedores reconhece os modelos dessa lista ao salvar os pontos e o modelo padrão, e a Prospecção pode selecioná-los quando oferecem ferramentas do CRM. Não é necessário configurar CODEX_CLIENT_VERSION.

Contribuição de @omayklourenco.

Na instalação em servidor único (o Supabase na mesma VPS do CRM), a conferência da chave do Supabase falava com o domínio público — que só passa a responder depois que o proxy da instalação sobe. Com o domínio atrás de proxy (Cloudflare no modo laranja, o padrão do kit), essa conferência recebia 521 e a instalação parava pedindo para conferir uma chave que estava certa. A conferência passa a falar com o Supabase da própria VPS, como a validação do endereço já fazia nesse modo; fora do servidor único, nada muda.

Você não precisa fazer nada.

Contribuição de @webtecnica (#2933).

Antes de cada resposta, o agente classifica o estágio da conversa e confere se a mensagem tenta manipulá-lo. Essas duas verificações usam o modelo mais barato do provedor, e os mais novos raciocinam antes de responder até quando a resposta é uma palavra só. Na OpenAI, desde que o GPT-6 Luna virou o modelo econômico, isso somava perto de 1 segundo a cada resposta, e até 2 segundos nas mais lentas. Agora as duas verificações pedem ao modelo que não raciocine: medido em 60 conversas reais, a espera delas caiu de 1,7 s para 0,9 s (de 3,5 s para 1,3 s nas mais lentas). O mesmo vale para o Claude Haiku 5.5 quando ele entrar no catálogo: de 2,0 s para 0,9 s. Também custam menos, porque deixam de pagar o raciocínio. Quem ajustou o esforço de raciocínio da OpenAI no servidor (OPENAI_REASONING_EFFORT) continua com o ajuste nas demais chamadas. Nada a fazer na VPS.

Contribuição de @jmpo.

Ao gravar a credencial do Google Agenda ou do app da Meta pela tela de administração, uma leitura que já estava em andamento podia trazer de volta o valor anterior e mantê-lo por até 30 segundos: o aviso de salvo aparecia, mas a Agenda não conectava ou a entrega da Meta falhava nesse intervalo. A leitura em andamento agora não reinstala o valor antigo. Contribuição de @webtecnica (#2905).

Quem escrevia {{primeiro_nome}} à mão no campo de resposta de um contato com nome mandava o texto cru para o cliente: sem aviso e com o botão Enviar liberado. Só a resposta rápida trocava a variável pelo nome. Agora o texto digitado passa pela mesma troca no envio, com o nome da conversa para onde a mensagem vai. Variável desconhecida, como {{codigo}}, continua como foi escrita. A nota interna também continua como foi escrita, porque não vai ao cliente. Contato sem nome segue barrado pelo aviso de antes. Nenhuma configuração nova, nenhum passo manual.

Contribuição de @webtecnica (#2920), a partir da issue #2891.

Com modelos que pensam antes de responder (o raciocínio estendido da Anthropic), o fechamento do turno reenviava o raciocínio assinado numa chamada sem ferramentas, e a API recusa essa chamada, segundo o relato de quem contribuiu. O resumo do atendimento não era salvo. O raciocínio deixa de ser reenviado nessa chamada. Contribuição de @stivanellidrop-dotcom.

Quando o lead pedia para ser procurado mais tarde, o sistema agendava o retorno e prometia voltar no horário combinado. Enquanto a promessa estava de pé, o fluxo de silêncio segurava o contato — mas, no minuto seguinte à mensagem do retorno, a inscrição nova deixava de ser segurada e o primeiro passo do fluxo saía por cima: duas mensagens seguidas, sem o lead ter respondido. A folga de um dia que já valia para quem estava no meio do fluxo passa a valer também para quem entra agora: enquanto o retorno acabou de sair, o contato não é inscrito pelo fluxo de silêncio, e continua valendo o mesmo prazo de sempre quando a folga termina. Nada muda para quem não tem retorno agendado, nem para os fluxos por etapa, por caso ou por lead.

Contribuição de @webtecnica (#2929), a partir da issue #2907.

Quando o agente mandava dia e dias_a_frente juntos para crm_find_free_slots — o que modelos GPT via OpenRouter fazem mesmo em pergunta aberta, com dia igual a hoje —, a busca olhava só aquele dia, e a resposta saía vazia com a agenda cheia de vagas. Agora o período começa no dia pedido (nunca antes de agora) e cobre pelo menos dias_a_frente dias inteiros (pode trazer o começo do dia seguinte); horários da véspera ficam de fora. dia sozinho continua recortando naquele dia. Diagnóstico e primeira versão do conserto: @webtecnica (#2921), a partir da issue #2889.

Ao mover vários negócios de uma vez para uma etapa de perda com um motivo, o motivo era gravado em todos os negócios selecionados, inclusive nos que já estavam perdidos, e o motivo original deles era trocado sem nenhum registro. Agora só os negócios perdidos nesse lote recebem o motivo; os que já estavam perdidos são movidos e mantêm o motivo que tinham. Os que já estavam perdidos deixam de aparecer no histórico como se tivessem sido perdidos de novo com o motivo do lote, e cada negócio perdido no lote passa a ter um registro próprio na auditoria, como acontece ao perder um negócio pelo card. A atualização aplica a mudança de banco sozinha.

Contribuição de @webtecnica (#2922), a partir da issue #2887.

Cada número de WhatsApp tem uma marca de "aquecimento completo", exposta na lista de conexões da API (is_warmup_complete). Até aqui ela era sempre "não", em toda instalação: o início do aquecimento nunca era gravado, e sem ele a conclusão não acontecia. Agora a primeira conexão do número grava o início (numa instalação existente, é a primeira conexão depois da atualização, inclusive em números usados há meses), e a marca vira "sim" quando o controle de ritmo de envio já não põe limite de aquecimento nele — a data em "Este número é usado desde" já passou do último degrau, ou "pular o aquecimento" está ligado. Uma reconexão no mesmo dia não marca mais um número novo como aquecido.

A marca anda quando o número informa que está conectado; um número que fica conectado sem reconectar recebe a marca com atraso, para o lado seguro. Depois de marcada, ela não volta: se "pular o aquecimento" for desligado ou a data em "Este número é usado desde" for trocada por uma mais recente, a marca continua "sim" enquanto o controle de ritmo volta a limitar. Por isso nada muda no envio: o limite de mensagens por dia continua vindo do controle de ritmo. Nenhuma configuração nova, nenhum passo manual.

Contribuição de @webtecnica (#2672), a partir da issue #2432.

No Brasil, o relatório de acesso aos dados (PDF), o e-mail que o titular recebe e o aviso de prazo ao encarregado rotulavam a citação do art. 18 da LGPD como "Base legal". O art. 18 é um direito do titular; a base legal fica nos arts. 7 e 11. Agora os três dizem "Direito exercido", como Portugal já dizia. Só essa palavra muda: prazos, dados e links continuam os mesmos, e o arquivo data.json brasileiro não muda.

Numa organização de Portugal, o rodapé do PDF passa a dizer "Responsável pelo tratamento" e "Encarregado da proteção de dados", em vez de "Controlador" e "Encarregado (DPO)". A política de privacidade passa a citar o RGPD e o NIPC, em vez da LGPD e do CNPJ. O data.json dessa organização ganha os campos papel_controlador e papel_encarregado. Os termos de Portugal foram revisados por IA, sem advogado, com a mesma ressalva da revisão anterior do RGPD.

Você não precisa fazer nada.

Contribuição de @webtecnica (#2719), a partir da issue #2344.

Atualizar pelo botão da tela (ou pelo update.sh) numa instalação que tem alteração local não commitada em arquivo que a versão nova troca passava pela conferência inicial, fazia o backup inteiro e só então parava no git checkout, com uma mensagem que não dizia quais arquivos eram nem o que fazer com eles. Agora a conferência inicial recusa antes de tocar em qualquer coisa, nomeia os arquivos e ensina a guardar ou desfazer o que é local. Alteração local em arquivo que a versão nova não troca continua não atrapalhando nada.

Você não precisa fazer nada.

Contribuição de @webtecnica (#2932).

A conferência inicial da atualização, que recusa antes do backup quando há alteração local no caminho da versão nova, ainda divergia da troca de versão em três casos: recusava à toa quando um arquivo do kit tinha sido apagado na instalação, ou quando a alteração já estava preparada e deixava o arquivo igual ao da versão nova; e deixava passar arquivo fora do controle de versão que a versão nova traz, que seguia parando a atualização depois do backup. Agora ela pergunta ao próprio git, com a mesma régua da troca de versão, e a mensagem nomeia todos os arquivos de uma vez, separando os alterados (guardar ou desfazer) dos que estão fora do controle de versão (mover ou apagar). A tela também deixa de repetir "nada foi parado" duas vezes.

Você não precisa fazer nada.

Conserto sobre a contribuição de @webtecnica (#2932).

Sem conexão direta com a Meta, o botão "Usar o recomendado" de Configurações › Conversões ligava etapas de qualificação com "Lead qualificado", um evento que o canal da conversa não repassa, e o aviso de evento sem saída aparecia em seguida. Agora, sem conexão direta, essas etapas ficam sem sugestão. Com conexão direta, nada muda. Conserto de @webtecnica (#2930).

Em Conexões, o diálogo Renomear reabria mostrando o texto que a pessoa tinha digitado e cancelado, em vez do nome atual da conexão — digite, cancele e reabra: o campo vinha com o que foi descartado (em português e em espanhol). Agora a reabertura sempre repõe o nome atual, pelos dois caminhos de abrir (o botão Renomear e a reabertura do diálogo); Cancelar, o X e o Escape continuam só fechando.

Você não precisa fazer nada.

Contribuição de @webtecnica (#2919).

Em Configurações › Etiquetas, renomear uma etiqueta para o nome de outra que já existe junta as duas numa só. A cor escolhida podia sumir nessa junção, porque ficava a primeira etiqueta da lista, tivesse cor ou não, e a tela dizia "Etiqueta atualizada" como num renome simples. Agora fica a etiqueta que tem cor ou descrição. Antes de confirmar, a tela avisa que as duas vão virar uma, e depois confirma com "Etiqueta juntada em". Mudar só maiúsculas e minúsculas do próprio nome continua sendo renome e não mostra o aviso. Excluir uma etiqueta segue sem tocar nas outras. A atualização aplica a mudança de banco sozinha.

Contribuição de @webtecnica (#2817), a partir da issue #2801.

O link de reunião enviado pela IA passa a conferir a marca "sempre atendimento humano" do contato diretamente, em vez de deduzi-la da trava de passagem a humano. Contato marcado não recebe o link pelo envio automático; o envio pelo botão do responsável continua funcionando. A devolução do atendimento ao agente confere a marca no mesmo passo em que grava: se ela estiver ligada nesse momento, nada é devolvido. A atualização aplica a mudança de banco sozinha.

Na tela de marca da instalação, com duas cores (a segunda para o tema escuro), a tira de tons desenhava só a escala da cor principal e marcava nela o tom do botão escuro, que vem da segunda cor. Agora aparecem duas tiras, uma por cor, cada uma marcando os seus tons. Com uma cor só, nada muda. A tela de marca da organização ainda mostra uma tira só.

Quando a verificação da agenda recusa um acompanhamento (por exemplo, porque o compromisso ao qual ele estava ligado mudou), o motivo do cancelamento passa a ser "Agenda do acompanhamento vencida", e não mais "Atendimento encerrado ou substituído". O cancelamento por atendimento encerrado continua com o texto de antes.

Você não precisa fazer nada.

Contribuição de @webtecnica (#2900), fechando restos declarados nos #2687 e #2709.