Version 1.68.0v1.68.0

O Jev ganha duas tarefas: Perceber pedido para falar com uma pessoa e Perceber pedido para parar de receber mensagens. Hoje quem percebe esses pedidos é uma regra sem IA: ela passa a conversa a uma pessoa quando o cliente escreve "quero falar com um atendente" (ou uma das palavras de passagem do agente) e bloqueia o contato quando ele manda "PARAR". Ela é precisa, mas estreita: "quero falar com alguém de verdade, não com robô" passa por ela sem ser visto.

O Jev só é perguntado onde a regra de hoje disse não — a mensagem que ela já pegou nem sai para a TypeSafe, e a regra olha todas as mensagens do cliente ainda sem resposta, como o atendimento automático olha: "quero falar com um atendente" seguido de "por favor, alguém de verdade" é um pedido que ela pegou — e só onde há um atendente automático no ar naquele número, sem pessoa no comando. Pedido mandado por áudio não é perguntado. As duas perguntas vão juntas, numa chamada ao Jev separada da do clima da conversa: uma falha nela nunca muda a medição do clima.

As duas tarefas começam só observando. O cartão do Jev, em IA › Provedores, mostra em quantas mensagens dos últimos 30 dias o Jev percebeu um pedido que a regra de hoje não reconheceu, com links para as conversas mais recentes, para você ler o que o cliente escreveu. A conta é por mensagem, e não por pedido: um cliente que escreve duas frases desse tipo seguidas conta duas. Onde nenhum atendente automático está no ar (ou o atendimento está com um sistema de fora), o cartão mostra as duas tarefas como "Não roda", com o motivo. Em IA › Execuções, a chamada aparece como "Perceber pedidos do cliente".

Quando quiser, clique em "Avisar a equipe" na tarefa (o cartão explica o efeito e pede confirmação antes de valer). A partir daí, cada pedido que o Jev perceber abre um aviso na Central de avisos, um por conversa, com o botão "Abrir a conversa"; se o cliente pedir de novo, o mesmo aviso volta a abrir (ou, se ainda estiver aberto, sobe para o topo), com a data do pedido novo. O aviso não repete o que o cliente escreveu — a mensagem fica na conversa, para quem pode vê-la. O de falar com uma pessoa se fecha sozinho quando a conversa fica com uma pessoa (alguém assume, ou o atendimento automático a passa) ou é encerrada; se isso aconteceu enquanto o Jev respondia, ele nem nasce. O de parar de receber diz à equipe o que ela pode fazer — assumir a conversa, para o assistente parar de responder, e pedir ao cliente que responda "PARAR", que é o que bloqueia o contato —, e por isso não se fecha ao assumir: fica aberto até o contato ser bloqueado ou a conversa ser encerrada. O "Marcar resolvido" continua valendo para os dois. Com as tarefas avisando, o cartão segue dizendo que o Jev observa: ele não decide nada no lugar da regra. Em nenhum estado o Jev passa a conversa, bloqueia alguém, cala o agente ou responde o cliente: quem passa a conversa continua sendo a regra de hoje ou uma pessoa, e quem bloqueia o contato é só a regra de hoje, quando o próprio cliente manda "PARAR". Para voltar, clique em "Voltar a só observar".

Quem já tem o Jev ligado vê as duas tarefas com o selo "Nova", já observando: elas usam o mesmo dado que você já autorizou — cada mensagem, sozinha, sem CPF, telefone e e-mail. Isso é uma chamada a mais ao Jev por mensagem em que a regra não viu algum dos pedidos (uma fração de centavo de dólar, cobrada na sua conta da TypeSafe). Para não usar, clique em "Pausar esta tarefa" no cartão. A política de privacidade passa a listar essas duas finalidades. Nada precisa ser editado para atualizar.

Se a instalação voltar para uma versão anterior, as duas tarefas deixam de rodar e o estado delas fica guardado; os avisos já abertos continuam na Central, e seguem se fechando sozinhos.

A atualização do aplicativo parava na etapa "Atualizando o banco de dados" com erro duplicate key value violates unique constraint "ai_pricing_pkey" quando o mesmo modelo existia ativo, com preço, em dois provedores ao mesmo tempo (ex.: openrouter e requesty) e ainda não tinha linha em ai_pricing. Como ai_models permite um model_id por provedor, o backfill de preços gerava duas linhas iguais dentro do mesmo comando e a chave primária (que é só o model) recusava a segunda. O erro não deixava nenhuma versão atualizar nem voltar com --force naquela instalação.

Agora o backfill emite uma única linha por modelo, escolhendo de forma determinística o provedor de menor preço quando houver o mesmo modelo em mais de um provedor; o mecanismo idempotente (não reescrever preço já existente) continua intacto. Quem estava travado por esse erro basta rodar a atualização de novo: ela completa sem ação manual no banco.

Contribuição de @webtecnica (#2008); reportado e investigado no banco por @aerosuiteapp (#1998).

Ao confirmar uma etapa durante a conversa, o agente agora passa ao espelho do CRM os funis autorizados em sua versão publicada. Um agente sem acesso ao funil não move mais o cartão, inclusive quando retoma um caso interno; agentes com o funil autorizado continuam podendo atualizar a etapa. O estado da conversa e a resposta ao cliente seguem seu fluxo normal.

Contribuição de @arodalves (#2006).