Versão 1.35.0v1.35.0

Quando uma atualização termina, a tela passa a contar o que aconteceu com o banco: se ele estava em disputa com o sistema no ar, quantas retentativas foram necessárias e em qual passada o banco fechou. Se a rodada não passou pelo banco — atualização só de código, por exemplo —, a tela não fala do assunto: ela não inventa uma passada que ninguém mediu. E uma rodada que NÃO conseguiu fechar o banco (a disputa persistiu até o teto de tentativas, ou veio um erro que retentativa não cura) também fica em silêncio: a frase existe para dizer que fechou, e afirmar fechamento onde não houve seria pior que não dizer nada.

O efeito para quem opera: uma atualização que precisou de três passadas por causa do sistema em uso deixa de parecer idêntica a uma que fechou de primeira, e o dono do servidor sabe que o "deu certo" dele veio acompanhado de disputa — o que muda o que ele confere depois.

Antes, o acervo de conhecimento só lia PDF, Markdown e texto puro — uma planilha exportada como CSV era recusada com "não sei ler esse tipo de arquivo", e Excel (.xlsx/.xls) continua recusado, mas agora com uma mensagem que ensina a exportar como CSV primeiro. Cada linha da planilha vira um bloco de busca próprio (Coluna: valor), então uma tabela de preços ou uma lista de perguntas frequentes em CSV passa a ser pesquisável pelo agente linha a linha, sem virar uma tabela ilegível depois de indexada. Crédito: @cabindaferreira.

Até agora não dava para montar um acompanhamento de retorno — "volte a falar com esta cliente daqui a 28 dias" — dentro de um fluxo. Qualquer espera era interrompida assim que o cliente mandasse qualquer mensagem: ou o acompanhamento era cancelado, ou o relógio era cortado e a mensagem de retorno saía na hora errada. Para uma cliente de manutenção, que conversa com o estúdio várias vezes no mês, os dois desfechos estavam errados — e por isso essa regra só existia escrita no prompt do agente, onde não dá para editar o prazo, ver quem está esperando nem medir o resultado.

Agora a espera de um fluxo tem uma opção nova. A resposta do cliente não encurta mais a espera. Ela vale só para esperas de 24 horas ou mais (numa espera curta seria um tiro no pé: prenderia alguém no meio da conversa) e o acompanhamento fica visível na fila como "Aguardando a data do retorno", com a data em que volta a falar. Enquanto ele dorme, o cliente continua podendo entrar em outros acompanhamentos — antes, um só já ocupava a vaga dele por todo o período.

Quem pede silêncio continua sendo respeitado: um "pare de me mandar mensagem" cancela também o retorno que estava dormindo.

Junto vem uma capacidade nova para os agentes de IA, "Iniciar um acompanhamento configurado", que deixa o agente pôr o cliente num fluxo que você montou na tela. É o que tira do texto do agente as decisões de quando falar, o que dizer e quando parar, deixando com ele só o que ele realmente sabe: que o atendimento terminou e ainda há motivo para voltar.

Há um limite conhecido, e ele importa antes de você armar um retorno longo: se o atendimento que originou o acompanhamento for encerrado ou substituído durante a espera, o envio é cancelado. Isso já acontecia com o retorno agendado pelo agente e não é novo — a diferença é que agora você fica sabendo: abre um aviso na Central dizendo qual fluxo era e que o retorno não saiu. Nada a fazer na VPS além de atualizar.

Sua equipe já guardava datas no funil — a data do casamento, o vencimento, o dia da prova — e elas não acionavam nada: quem quisesse avisar 240 dias antes teria de olhar negócio por negócio, e no dia certo.

Agora existe uma automação para isso, em Automações → Nova automação: escolha "Quando faltarem N dias para uma data do funil", diga de qual funil é o campo, qual campo de data e quantos dias antes avisar. No dia certo, a regra dispara uma vez por negócio — dá para mandar mensagem no WhatsApp, aplicar uma etiqueta, mover o card, o que a automação já fazia.

O número aceita sinal: 7 avisa sete dias antes da data; -60 avisa sessenta dias depois dela — é assim que a confirmação de entrega sai depois do casamento, com a mesma data que já está no negócio. O aviso sai às 9h da manhã no fuso da sua empresa, e cada negócio recebe uma vez só por regra: mudar a data depois do disparo não faz o aviso voltar — para uma segunda cobrança, crie uma regra nova.

A regra só dispara para negócios do funil e do campo escolhidos, e só nas organizações que a configuraram: quem não usa a automação não é varrido nem recebe nada.

Até aqui, mesmo com o clique do Google Ads já sendo capturado (versão anterior), o sistema não tinha como avisar o Google quando aquele lead virava venda de verdade — o anúncio continuava otimizando "pessoa que clicou", nunca "pessoa que comprou".

Agora existe a conexão completa: um botão "Conectar com Google" em Configurações › Conversões autoriza a organização, e a partir daí, sempre que um negócio vindo do Google Ads é marcado como ganho, o valor da venda é reportado de volta para a conta de anúncios — o mesmo laço que já existia para a Meta.

Não muda nada para quem não usa: a conexão precisa ser configurada explicitamente (autorizar + informar a conta de anúncios + a ação de conversão), e a instalação precisa ter as credenciais do Google Ads (GOOGLE_ADS_DEVELOPER_TOKEN, GOOGLE_ADS_OAUTH_CLIENT_ID, GOOGLE_ADS_OAUTH_CLIENT_SECRET) configuradas no .env — sem elas, o botão de conectar simplesmente não aparece.

Até aqui, uma organização que anunciava no Google Ads não tinha como saber quais leads do WhatsApp vieram de qual clique pago — o Google Ads, ao contrário da Meta, não tem um "Clique para o WhatsApp" nativo que carregue essa informação para dentro da conversa.

Agora existe uma landing page (/api/v1/anuncios/google/<organização>) que recebe o clique do anúncio, gera um código curto e redireciona para o WhatsApp com esse código já embutido no texto da mensagem. Quando a pessoa manda a mensagem, o sistema reconhece o código e carimba o contato com a origem do anúncio — o mesmo carimbo que já existe para a Meta.

Não muda nada para quem já usa o produto: a captura só funciona para a organização que configurar seu número de WhatsApp e o texto da mensagem em google_ads_landing_pages (ainda sem tela própria nesta versão). O passo seguinte — reportar a venda de volta para o Google Ads — continua fora do ar, porque depende de credenciais da API do Google Ads que a maioria das instalações ainda não tem.

Quando alguém assume uma conversa — pelo botão, pela IA passando para humano ou pelo celular —, o agente de IA para de responder nela até ser devolvido. Isso continua sendo a regra. O que muda: em Configurações › Distribuição de atendimento, a organização pode ligar um prazo (de 5 minutos a 24 horas) para devolver a conversa ao agente sozinha quando ninguém da equipe deu mais nenhum sinal — nem assumiu, nem respondeu pela tela ou pelo celular. O tempo conta do último sinal, então um atendimento longo com a pessoa respondendo não é interrompido. A volta acontece pelo mesmo caminho do botão "Devolver": as travas saem, o acompanhamento pausado retoma e a linha do tempo do negócio diz que foi o prazo, e depois de quantos minutos. Só devolve onde há agente publicado para aquele número — devolver para ninguém deixaria a conversa muda. Desligado (o padrão, inclusive para quem já tem o sistema instalado), nada muda: a IA só volta quando alguém clica em Devolver. Motivo: numa instalação real, 12 das 31 conversas ativas de um dia estavam paradas com humano, ninguém devolvia, e o cliente que escrevia de novo ficava sem resposta. Crédito: @Gervanno.

Quem opera em Angola não encontrava a própria moeda nem o próprio fuso: em Configurações › Organização, a lista de moedas ia só até dólar, peso e real, e as listas de fuso horário — da organização, do perfil de cada pessoa, da equipe e da janela de envio do WhatsApp — só ofereciam cidades da América do Sul. Sem a opção certa, restava deixar o relógio do Brasil e ver o agente respeitar a janela de envio três horas fora do lugar. Agora o kwanza aparece na lista de moedas (e o valor sai escrito como se escreve lá, 249,90 Kz) e "Luanda (Angola)" aparece em todas as listas de fuso. Nada muda para quem já usa o sistema: o padrão de quem nunca escolheu continua sendo real e São Paulo — o que entrou foi opção, não troca. Crédito: @cabindaferreira.

A documentação interna prometia autenticar chamada de servidor com um token começando em tok_, e o sistema exige dsk_. Quem seguia o texto recebia "credencial inválida" sem entender por quê — o prefixo tok_ não existia em nenhuma linha de código.

Além disso o texto descrevia a autenticação por chave de servidor como se valesse em toda a API, quando ela é habilitada rota por rota. Agora o texto diz a direção (é assim que o produto quer atender sistema externo, e as rotas vão sendo convertidas conforme cada integração precisa) e entrega o comando que responde quais rotas já aceitam hoje, em vez de um número que envelhece.

Nada muda para quem opera uma instalação: não há env nova, nem migration, nem comportamento diferente no que já estava no ar.

O PDF que responde ao direito de acesso do titular citava a LGPD fixa no código. Agora a citação sai do perfil do país da organização — e o documento simplesmente não cita lei quando o país ainda não tem a citação revisada, em vez de citar a de outro.

No Brasil, nada muda no que você entrega: a citação continua "LGPD Art. 18, II (Lei nº 13.709/2018)". O título do arquivo passa a ser "Relatório de Acesso aos Dados" — o documento é sobre o direito ao acesso, e o nome da lei é do país. O prazo de resposta também passa a ser contado no calendário de feriados do país da organização, não no brasileiro fixo.

Não há ação para quem opera a VPS.

Numa VPS cuja arquitetura não tem imagem publicada, o registro responde no matching manifest for linux/arm64/v8, o pull não traz imagem nenhuma e o up -d morre junto. O desfecho era o pior possível: o CRM continuava na versão antiga e ninguém era avisado — pelo botão Atualizar nem isso, porque o agente roda sozinho no cron e a falha não cabia na tela. Agora, quando o pull falha por arquitetura, o kit constrói aqui nesta VPS a MESMA versão alvo (docker-compose.build.yml, subindo pelo override com pull_policy: never para o Compose não voltar ao registro) e termina dizendo, em português, que as imagens foram construídas aqui nesta VPS e o motivo. Quando a imagem existe para a sua arquitetura, nada muda: nenhum build local, nenhuma ação sua, nenhuma variável, nenhum comando. Crédito: @webtecnica.

No passo "Verificar condição", a etapa do funil era digitada à mão. O sistema compara a etapa pelo código interno dela, então a regra "o lead está na etapa PAGO" nunca era verdadeira, e ninguém avisava: o fluxo publicava e o contato seguia pelo caminho errado. Agora a etapa é escolhida numa lista (com o nome do funil junto), o número de passos é um campo numérico, e publicar recusa a regra sem valor, a que aponta para etapa que não existe mais e a que ficou arquivada — dizendo qual regra corrigir. Um fluxo antigo com a etapa digitada à mão continua rodando como está; ao publicar de novo, o sistema pede para escolher a etapa.

Regras de "passos" também voltam a decidir como foram escritas: a tela antiga gravava o número como texto e o sistema nunca dava a regra por verdadeira, então "pelo menos 3 passos" mandava todo mundo pelo caminho do "não". Vale a pena conferir os fluxos ativos que comparam passos — eles podem passar a seguir por outro caminho, que é o que foi pedido quando a regra foi escrita.

No cartão de cada passo, o texto deixa de ser cortado no meio, o passo de classificar nasce com opções em português ("Interessado", "Sem interesse") no lugar de "hot"/"cold", "grace 15min" virou "espera 15 min", e a saída de escape de um passo que já tem saídas deixa de se chamar "Sempre" — ela só é usada quando nenhuma das outras serve, e agora se chama "Outros casos". As linhas entre os passos ganharam contraste: no tema claro elas quase sumiam.

A agenda de quem atende abria com um aviso de permissão sem motivo no lugar dos horários: a tela pedia a lista de membros da organização a uma rota que só quem administra pode ler, recebia a recusa e mostrava "Você não tem permissão para esta ação" — sem dizer de que permissão se tratava, nem como pedir. Quem atende agora lê a mesma lista por um caminho próprio, com o papel mínimo de quem atende, e o que essa lista devolve é só o que a barra da agenda usa: nome e se a pessoa tem agenda. E-mail e data do último acesso não saem por ali.

O horário ocupado no Google da dona da agenda também deixa de aparecer livre para quem atende. A ocupação passa a ser lida por pessoa, e não pelo que a sessão de quem olha tem direito de ver: quem atende recebia apenas a própria ocupação, e desenhava livre o horário em que a dona já estava comprometida. Quando a leitura de uma pessoa falha, o que foi lido das outras continua na tela, e o motivo da falha fica registrado.

A explicação do bloqueio passou a distinguir os dois casos que a mesma frase cobria. "Ocupado" é quando alguém já está comprometido naquele horário — inclusive no Google; "fora da jornada" é quando aquele horário não faz parte do que a pessoa publicou. O rótulo da coluna só diz "Você" quando o dono da agenda é quem está logado, e o painel do dono não escreve mais "Você" para si mesmo. E um dia de folga dentro da jornada deixou de ser anunciado como "Nenhum horário publicado neste dia", que fazia parecer configuração faltando para quem já tinha publicado jornada: a folga agora se anuncia como folga, e a falta de jornada continua tendo o seu próprio aviso.

Quem já roda o sistema não precisa fazer nada: nada de configuração mudou, só o que a tela diz e o que ela mostra.

Quem manda texto de conversa para o modelo tinha dois buracos: o BI angolano (003862011LA042) e o CPF de nove dígitos (541712345) atravessavam o anonimizador intactos — medido, antes do conserto, nos dois casos, um depois do outro.

Agora o conjunto de padrões é declarado no perfil do país, o anonimizador e a guarda que o confere usam o MESMO conjunto (antes eram duas listas que podiam divergir em silêncio), e documento novo entra pelo perfil em vez de virar mais um padrão solto no meio dos outros.

Ninguém precisa fazer nada.

Quando uma regra de automação aponta para outro funil e o contato já tinha um negócio aberto no funil antigo, a regra criava um SEGUNDO negócio e deixava o primeiro aberto: o mesmo cliente aparecia duas vezes, um card em cada funil, e ninguém sabia qual dos dois era o de verdade. Agora a regra TRANSFERE: o negócio é levado para o funil da regra com os mesmos dados (título, valor, responsável, campos personalizados e etiquetas) e o do funil antigo é encerrado como perdido, com o registro de para onde foi. Negócio aberto no mesmo funil continua sendo movido de etapa, e contato sem negócio aberto continua ganhando um negócio novo.

Esse encerramento não conta como perda comercial: "Levado para outro funil" é o motivo próprio da transferência, e as métricas de perdas (a por responsável e a do relatório de atrito) deixam de contá-lo — trocar de funil não é perder o negócio. O motivo de sistema também não aparece na janela "Marcar como perdido": ele continua gravado pela transferência, mas não é oferecido a quem está fechando um negócio à mão — sem isso, um clique tiraria uma perda comercial real do número. A atualização aplica a mudança no banco sozinha: nada precisa ser feito à mão, e negócio encerrado antes dela continua contando como perda.

Quando uma regra de automação ia atribuir um responsável a um negócio e a consulta que confere se aquela pessoa é membro da organização não voltava — rede fora, banco fora —, a regra terminava dizendo user_not_in_org, como se o responsável escolhido tivesse saído da organização. O aviso mandava o operador mexer justamente no que estava certo: quem ele havia escolhido para atender.

Agora a ação separa "não é membro" de "não deu para saber". O responsável que realmente não é membro continua sendo recusado do mesmo jeito, com user_not_in_org. Quando a consulta falha, a execução passa a ser marcada com o código membro_indeterminado, e a mensagem do erro fica registrada no detalhe da execução.

O que muda para quem opera, hoje: o histórico da regra deixa de acusar a configuração. Antes ele dizia que o responsável escolhido estava fora da organização, o que mandava mexer justamente no que estava certo. A frase amigável para esse caso na aba Atividade ainda não existe — o histórico mostra o código — e está sendo tratada à parte.

Ao terminar, o Playwright agora remove as sessões de WhatsApp criadas pelos seeds E2E. Também há um script explícito para limpar resíduos antigos; em banco remoto ele exige --allow-remote para evitar exclusão acidental. Crédito: @joaopaulomirandamatias.

Na aba Fila, a posição de cada conversa era calculada pela ÚLTIMA mensagem do cliente. O efeito era o inverso do pretendido: quem escrevia de novo — cobrando, perguntando outra vez — reiniciava a própria espera e descia para o fim, atrás de quem escreveu uma vez e ficou quieto. Quem mais estava tentando ser atendido era o último a ser atendido.

A régua agora é a mensagem do cliente mais antiga que ninguém respondeu ainda, e é ela que ordena a lista, que a pílula "Aguardando há…" mostra e que a posição dita no WhatsApp usa. A resposta do atendente continua encerrando a espera: a partir dela, a próxima mensagem do cliente conta do zero, como deve ser.

Um aviso para quem já tem fila rodando: a atualização preenche a coluna nova das conversas que já existem, usando as mensagens de cada atendimento. Na prática, conversas que estavam no fim da fila porque o cliente insistiu vão subir, e as que estavam no topo podem descer — a ordem passa a refletir quanto tempo cada um espera de fato. Nada precisa ser feito à mão.

O template self-host não pré-define mais SENTRY_DSN vazio antes da primeira execução. Assim, o instalador volta a perguntar pelo envio de relatórios de erro; em modo --yes, mantém a telemetria desligada, e uma escolha anterior continua preservada nas reexecuções. Crédito: @joaopaulomirandamatias.

Instalação e atualização agora recusam ARM64/aarch64 antes de consultar ou baixar as imagens do DeskcommCRM, explicando que as imagens oficiais atuais são linux/amd64 e orientando usar uma VPS x86_64/amd64. Crédito: @joaopaulomirandamatias.

Em Configurações › Organização dá para escolher a moeda da empresa, e o funil ignorava a escolha em dois pontos. O total no topo de cada coluna do quadro saía sempre com R$ na frente — o número estava certo e o símbolo mentia. E todo negócio criado pela tela "Novo negócio" nascia em real, mesmo numa empresa que opera em peso ou dólar: o valor cadastrado passava a ser exibido na moeda errada em toda tela que o mostra. Agora o total sai na moeda dos negócios da coluna, e um negócio novo nasce na moeda que a empresa declarou. Nada muda para quem opera em real, e nenhum negócio já cadastrado tem a moeda alterada — o conserto vale para o que nasce daqui em diante. Um detalhe visível: o total da coluna passa a mostrar os centavos, porque quem os escondia era a mesma linha que escondia a moeda. Crédito: @cabindaferreira.

Um PDF de poucos KB recebido no WhatsApp reiniciava o processo do agente de IA a cada poucos segundos (estouro de memória ao ler o arquivo), e enquanto isso nenhuma conversa era respondida — o mesmo PDF voltava à fila e derrubava de novo, sem limite. Agora a leitura de PDF roda num processo à parte, com teto de memória próprio: um arquivo que não dá para ler vira um erro comum daquela mensagem, o agente segue respondendo, e depois de cinco tentativas a Central de Avisos recebe o aviso. Vale também para qualquer outro processamento que derrube o processo no meio: ele passa a contar como tentativa em vez de voltar à fila para sempre.

Toda falha ao ler um PDF no acervo de conhecimento — qualquer uma — aparecia como "Se ele for só imagens escaneadas, não há letra nenhuma para ler", mesmo quando o PDF tinha texto selecionável e o problema era outro (por exemplo, uma dependência nativa ausente na instalação). A mensagem específica que extractPdfText já produzia para cada causa era descartada e trocada por essa frase única em lib/ai/rag/ingest/documento.ts, então quem enviava um PDF perfeitamente legível recebia uma explicação que apontava para o próprio arquivo como culpado. Agora a causa relatada é a causa real — e, no caso que motivou o conserto (uma peça nativa do leitor de PDF que ficou de fora da imagem), a mensagem diz o que quem opera a VPS pode de fato fazer: atualizar a instalação e, se não resolver, avisar quem instalou. Antes ela mandava reinstalar pacotes, que num servidor com a imagem pronta não é um passo que exista. Crédito: @cabindaferreira.

A tela Uso e orçamento mostrava gasto zero em instalações que atendem no Claude Sonnet 5 — o modelo padrão do catálogo —, e o limite mensal nunca disparava, por mais que a conta do provedor subisse. A tabela de preços interna tinha parado na geração 4 dos modelos, e o que ela não conhece é registrado como custo desconhecido, que o teto soma como zero. Agora a geração 5 tem preço, e o gasto aparece e conta. Pelo mesmo motivo, o Claude Opus 4.5 em diante era cobrado ao preço do Opus 4 aposentado, três vezes mais caro, o que fazia o teto disparar antes da hora. Crédito: @maclevison.