Corregido4
A agenda desenha no fuso da organização, não no do navegador
A agenda aberta fora do fuso da empresa desenhava as horas no relógio de quem abriu a tela: um compromisso às 09:00 da clínica aparecia às 09:00 do relógio de quem estava viajando ou com a máquina em outro fuso, a régua do "agora" subia para a hora local, e a chave de dia dos horários livres era a do navegador.
A âncora da semana já vinha do relógio da organização; faltava a grade. Os blocos, os rótulos de hora, a linha do "agora" e a chave de dia agora saem de partesNoFuso e diaLocalISO (lib/agenda/fuso.ts) sobre o fuso resolvido em page.tsx — a mesma fonte que o servidor usa para a primeira pintura.
Para quem tem navegador e organização no mesmo fuso — a maioria das instalações — a conversão é a identidade e nada muda de lugar. Um teste novo escolhe de propósito um fuso diferente do ambiente, fixa o instante e mede a posição da régua e o rótulo do card contra a hora de parede esperada; ele reprova se a grade voltar a ler o relógio local.
Refs #1362
Contribuição de @webtecnica (#1831).
A cópia de playbook que a organização editou também avisa quando sai versão nova no catálogo
Até aqui, a primeira edição de um playbook copiado do catálogo desligava de vez o aviso de versão nova: a cópia editada passava a aparecer como "manual" e nunca mais era avisada, justamente na empresa que mais precisa saber da atualização. Agora a cópia editada continua ligada à versão do catálogo de onde veio, segue marcada "do catálogo" e mostra o aviso quando a plataforma publica versão nova.
O aviso agora diz que, se a cópia foi editada, adotar a versão nova torna ativa a versão do catálogo e deixa as alterações só no Histórico de versões, de onde podem ser restauradas. Skills importadas por arquivo .zip continuam sem aviso. Uma cópia editada antes desta versão já tinha perdido o vínculo e continua sem o aviso.
Refs #1951
Contribuição de @webtecnica (#1960).
Anonimizar um contato também limpa a memória e os registros da IA sobre ele
Anonimizar um contato limpava a ficha, as conversas, as leads, as atividades e a régua, mas deixava dado pessoal em quatro lugares que o agente de IA escreve: as notas de memória (lead_notes), o registro de execução com os argumentos passados às ferramentas (ai_agent_runs.tool_calls), a próxima ação e a qualificação do funil (lead_state) e a identidade social do contato (contacts.social_identity).
As quatro fontes agora entram na cascata de anonimização. No registro de execução fica só o nome das ferramentas que rodaram, para a trilha do que o agente fez continuar legível; o texto do modelo, os argumentos e os resultados são apagados. Quem anonimiza pela ficha do contato tem tudo limpo na hora. Um pedido formal de exclusão tem essas fontes limpas na varredura diária de retenção, que já completava cascatas interrompidas. Nada precisa ser feito na instalação.
Refs #1957
Contribuição de @webtecnica (#1958).
O nome da marca no onboarding segue a configuração da tela Marca
As telas de boas-vindas, de primeiro acesso e o cabeçalho do onboarding escreviam o nome da marca lido só do arquivo de instalação (.env), então quem trocou o nome em Administração › Marca continuava vendo o nome antigo justamente nas primeiras telas. Agora elas usam o mesmo resolvedor do título da aba: a configuração salva na tela vence, e o .env segue como reserva. Sem marca própria configurada, nada muda.
Refs #1944
Contribuição de @webtecnica (#1961).