akitaonrails/ai-memory

O problema

A interface de comandos executa tarefas administrativas no servidor de memória, incluindo consultas de integridade, envio de dados e geração de cópias de segurança. Em ambientes corporativos com portais de acesso ou proxies que interceptam o tráfego com telas de autenticação, o cliente leve seguia os redirecionamentos de forma irrestrita. Com isso, rotinas de backup salvavam o código HTML do portal no lugar do arquivo de dados e sobrescreviam cópias anteriores, enquanto consultas de diagnóstico tentavam interpretar respostas inválidas.

O que foi feito

O PR propõe padronizar as requisições do cliente leve em uma instância compartilhada que recusa terminantemente qualquer redirecionamento de rede. Caso o servidor responda com códigos de desvio, a operação é interrompida com erro imediato, preservando arquivos locais pré-existentes e mantendo corpos de envio protegidos contra retransmissão. Testes automatizados simulam servidores de redirecionamento para assegurar que consultas e exportações falhem com segurança sem contatar rotas intermediárias.

Valor entregue

Protege a integridade de cópias de segurança locais e assegura diagnóstico imediato de bloqueios de rede em infraestruturas corporativas.

Ver o PR #1933 no GitHub

O problema

O pacote auxiliar em PowerShell registra eventos de ciclo de vida das sessões e recupera resumos de contexto em ambientes Windows. Em redes protegidas por portais cativos ou proxies corporativos com autenticação intermediária, as requisições seguiam redirecionamentos HTTP automaticamente. Respostas de redirecionamento para telas de autenticação eram interpretadas como entrega bem-sucedida, excluindo arquivos da fila local sem gravá-los no servidor e injetando o código da página de login como contexto da sessão.

O que foi feito

O PR propõe bloquear qualquer redirecionamento HTTP nas requisições do módulo PowerShell e considerar não entregue qualquer resposta diferente dos códigos de sucesso padrão. Eventos pendentes continuam preservados na fila local até que a conexão legítima seja restabelecida, impedindo também o envio de cabeçalhos de autorização para servidores externos. Testes com servidores de teste confirmam que respostas de redirecionamento mantêm os arquivos locais intactos e não transferem dados para destinos não autorizados.

Valor entregue

Evita a perda de eventos de rastreamento e o vazamento de credenciais em redes corporativas com autenticação intermediária.

Ver o PR #1931 no GitHub

O problema

Ambientes com portais cativos ou proxies corporativos costumam responder com redirecionamentos HTTP para telas de autenticação. Ao seguir essas respostas, o cliente de ganchos considerava os eventos entregues e apagava a fila em disco, ou inseria o HTML da página de login diretamente no contexto de continuidade do agente. Além disso, redirecionamentos temporários podiam reenviar cargas úteis de telemetria para servidores terceiros.

O que foi feito

O construtor do cliente HTTP nativo de ganchos agora desativa explicitamente o seguimento de redirecionamentos. Respostas de redirecionamento são tratadas como falha de entrega, o que preserva os eventos em disco para novas tentativas e descarta qualquer conteúdo vindo de fora. Testes automatizados confirmam que o cliente recusa desvios temporários e definitivos sem acionar o servidor de destino.

Valor entregue

Protege o contexto do agente contra injeção de HTML externo e garante que nenhuma mensagem de sessão se perca em redes com autenticação intermediária.

Ver o PR #1819 no GitHub

O problema

No ai-memory, os comandos de gerenciamento de usuários permitem conceder privilégios de acesso a projetos e revogar permissões ativas. Ao contrário de comandos que operam no contexto da pasta atual, essas operações recebem argumentos obrigatórios de usuário, workspace, projeto e nível de acesso. Se disparados com variáveis de ambiente vazias, o sistema enviava chamadas com campos nulos diretamente aos pontos de alteração de privilégios da API administrativa.

O que foi feito

O PR propõe validar e recusar imediatamente valores em branco nas opções de usuário, workspace, projeto e nível de permissão antes de emitir as requisições de concessão e revogação. Testes unitários com servidores simulados inalcançáveis garantem que chamadas com qualquer um dos quatro campos vazios falhem de imediato com a mensagem esperada, preservando a entrega de credenciais válidas.

Valor entregue

Garante que mudanças de privilégios e permissões de usuários só sejam despachadas com todos os identificadores devidamente preenchidos.

Ver o PR #1798 no GitHub

O problema

No ai-memory, os comandos de gerenciamento de projetos permitem alterar a visibilidade entre pública e restrita e auditar as permissões concedidas. Como esses comandos exigem argumentos nominais e não passam pela dedução automática de pasta de trabalho, a passagem de variáveis não definidas gerava requisições com projeto, workspace ou modo vazios diretamente contra a API de administração do servidor.

O que foi feito

O PR propõe recusar explicitamente argumentos vazios ou preenchidos apenas com espaços antes de enviar qualquer requisição HTTP, cobrindo o projeto, o workspace e a modalidade de acesso. Testes unitários comprovam a interrupção precoce das chamadas com mensagens de erro claras, garantindo que nomes reais continuem sendo repassados sem alteração.

Valor entregue

Evita chamadas defeituosas à API de segurança e protege a integridade das políticas de acesso contra scripts com parâmetros não inicializados.

Ver o PR #1796 no GitHub

O problema

O ai-memory permite cadastrar webhooks de admissão que avaliam e enriquecem documentos da wiki antes da gravação definitiva. Pelo comportamento padrão do cliente HTTP, respostas com redirecionamento temporário ou permanente faziam o sistema reenviar todo o conteúdo da página, metadados e identificadores de projeto para qualquer endereço externo informado, inclusive com rebaixamento de protocolo seguro. Além de vazar dados confidenciais a terceiros não autorizados, respostas dessa origem externa podiam alterar o texto final persistido.

O que foi feito

O PR propõe configurar uma política personalizada de redirecionamentos no cliente HTTP de admissão que exige estrita correspondência de protocolo, domínio e porta da requisição anterior. Qualquer tentativa de redirecionamento para outra origem encerra a chamada com erro, sem repassar o corpo da mensagem nem acatar modificações externas no documento, enquanto redirecionamentos internos na mesma origem continuam permitidos. Testes de integração cobrem a recusa contra servidores externos e a preservação de rotas internas.

Valor entregue

Impede o vazamento de documentos internos da wiki e protege a integridade dos dados contra adulteração por servidores externos não homologados.

Ver o PR #1795 no GitHub

O problema

O comando de encerramento de sessões do ai-memory permite fechar atividades abertas de agentes de IA informando o escopo do projeto. Quando opções de escopo eram passadas com valores vazios por scripts ou variáveis de ambiente não preenchidas, a rotina tratava o parâmetro como omitido e recorria à pasta do diretório atual. Isso fazia o comando encerrar indevidamente as sessões ativas do repositório local sem aviso ao usuário.

O que foi feito

O comando passou a validar e recusar imediatamente valores vazios ou contendo apenas espaços nas opções de workspace e projeto antes de tentar resolver o escopo ou listar sessões abertas. Testes unitários foram adicionados cobrindo espaços em branco em ambas as opções e confirmando a falha antecipada.

Valor entregue

Evita o encerramento acidental de sessões ativas do projeto local durante automações ou rotinas de limpeza com parâmetros vazios.

Ver o PR #1772 no GitHub

O problema

No ai-memory, páginas da wiki de um projeto podem ser lidas via linha de comando especificando escopo, caminho ou termo de busca. Quando uma variável de ambiente vazia era passada nas opções de projeto ou workspace, o comando ignorava o valor vazio e recorria silenciosamente à pasta do projeto atual, consultando documentos do repositório local sem confirmação do usuário. Além disso, passar caminho ou termo de busca em branco gerava requisições inválidas contra a API do servidor.

O que foi feito

O comando passou a validar e recusar imediatamente valores vazios ou compostos apenas por espaços nas opções de workspace, projeto, caminho e termo de busca, antes de qualquer resolução de escopo, autenticação ou envio de requisição à rede. Testes unitários foram incluídos cobrindo cada opção e a ausência simultânea de caminho e busca, garantindo alinhamento com os demais comandos da wiki.

Valor entregue

Impede consultas indevidas à base de conhecimento do projeto local quando scripts passam parâmetros vazios e evita chamadas desnecessárias ao servidor.

Ver o PR #1770 no GitHub

O problema

O ai-memory tem uma caixa de mensagens entre projetos, operada pela linha de comando para enviar, retirar e cancelar pedidos. Um escopo vazio era tratado como ausente e resolvido pela pasta de trabalho. Assim, retirar uma mensagem com projeto vazio pegava a próxima mensagem da caixa do projeto local, cancelar com a opção de todas cancelava todas as mensagens pendentes daquele projeto, e enviar com remetente vazio atribuía a mensagem ao projeto da pasta atual, enquanto destinos vazios geravam pedidos inválidos. Tudo sem que o usuário tivesse nomeado esse projeto.

O que foi feito

Os três comandos passaram a recusar valores vazios ou só com espaços em todas as opções de escopo e alvo (workspace e projeto de origem e de destino, workspace, projeto e identificador da mensagem) antes de ler a entrada padrão ou enviar qualquer requisição. Oito testes automatizados cobrem os casos de cada comando, a mensagem de erro compartilhada foi reescrita para valer tanto para escopos quanto para alvos, e o registro de mudanças documenta o comportamento.

Valor entregue

Impede que uma automação com variável esquecida leia, cancele ou envie mensagens em nome do projeto errado, preservando o isolamento entre as caixas de cada projeto.

Ver o PR #1762 no GitHub

O problema

O comando de renomear projetos já recusava valores vazios no workspace, na origem e no identificador do projeto, mas não no nome de destino. Com um destino vazio, caso típico de variável de ambiente não definida num script, o comando resolvia o projeto de origem e mandava ao servidor um pedido com o novo nome em branco, deixando para o servidor a tarefa de rejeitar algo que podia ter sido barrado na origem. Outros comandos com destino, como mover projeto e mover sessão, já recusavam o valor vazio.

O que foi feito

O nome de destino passou pela mesma verificação dos demais parâmetros, recusando valores vazios ou só com espaços antes de resolver o projeto ou enviar qualquer requisição. Três testes automatizados cobrem o destino, a origem e o workspace, e o registro de mudanças documenta o comportamento.

Valor entregue

Dá ao comando de renomear projetos a mesma proteção dos outros comandos de alteração, com um erro claro na hora certa em vez de um pedido inválido ao servidor.

Ver o PR #1760 no GitHub

O problema

A linha de comando do ai-memory grava páginas na wiki de um projeto, com o conteúdo vindo de um argumento ou da entrada padrão. Um projeto vazio era tratado como ausente e o comando deduzia o projeto da pasta de trabalho, então um script com variável não definida gravava ou sobrescrevia uma página no projeto errado, sem aviso. Com caminho vazio, o comando ainda ficava bloqueado esperando a entrada padrão antes de enviar uma requisição inválida. A mesma proteção já havia sido aplicada aos comandos de apagar, restaurar e mover, mas não a este.

O que foi feito

O comando passou a recusar valores vazios ou só com espaços nas opções de workspace, de projeto e de caminho antes de ler a entrada padrão ou enviar qualquer requisição, com mensagem que nomeia a opção. Quatro testes automatizados cobrem cada opção e o caso em que a recusa precisa acontecer antes da leitura da entrada. A documentação do comando e o registro de mudanças foram atualizados.

Valor entregue

Protege a wiki de cada projeto contra gravações e sobrescritas acidentais vindas de automações, mantendo o conteúdo onde o autor mandou.

Ver o PR #1758 no GitHub

O problema

O ai-memory organiza o trabalho de um projeto em frentes (workstreams), que podem ser renomeadas pela linha de comando. Um projeto vazio era tratado como ausente e o comando deduzia o projeto da pasta de trabalho, o que em scripts com variáveis não definidas apontava para o projeto errado. Um nome de origem vazio ainda passava pela verificação de ausência, porque chegava embrulhado como valor presente, e um nome de destino vazio era enviado ao servidor em branco.

O que foi feito

O comando passou a recusar valores vazios ou só com espaços nas opções de workspace, de projeto, de origem e de destino antes de olhar o repositório ou enviar qualquer requisição, com mensagem que nomeia a opção. Quatro testes automatizados cobrem cada caso, e o registro de mudanças documenta a mudança.

Valor entregue

Garante que uma renomeação só acontece no projeto e na frente de trabalho que foram de fato nomeados, sem efeitos colaterais vindos de variáveis esquecidas.

Ver o PR #1703 no GitHub

O problema

A linha de comando do ai-memory apaga páginas da wiki de um projeto. Ao resolver o escopo, um valor vazio era tratado como opção ausente e o comando deduzia o projeto a partir da pasta de trabalho. Em scripts, uma variável não definida chega como texto vazio, então um projeto vazio mirava o projeto local e apagava a página ali, um alvo que ninguém escolheu. Um caminho vazio seguia o mesmo rumo e gerava uma requisição inválida. A proteção já existia para os comandos de expurgo e de mover ou renomear projeto, mas não para este.

O que foi feito

O comando passou a recusar valores vazios ou só com espaços nas opções de workspace, de projeto e de caminho antes de resolver o escopo ou enviar qualquer requisição, com uma mensagem que nomeia a opção. Três testes automatizados garantem a recusa antecipada, e o registro de mudanças documenta o comportamento.

Valor entregue

Evita que uma automação apague uma página do projeto errado, mantendo o isolamento entre projetos e a confiança de que só se apaga o que foi nomeado.

Ver o PR #1701 no GitHub

O problema

A ferramenta de linha de comando do ai-memory move sessões de um projeto para outro, inclusive em lote. Ao resolver o escopo, a rotina tratava um valor vazio como se a opção não tivesse sido informada e caía no padrão de deduzir o projeto a partir da pasta de trabalho. Em scripts e automações, uma variável de ambiente não definida chega ao comando exatamente assim, como texto vazio. Com isso, um projeto de origem vazio disparava a migração de todas as sessões do projeto da pasta atual para o destino, um alvo que ninguém havia digitado. A mesma proteção já existia para as operações de expurgo, de mover projeto e de renomear projeto, mas não para esta.

O que foi feito

O comando passou a verificar as quatro opções de escopo (projeto e workspace de origem, workspace de destino e destino) antes de montar ou enviar qualquer requisição, recusando valores vazios ou só com espaços com uma mensagem que nomeia a opção problemática. Quatro testes automatizados cobrem cada uma das opções e garantem que a recusa acontece antes de qualquer contato com o servidor. O registro de mudanças documenta o comportamento.

Valor entregue

Impede que uma automação com variável esquecida mova em lote a memória de um projeto inteiro para o lugar errado, preservando o isolamento entre projetos.

Ver o PR #1699 no GitHub

O problema

A base de vulnerabilidades do ecossistema Rust emitiu um alerta de segurança para versões antigas da biblioteca de concorrência Tokio. Embora as funções afetadas não fossem utilizadas pelo código do ai-memory, as ferramentas automáticas de auditoria de dependências na integração contínua passaram a reprovar todas as propostas abertas no repositório por encontrarem versões antigas registradas nos arquivos de dependências travadas.

O que foi feito

O PR propõe atualizar a versão do Tokio para 1.54.1 no arquivo principal de dependências e nos três serviços auxiliares de retransmissão, importação e sincronização de wikis. A alteração remove a vulnerabilidade apontada, mantém o restante das dependências inalterado e restabelece a aprovação nos testes automáticos de segurança.

Valor entregue

Mantém o ecossistema do ai-memory em conformidade com as diretrizes de segurança da cadeia de suprimentos de software e destrava os gates de auditoria.

Ver o PR #1661 no GitHub

O problema

A interface web do ai-memory monta suas páginas com a biblioteca askama, que por padrão inclui um leitor de arquivos de configuração TOML, usado só quando existe um arquivo de configuração do askama. O projeto não tem esse arquivo, mas carregava a biblioteca de leitura, que não recebe mais manutenção. Em 20 de outubro de 2026 um alerta foi registrado contra ela na base de vulnerabilidades do Rust; não existe versão corrigida, e as versões mais novas do askama trazem a mesma dependência. A verificação automática de dependências passou a reprovar todos os PRs abertos contra a branch principal, inclusive o do instalador para Windows, e nenhuma troca de versão resolvia.

O que foi feito

O PR desliga o recurso de configuração do askama e mantém ligados os outros três que já vinham por padrão (formatação de tamanhos, de números e de endereços), de modo que os filtros dos modelos continuam como estavam. Sem o recurso, a biblioteca sem manutenção e duas ligações opcionais saem do arquivo de dependências. Nenhuma página muda, porque os modelos informam apenas o caminho do arquivo e, com ou sem o recurso, valem as mesmas regras padrão. Silenciar o alerta manteria a biblioteca na compilação, por isso a remoção foi a escolha.

Valor entregue

A verificação de segurança das dependências volta a passar, destrava os PRs abertos e reduz o código de terceiros sem manutenção dentro do produto.

Ver o PR #1483 no GitHub

O problema

O ai-memory monta um perfil de preferências do usuário, válido para todos os projetos, colhendo dos pedidos frases com cara de preferência; cada uma guarda o texto original e aponta para a sessão de origem. Expurgar um projeto apagava essas frases, mas expurgar uma sessão apagava a sessão, seus registros, páginas e passagens de bastão e deixava as frases para trás. Uma rodada posterior ainda podia gravá-las numa página do perfil.

O que foi feito

O expurgo de sessão passou a apagar também as frases colhidas dos pedidos daquela sessão, na mesma operação que apaga o resto. O teste confere que somem só as frases da sessão expurgada, e não as de uma sessão vizinha nem as do mesmo identificador em outro projeto. O que já tinha sido incorporado ao perfil antes do expurgo continua dependendo do comando próprio de esquecer.

Valor entregue

Um pedido de exclusão passa a valer também para as palavras do próprio usuário: uma frase de uma sessão expurgada não pode mais reaparecer no perfil compartilhado entre projetos.

Ver o PR #1195 no GitHub

O problema

O comando de expurgo apaga uma sessão e deixa uma marca para que eventos atrasados, ainda na fila de um cliente ou vindos de um agente que segue aberto, não a recriem. Essa verificação ficava num ponto por onde a captura ao vivo deixou de passar: a entrada de eventos dos agentes criava a sessão por conta própria, sem olhar a marca. Assim, o próximo evento de uma sessão expurgada a trazia de volta, com um registro novo.

O que foi feito

A entrada de eventos passou a checar a marca e recusar o evento, respondendo "descartado, nunca poderá ser gravado" em vez de falha; sem isso, o cliente manteria o evento, e tudo o que viesse atrás dele, na fila, tentando de novo por uma sessão que não pode mais voltar. Os testes conferem que uma sessão vizinha e o mesmo identificador em outro projeto continuam aceitos.

Valor entregue

O expurgo de uma sessão passa a ser definitivo: o que a pessoa pediu para apagar não reaparece com o próximo evento. E os clientes de captura deixam de ficar presos reenviando esses eventos.

Ver o PR #1194 no GitHub

O problema

O ai-memory guarda trechos das sessões (pedidos, resultados de ferramentas, notificações, resumos) com um tamanho máximo para cada tipo. O corte vinha antes do filtro que esconde senhas e chaves de acesso, então um segredo no ponto de corte era partido, e o pedaço restante, curto demais para ser reconhecido, ficava gravado em texto puro. Na máquina do usuário, o cliente de captura cortava textos grandes sem filtro nenhum, e o pedaço chegava ao servidor já irreconhecível.

O que foi feito

A ordem foi invertida nos dois lados: primeiro o texto inteiro passa pelo filtro de segredos, depois é cortado no tamanho máximo, que continua o mesmo. Testes novos colocam uma chave exatamente no ponto de corte de pedidos, resumos e resultados de ferramentas, e também na fila local. Em todos os casos, só a marca de ocultação chega a ser gravada.

Valor entregue

Fecha um caminho pelo qual pedaços de senhas e chaves de acesso podiam ficar gravados na memória do projeto, apesar do filtro. É o mesmo tipo de falha já corrigido antes nos títulos dos registros, agora fechado também no conteúdo.

Ver o PR #1128 no GitHub

O problema

Os agentes podem avaliar se uma memória recuperada foi útil e anexar um motivo de até 500 caracteres. O texto era cortado no limite e só depois passava pelo filtro que apaga segredos, como chaves de acesso. Um segredo que cruzava o limite ficava curto demais para ser reconhecido, e o pedaço inicial era gravado e podia aparecer no relatório de auditoria da wiki.

O que foi feito

A ordem foi invertida: o motivo passa primeiro pelo filtro de segredos, depois é reduzido a uma linha e só então cortado em 500 caracteres. Um teste novo coloca uma chave de acesso começando 12 caracteres antes do limite e confirma que nenhum pedaço dela sobra. É a mesma correção já aplicada antes aos títulos das observações capturadas nas sessões.

Valor entregue

Fecha mais um caminho pelo qual fragmentos de credenciais dos usuários podiam chegar ao banco de dados e aos relatórios da ferramenta. A proteção passa a valer onde quer que o segredo caia no texto.

Ver o PR #1109 no GitHub

O problema

O ai-memory mantém anotações curtas de contexto, como o foco atual, que entram no resumo de início de cada sessão e, num servidor com vários usuários, podem ser pessoais. A gravação já levava cada usuário para a sua própria área, mas a exclusão não: apagar o caminho genérico removia a versão compartilhada que chega a todos, e indicar o caminho de outra pessoa apagava a anotação dela.

O que foi feito

A exclusão passou a seguir a mesma regra da gravação. Um usuário comum que apaga o caminho genérico remove só a própria versão, e a tentativa de apagar dentro da área de outra pessoa é recusada com uma mensagem clara. Administradores continuam podendo apagar qualquer uma, e com o modo por usuário desligado, que é o padrão, nada muda.

Valor entregue

Em servidores compartilhados, ninguém apaga mais, por engano ou de propósito, o contexto de outra pessoa ou o contexto comum da equipe. Gravação e exclusão passam a obedecer à mesma fronteira de isolamento.

Ver o PR #1083 no GitHub

O problema

No OpenClaw, a captura funciona por um plugin que o próprio ai-memory gera e instala, e que envia cada uso de ferramenta no mesmo formato já usado pelo OpenCode: o nome da ferramenta, os dados de entrada, a saída e o erro. As regras de exclusão de caminhos já reconheciam suas leituras, edições e comandos, mas o OpenClaw não constava das listas de agentes cujas ferramentas recebem título e conteúdo estruturados. Assim, toda chamada era gravada com o nome do evento como título e corpo vazio, e o filtro que descarta chamadas pelo identificador não reconhecia o identificador enviado pelo plugin.

O que foi feito

O OpenClaw passou a ser lido com os mesmos campos do OpenCode e entrou nessas listas, e suas chamadas ganharam o mesmo título e conteúdo das do Claude Code: o tipo de ferramenta, a saída produzida e, quando houver, o erro. Como a documentação do OpenClaw trata o resultado e o erro como opcionais, a falta de erro não é registrada como sucesso: a chamada fica com desfecho desconhecido, e só um erro informado a marca como falha, sem repetir o comando. Testes no formato que o plugin envia conferem a saída, a falha, as exclusões de caminho e o descarte pelo identificador.

Valor entregue

Quem usa o OpenClaw passa a ter na memória o que cada ferramenta fez, e o registro não afirma que uma chamada deu certo quando o OpenClaw não disse isso.

Ver o PR #2131 no GitHub

O problema

O Devin CLI avisa o ai-memory antes e depois de cada uso de ferramenta e, depois da execução, manda a resposta num formato próprio: um indicador de sucesso, a saída e o erro. As regras de exclusão de caminhos já reconheciam suas leituras, edições e comandos, mas o Devin não constava das listas de agentes cujas ferramentas recebem título e conteúdo estruturados. Assim, toda chamada era gravada com o nome do evento como título e corpo vazio, e o filtro que descarta chamadas pelo identificador não reconhecia o identificador enviado. Mesmo com o conteúdo gravado, o desfecho ficaria como desconhecido, porque o indicador de sucesso não era lido.

O que foi feito

O Devin CLI entrou nessas listas, e suas chamadas passaram a ter o mesmo título e conteúdo das do Claude Code: o tipo de ferramenta, se deu certo ou não e a saída produzida. O desfecho vem do indicador de sucesso da resposta, como já acontecia com o Kiro CLI, e o conteúdo guarda só a saída ou, na falha, a mensagem de erro, sem o indicador solto no texto e sem repetir o comando. Testes com eventos no formato documentado do Devin conferem o sucesso, a falha e o descarte pelo identificador, com um caso de controle que mantém uma chamada comum.

Valor entregue

Quem usa o Devin CLI passa a ver na memória o que cada ferramenta fez e quais chamadas falharam, e a retomada e a consolidação de uma sessão ficam fiéis ao que aconteceu.

Ver o PR #2129 no GitHub

O problema

O Kimi Code avisa o ai-memory antes e depois de cada uso de ferramenta, com o nome da ferramenta, os dados de entrada e, no fim, a saída ou o erro. Ele já tinha esses avisos antes de o ai-memory criar as listas de agentes cujas ferramentas recebem título e conteúdo estruturados, e nunca foi incluído nelas. Por isso, toda leitura de arquivo, edição e comando do Kimi Code era gravada com o nome do evento como título e corpo vazio. As regras que excluem caminhos da captura também não reconheciam essas chamadas e nunca descartavam um evento de pasta excluída, e o filtro que descarta chamadas pelo identificador não encontrava o identificador que o Kimi Code envia.

O que foi feito

O Kimi Code entrou nessas listas, e suas chamadas passaram a ter o mesmo título e conteúdo das do Claude Code: o tipo de ferramenta, se deu certo ou não e a saída produzida. Uma falha, que o Kimi Code avisa num evento próprio, fica registrada como erro com a mensagem recebida, sem repetir o comando. Leituras, edições e comandos agora passam pelas regras de exclusão de caminhos, e o filtro por identificador reconhece tanto o identificador ao vivo quanto o das transcrições reconstruídas. Testes com eventos no formato documentado do Kimi Code mostram o descarte de uma leitura numa pasta excluída e a manutenção de uma leitura comum.

Valor entregue

Quem usa o Kimi Code passa a ter na memória o que foi feito na sessão, e não só o que foi pedido, com as pastas marcadas como excluídas fora do registro também para esse agente.

Ver o PR #2127 no GitHub

O problema

Ao monitorar tarefas executadas pelo assistente Cline, o servidor de memória intercepta o uso de comandos e leitura de arquivos para alimentar o contexto contínuo. Com a atualização das rotinas internas do ambiente para chamadas nativas em lote, as ferramentas deixavam de ser identificadas nas famílias reconhecidas pelo sistema. Por falta de enquadramento, os eventos eram gravados como ferramentas desconhecidas e o retorno das execuções era descartado, ocultando o trabalho realizado durante a sessão.

O que foi feito

O PR propõe mapear as operações nativas do Cline entre ferramentas de arquivo, listagem e comandos de terminal, suportando tanto o formato aninhado da interface de comandos quanto o envelope da extensão gráfica. A extração passa a coletar caminhos e linhas de execução para aplicar políticas de exclusão e preservar o identificador da chamada com seu desfecho de sucesso. Testes automatizados validam a classificação das operações, o respeito a regras de descarte e a captura integral dos registros de saída.

Valor entregue

Evita lacunas no histórico de sessões executadas com o assistente Cline e garante rastreabilidade completa das ações realizadas no projeto.

Ver o PR #1954 no GitHub

O problema

Diferente de chamadas a ferramentas, o OpenCode 2 armazena eventos de compactação de contexto em registros dedicados de mensagem. Como o leitor de histórico filtrava apenas falas de usuário e assistente, esses resumos consolidados eram descartados silenciosamente, sem gerar evento nem apontamento de perda. Assim, o contexto histórico perdia os resumos de conversas longas que haviam sido compactadas pelo assistente.

O que foi feito

O importador ganhou suporte ao tipo dedicado de compactação da sessão, registrando o resumo do turno como evento oficial ou o erro caso a operação tenha falhado. Processos ainda em andamento viram apontamentos de perda temporária e registros vazios são omitidos. Testes automatizados validam o fluxo completo de importação com eventos completados e falhos em banco de dados isolado.

Valor entregue

Mantém o histórico de contexto condensado disponível para outros assistentes continuarem o trabalho em projetos extensos.

Ver o PR #1826 no GitHub

O problema

Ao sincronizar conversas do OpenCode 2 com o histórico gerenciado de trabalho, execuções de ferramentas encerradas com erro tinham apenas a chamada registrada. A mensagem e a causa do erro eram descartadas e viravam apenas um aviso genérico de perda. Com isso, os agentes que assumiam a tarefa em sessões seguintes não sabiam por que determinado comando ou script havia falhado.

O que foi feito

O adaptador de transcrição passou a extrair o texto de erro visível em estruturas antigas e recentes de mensagens, registrando o resultado como retorno de ferramenta com sinalização explícita de erro nos metadados. Estados intermediários em execução continuam tratados como perdas parciais. Testes automatizados com banco de dados de teste confirmam a preservação de mensagens de erro sem alterar os registros nativos do assistente.

Valor entregue

Permite que agentes compreendam imediatamente falhas em comandos anteriores e evitem repetir tentativas inválidas ao retomar tarefas.

Ver o PR #1825 no GitHub

O problema

O ai-memory captura o histórico de comandos e sessões de agentes de IA para dar continuidade ao contexto entre diferentes ferramentas. O Codex possui um agente interno de consolidação de memória que roda em segundo plano e cujas atividades são descartadas pelo hook em tempo real para não poluir a base. Na importação de transcrições passadas, contudo, a verificação checava apenas a pasta atual da importação. Com isso, instalações com diretório de dados customizado tinham sessões de manutenção interna gravadas indevidamente como se fossem atividade técnica do usuário.

O que foi feito

O PR propõe adotar na importação de transcrições os mesmos três critérios do hook em tempo real: o diretório do checkout, o caminho registrado no próprio evento e a identificação do cabeçalho da mensagem de consolidação do Codex. Caso qualquer evento indique a rotina de manutenção, a sessão inteira é descartada antes de entrar no histórico. Testes automatizados cobrem o descarte pelo cabeçalho e pelo caminho registrado, garantindo que comandos normais e mensagens de outros agentes continuem preservados.

Valor entregue

Mantém a linha do tempo do projeto limpa de rotinas de manutenção interna de ferramentas ao importar históricos antigos.

Ver o PR #1793 no GitHub

O problema

O ai-memory registra o que acontece nas sessões dos agentes de programação por meio de comandos que cada agente executa em eventos como o início da sessão. Desde a versão 0.23.0, o Gemini CLI executa esses comandos no Windows pelo PowerShell, onde um caminho entre aspas no começo do comando é apenas um texto, e não um programa a executar. O comando falhava com erro de interpretação e saía com código 1, que o Gemini trata como erro sem bloqueio, então a sessão continuava normalmente, sem aviso e sem nada capturado.

O que foi feito

O PR faz o comando do Gemini CLI no Windows começar com o operador de chamada do PowerShell, como o ai-memory já fazia para o Codex, o Grok e o Copilot CLI; o Claude Code e os demais agentes não mudam. Dois testes novos cobrem a mudança: um confere o prefixo exato com espaços no caminho do programa e da pasta de dados, e o outro, no Windows, executa o comando gerado pelo PowerShell do jeito que o Gemini faz. Numa execução de teste no Windows, os dois falharam sem a correção, com o erro de interpretação, e passaram com ela, junto dos testes dos outros agentes. Instalações existentes recebem o comando novo ao rodar a instalação dos ganchos de novo, e as entradas antigas são substituídas, sem duplicar.

Valor entregue

Quem usa o Gemini CLI no Windows passa a ter as sessões registradas pelo ai-memory em vez de perder o histórico em silêncio.

Ver o PR #1485 no GitHub

O problema

O Crush registra na mesma lista as conversas principais e sessões auxiliares, como as de subagentes, que apontam para a conversa de origem. A descoberta de sessões já ignorava as auxiliares, mas a listagem usada por três funções não: a importação de histórico trazia uma sessão de subagente como sessão separada do projeto, o diagnóstico a contava e a retomada automática podia escolhê-la se fosse a mais recente.

O que foi feito

A listagem passou a ignorar as sessões que têm uma conversa de origem, o mesmo filtro que a descoberta já aplicava. O teste ganhou uma sessão de subagente mais recente que as principais, que não pode aparecer na lista, e falha sem a correção.

Valor entregue

Quem usa o Crush passa a ter um histórico sem sessões de subagente misturadas às conversas principais, e a retomada automática volta para a conversa principal em vez de cair numa sessão interna.

Ver o PR #1190 no GitHub

O problema

Para achar uma sessão pelo identificador, o ai-memory varria os arquivos de conversa do agente e lia no máximo os 2.000 primeiros, numa ordem arbitrária do disco. No Codex, no Pi, no OMP e no Grok, quem tinha mais de 2.000 conversas podia ter a sessão dada como inexistente. Ao abrir o agente pelo ai-memory, a sessão vinculada era então descartada e outra começava do zero, e a importação daquela conversa falhava.

O que foi feito

A busca passou a ler primeiro o arquivo cujo nome ou pasta contém o identificador da sessão, que é como esses agentes gravam, e depois os mais recentes. O limite de 2.000 continua, e cada candidato ainda é confirmado pelo cabeçalho, então um palpite errado custa só uma leitura. O teste usa 2.500 arquivos falsos com o arquivo certo no fim da lista.

Valor entregue

Quem usa muito esses agentes deixa de perder a continuidade de uma sessão só porque o histórico cresceu: retomar e importar encontram a conversa certa mesmo entre milhares de arquivos.

Ver o PR #1189 no GitHub

O problema

Os eventos de uso de ferramentas do Kiro CLI chegam ao ai-memory com o nome da ferramenta, os dados de entrada e, depois da execução, a resposta. As regras de captura já sabiam ler esse formato, mas o Kiro não constava da lista de agentes cujas ferramentas recebem título e conteúdo estruturados. Assim, toda chamada de ferramenta do Kiro era gravada com título genérico e corpo vazio, e a consolidação de uma sessão do Kiro só enxergava os pedidos.

O que foi feito

O Kiro CLI entrou nessa lista, e suas chamadas de ferramenta passaram a ter o mesmo título e conteúdo das do Claude Code: o tipo de ferramenta, se deu certo ou não e a saída produzida. As regras que excluem caminhos da captura continuam valendo como antes. Um teste novo usa eventos no formato real do Kiro, nas duas versões do seu motor, e falha sem a mudança.

Valor entregue

Quem usa o Kiro CLI passa a ter na memória o que foi feito na sessão, e não só o que foi pedido. O conhecimento consolidado dessas sessões passa a considerar também o trabalho das ferramentas.

Ver o PR #1187 no GitHub

O problema

Ao iniciar, o Pi avisa o servidor do ai-memory de que a conexão está pronta. A extensão gerada pelo ai-memory mandava esse aviso como se fosse um pedido à espera de resposta, com número de identificação. O servidor não o reconhecia, respondia com erro de "método não encontrado" e registrava um alerta no log a cada abertura do Pi, enquanto a extensão ignorava o erro e seguia.

O que foi feito

O gerador da extensão passou a enviar o aviso no formato próprio de avisos, sem identificação e sem esperar conteúdo de volta, aceitando a resposta vazia de sucesso. Testes conferem a extensão gerada e mostram que o servidor aceita o aviso correto e continua recusando o formato antigo. Como a correção está no gerador, reinstalar a integração não traz o problema de volta.

Valor entregue

Quem usa o Pi com o ai-memory deixa de ver um alerta de erro falso no log do servidor a cada inicialização. E o servidor passa a receber o aviso de forma válida, o que antes não acontecia nunca.

Ver o PR #1137 no GitHub

O problema

O OpenCode 2 descarrega e recarrega plugins durante o uso normal, sempre que libera serviços ociosos, e a cada descarga o plugin do ai-memory declarava encerradas todas as sessões em andamento. A sessão ficava congelada, deixava de registrar o progresso de cada turno e ganhava um resumo e um bastão falsos. No caso relatado, uma única sessão ativa foi encerrada 13 vezes num dia, com 16 bastões, e a entrega seguinte falhava.

O que foi feito

O plugin gerado deixa de encerrar sessões quando é descarregado. O fim da sessão passa a vir só da exclusão real da sessão, e o resumo e o bastão de cada turno concluído continuam sendo publicados ao fim do turno, então um desligamento abrupto não perde nada. Instalações existentes precisam gerar o plugin de novo com o comando de instalação.

Valor entregue

Quem usa o ai-memory com o OpenCode 2 mantém sessões contínuas e uma passagem de bastão confiável, sem páginas e bastões duplicados nem uma consolidação com modelo de linguagem a cada encerramento que não aconteceu.

Ver o PR #1081 no GitHub

O problema

Cada sessão encerrada gerava um bastão pendente, injetado no início da sessão seguinte. Para quem trabalha sozinho e emenda sessões no mesmo projeto, isso virava ruído, porque a sessão anterior era a própria pessoa minutos antes. Não havia como desligar sem perder também a página de resumo da sessão, e num relato mais de 60 bastões tinham se acumulado antes de uma limpeza manual.

O que foi feito

Uma nova configuração, válida para todo o servidor, desliga a criação automática do bastão no fim da sessão. O padrão continua ligado, então nada muda para quem não mexer. Com a opção desligada, o resumo da sessão e a consolidação em segundo plano seguem normais, e os bastões criados de propósito pelo agente ou por execuções gerenciadas não são afetados.

Valor entregue

Quem trabalha sozinho deixa de receber contexto repetido a cada sessão e de acumular bastões para limpar, sem abrir mão do histórico. Quem depende da passagem de bastão entre agentes mantém o comportamento atual.

Ver o PR #1063 no GitHub

O problema

A ferramenta que entrega o bastão respondia "nada" em duas situações diferentes: quando não havia bastão pendente e quando ele já tinha sido injetado no contexto pelo início automático da sessão. O modelo não tinha como distinguir os casos pela resposta, e as instruções precisavam de um parágrafo de avisos para que o agente não concluísse que não havia trabalho anterior a retomar.

O que foi feito

A resposta ganhou um campo de situação: entregue agora, já entregue no início da sessão ou nada pendente. O "já entregue" só é informado à própria sessão que recebeu o bastão, no mesmo projeto, do mesmo dono e ainda ativa; identificadores forjados, outros projetos e sessões irmãs ou encerradas recebem "nada pendente". Testes novos falham se qualquer uma dessas travas for removida, e o campo antigo continua igual para os clientes existentes.

Valor entregue

O agente deixa de adivinhar: sabe se deve usar o contexto que já recebeu ou seguir sem bastão, com menos risco de concluir que não há trabalho anterior. A informação nova não abre brecha, porque nenhuma sessão descobre o bastão de outra.

Ver o PR #990 no GitHub

O problema

Alguns agentes, como Grok e Zero, não recebem o bastão que o ai-memory injeta automaticamente no início da sessão. Para eles, a única forma de ver um bastão pendente era aceitá-lo, o que o consome, já que cada bastão vale uma única vez. O agente acabava assumindo sempre o mais recente, sem conferir o conteúdo nem poder escolher outro.

O que foi feito

Uma nova ferramenta, só de leitura, lista os bastões abertos do projeto com resumo, perguntas em aberto, próximos passos e arquivos envolvidos, sem mudar o estado de nenhum. Em seguida o agente assume exatamente o bastão escolhido, uma única vez. A listagem segue as regras de dono da entrega: bastões privados de outros usuários ficam ocultos e ver todos exige permissão de administrador.

Valor entregue

Agentes sem integração de início de sessão passam a retomar o trabalho escolhendo o contexto certo, em vez de consumir às cegas o mais recente. O isolamento entre usuários foi preservado, como confirmou a revisão do mantenedor, e nada muda para os demais agentes.

Ver o PR #664 no GitHub

O problema

Ao concluir a mesclagem de projetos, o servidor excluía o projeto de origem, mas as configurações armazenadas no cliente local continuavam referenciando o identificador antigo. Com isso, execuções de comandos a partir daquela pasta de trabalho enviavam um projeto inexistente, resultando em erros 404 e interrompendo o fluxo das sessões. Além disso, o relatório da operação informava apenas os nomes dos projetos sem seus identificadores numéricos, impedindo a atualização automática quando o comando era disparado por nome.

O que foi feito

Diferente da preservação da identidade no banco feita no servidor, este ajuste atua no cliente: após a confirmação da mesclagem, o comando transfere os vínculos locais e as associações do checkout para o projeto de destino. A resposta da API passou a incluir os identificadores de origem e destino calculados pelo servidor, permitindo atualizar o registro local mesmo quando a mesclagem é invocada por nome. Novos testes automatizados conferem o redirecionamento dos vínculos com identificadores do relatório ou informados na chamada.

Valor entregue

O operador e as sessões locais continuam trabalhando imediatamente após a mesclagem, sem necessidade de reconfigurar vínculos manuais ou reiniciar o ambiente.

Ver o PR #2159 no GitHub

O problema

Quando dois projetos eram unificados pela rotina de mesclagem, as informações de identidade do repositório e os nomes derivados ficavam apenas no registro de origem, que era excluído ao final da operação. Como apenas o modo de acesso e as preferências de perfil eram transferidos, o repositório ficava sem correspondência no espaço de trabalho. Na sessão seguinte, o mecanismo de resolução não encontrava o projeto consolidado e abria um novo projeto paralelo com configurações padrão.

O que foi feito

A rotina de mesclagem passou a consultar a identidade, a origem da identidade, o nome canônico e o nome legado do projeto de origem antes de sua exclusão, aplicando esses dados ao destino se ele estiver sem identidade configurada. Caso o destino já tenha sua própria identidade, ela é mantida intacta, respeitando o princípio de um projeto por repositório. Um novo teste automatizado valida que a simulação não altera os dados, que a confirmação transfere as coordenadas e que a busca pelo repositório localiza o projeto sobrevivente.

Valor entregue

Projetos unificados continuam sendo reconhecidos automaticamente pelas sessões dos agentes, evitando duplicação de históricos e falhas de localização.

Ver o PR #2157 no GitHub

O problema

O comando de status do ai-memory consulta o servidor para mostrar a saúde da instalação e, quando não obtém resposta, exibe a fila de eventos guardada no disco e as instruções de recuperação. Qualquer falha nessa consulta era tratada como servidor fora do ar, inclusive as recusas de acesso. Num servidor remoto ou multiusuário, a consulta exige credencial e permissão de administrador: sem credencial, o servidor responde que o pedido não foi autenticado, e um usuário comum recebe acesso proibido. Nos dois casos o servidor estava no ar e respondeu na hora, mas o comando o declarava inacessível e mandava religá-lo, o que levava a procurar uma pane de rede ou de processo que não existia.

O que foi feito

O comando passou a separar a falha de conexão da resposta de erro enviada pelo servidor. Quando o servidor responde, a fila local e as dicas de recuperação aparecem sem o rótulo de servidor inacessível, e o erro informa que o servidor foi alcançado e o que faltou: a credencial, com os lugares onde o comando procura o token, ou a permissão de administrador; para qualquer outro erro, mostra o código recebido. A falha de conexão continua com as mensagens de antes, e testes com um servidor local que recusa o pedido sem credencial e sem permissão confirmam que o comando não fala mais em servidor inacessível.

Valor entregue

Quem opera um servidor remoto ou compartilhado vai direto à causa real, credencial ausente ou falta de permissão, em vez de investigar uma queda que não aconteceu.

Ver o PR #2123 no GitHub

O problema

Quando dois projetos eram combinados no repositório de memória, o processo de migração copiava apenas parte das informações das chaves de ingestão. Os identificadores de sessão, o tipo de agente e os indicadores de retenção para recuperação eram zerados no projeto de destino. Com isso, a rotina periódica de limpeza apagava essas chaves após uma hora e qualquer tentativa de reproduzir o histórico de eventos falhava por conflito de sessão.

O que foi feito

O PR propõe copiar todos os atributos das chaves de ingestão durante a fusão, preenchendo campos ausentes em registros coincidentes e preservando a prioridade de retenção para recuperação. Um teste de regressão automatizado valida a permanência dos dados e a resolução correta de conflitos entre projetos.

Valor entregue

Projetos combinados mantêm a integridade de todas as sessões anteriores e continuam permitindo recuperar históricos sem erros de consistência.

Ver o PR #2062 no GitHub

O problema

O ai-memory registra o consumo de tokens de cada sessão no painel de uso e no livro de respostas. No Claude Code, a conversa principal fica numa transcrição e cada subagente grava as próprias respostas em outro arquivo, ao lado da sessão. A captura lia só a transcrição principal, então o trabalho dos subagentes não chegava aos totais nem ao livro em tempo real. Em sessões que delegam bastante, boa parte dos tokens ficava invisível.

O que foi feito

O PR propõe somar as transcrições dos subagentes ao total de encerramento da sessão e, no caminho ao vivo, anexá-las a um lote que já tenha uma resposta da conversa principal, cada uma com o próprio cursor e dentro do teto de respostas por evento. Respostas de subagente não viajam no evento do próprio subagente, para o modelo da sessão continuar sendo o da conversa principal. Testes automatizados conferem a soma com deduplicação, o lote ao vivo ao lado de uma resposta principal e o respeito ao teto por evento.

Valor entregue

Quem consulta o painel de tokens vê o consumo real da sessão, inclusive o trabalho delegado a subagentes, e deixa de subestimar o custo dessas execuções.

Ver o PR #2033 no GitHub

O problema

Durante a consolidação de notas e histórico de sessões, a ferramenta consulta provedores de inteligência artificial para resumir o conhecimento registrado. Ao atingir limites temporários de requisições, o mecanismo de repetição aguardava apenas dois segundos fixos antes de tentar novamente, desconsiderando a janela indicada pelo serviço no cabeçalho de resposta. Quando o provedor estipulava prazos maiores, as três tentativas da rotina se esgotavam em poucos segundos, cancelando a consolidação e deixando anotações da sessão fora da base.

O que foi feito

O PR propõe adotar o tempo de espera informado pelo provedor antes de disparar novas tentativas de consolidação, com teto de segurança de trinta e dois segundos para evitar bloqueios prolongados. Na ausência de orientação específica, o intervalo padrão de dois segundos permanece em uso. Testes automatizados verificam o cumprimento de esperas parciais, o limite máximo permitido e o sucesso das chamadas na rodada seguinte.

Valor entregue

Garante a gravação confiável do histórico de sessões em momentos de alta demanda nas APIs e evita a perda de registros por esgotamento precoce de tentativas.

Ver o PR #1929 no GitHub

O problema

Ao atualizar para a versão 3.0, a ferramenta adota automaticamente projetos anteriores assim que uma sessão captura a identidade do repositório pela primeira vez. No entanto, quando um desenvolvedor inicia o trabalho em uma árvore vinculada do git, o caminho diferente da pasta impedia o reconhecimento do projeto legado. Com isso, o sistema criava um projeto novo em paralelo e deixava o histórico de conversas e anotações originais inacessível.

O que foi feito

O PR propõe consultar os metadados do repositório compartilhado para identificar o diretório principal da árvore de trabalho e herdar o projeto correspondente. A rotina preserva identificadores, páginas e permissões existentes sem criar registros duplicados na base. Testes automatizados confirmam o vínculo a partir de ramificações do git e garantem que escopos reservados continuem protegidos contra adoção indevida.

Valor entregue

Evita a perda de contexto histórico e a criação de projetos órfãos quando equipes trabalham com múltiplas árvores vinculadas no mesmo repositório.

Ver o PR #1884 no GitHub

O problema

A versão 3.3.0 da ferramenta introduziu configurações para controle de tempo de ranqueamento, limite de contexto em sínteses, menu de encerramento de sessão e avaliador interno de propostas. No entanto, o arquivo de modelo gerado na instalação e o guia de propriedades omitiram essas quatro opções e suas variáveis de ambiente equivalentes. Quem consultava o modelo ou a documentação para personalizar o servidor não encontrava as configurações disponíveis.

O que foi feito

O arquivo de modelo padrão e o manual de propriedades passaram a documentar os quatro parâmetros com valores padrão, limites operacionais e variáveis de ambiente correspondentes. As orientações detalham o tempo limite de reordenação de consultas, o orçamento de contexto para respostas com inteligência artificial, o menu interativo de saída e o avaliador estrutural interno.

Valor entregue

Facilita o ajuste fino de memória, consultas e sessões interativas sem exigir inspeção do código fonte para descobrir configurações suportadas.

Ver o PR #1862 no GitHub

O problema

O script do PowerShell empacota e repassa os comandos da aplicação para contêineres no Windows, e a suíte de testes verifica esse repasse em ambientes sem programas instalados no sistema. Uma alteração no instalador fez a rotina buscar diretamente o executável nativo do sistema quando nenhuma opção de plataforma era informada. Sem esse executável na máquina de teste, a checagem falhava com erro de arquivo não encontrado e travava a esteira de validação contínua no Windows.

O que foi feito

A rotina de testes do PowerShell passou a definir explicitamente a variável de ambiente que preserva a execução por contêiner no Windows, no mesmo padrão já utilizado nos testes para sistemas Unix. Isso impede que o teste procure executáveis ausentes no hospedeiro e garante a verificação correta dos argumentos do comando. Com a mudança, os testes automatizados voltam a passar na esteira de integração do projeto.

Valor entregue

Restaura a aprovação da integração contínua em máquinas Windows e assegura a confiabilidade dos scripts de inicialização para os usuários da plataforma.

Ver o PR #1670 no GitHub

O problema

Ao iniciar o banco de dados após uma atualização, a rotina de reparo cria índices especializados de busca textual para conteúdos em idiomas asiáticos. A cada lote de registros, a consulta começava a conferência desde o primeiro identificador da tabela, o que forçava a checagem repetida de todos os itens já indexados nos lotes anteriores. Em bases com milhares de páginas e mais de um milhão de observações, esse comportamento quadrático degradava a inicialização e mantinha o servidor indisponível por horas.

O que foi feito

O PR propõe que cada lote consulte apenas os registros posteriores ao último identificador já concluído, avançando com um cursor direto na tabela. Testes unitários com contador de passos do SQLite comprovam que o esforço computacional passa a crescer de forma proporcional ao número de registros.

Valor entregue

Reduz o tempo de inicialização pós-atualização de horas para poucos minutos em bases de dados extensas de grandes times.

Ver o PR #1662 no GitHub

O problema

Ao listar usuários ou chaves de API pela linha de comando, a ferramenta calculava o espaçamento das colunas contando a quantidade bruta de bytes em vez da largura visual que o texto ocupa na tela. Como caracteres com acento ocupam mais bytes que letras comuns e ideogramas ocupam a largura de duas letras no terminal, qualquer nome com caracteres especiais empurrava as colunas seguintes para a direita, entortando a tabela e dificultando a leitura dos dados de acesso.

O que foi feito

As funções de formatação das duas listagens passaram a medir o tamanho de cada texto com base na largura visual ocupada no terminal e a aplicar preenchimento proporcional de espaços. Novos testes automatizados conferem que tabelas contendo nomes acentuados e caracteres de largura dupla mantêm as colunas perfeitamente alinhadas com os cabeçalhos.

Valor entregue

Garante listagens claras e visualmente legíveis no terminal para administradores que gerenciam usuários e chaves em diferentes idiomas.

Ver o PR #1626 no GitHub

O problema

Em servidores com políticas de segurança reforçadas, como as recomendações do CIS Linux, a pasta temporária do sistema costuma ser montada com a opção que proíbe a execução direta de programas. O script de instalação do ai-memory baixava o binário e executava um teste de fumaça preliminar ainda dentro dessa pasta temporária, antes de movê-lo para a pasta definitiva na biblioteca do usuário. Nesses ambientes, o sistema bloqueava a execução com erro de permissão e o instalador abortava o processo, mesmo com o binário sendo compatível e capaz de rodar perfeitamente na pasta de instalação.

O que foi feito

O script de instalação passou a preparar o binário em uma pasta temporária ao lado do diretório final de destino antes de executar o comando de teste. Se a validação falhar nessa etapa, a cópia de preparação é removida imediatamente e a mensagem de erro passa a indicar a pasta exata da verificação. Uma nova bateria de testes automatizados na integração contínua simula a instalação sob diretórios restritos e valida que binários defeituosos continuam sendo rejeitados sem deixar arquivos residuais.

Valor entregue

Permite a instalação automatizada e confiável do ai-memory em servidores corporativos e ambientes com regras estritas de segurança em disco.

Ver o PR #1624 no GitHub

O problema

No Windows, o PATH do usuário é a lista de pastas onde o sistema procura programas, e o próprio Windows o grava num formato que aceita variáveis, como a da pasta do perfil do usuário; ferramentas de desenvolvimento acrescentam entradas do mesmo tipo, como a pasta do Java indicada pela variável JAVA_HOME. O instalador do ai-memory lia esse valor pela função padrão do .NET, que já devolve as variáveis trocadas pelo valor do momento, e gravava de volta pela função equivalente, que salva tudo como texto simples. Assim, cada instalação congelava as variáveis, e trocar a versão do Java depois não mudava mais o PATH. Uma entrada cuja variável o instalador não conhecia era gravada ao pé da letra, com o nome da variável entre sinais de porcentagem, num formato em que o Windows nunca a expande, e aquela pasta saía do PATH. O aplicativo de desktop e os dois passos manuais da documentação do Windows faziam o mesmo.

O que foi feito

O instalador passou a ler o valor bruto, sem expandir as variáveis, acrescentar a sua pasta e gravar de volta no formato que aceita variáveis, como já fazem os instaladores do Bun, do Scoop e do pixi e os gerados pelo cargo-dist. A conferência de que a pasta já está no PATH continua usando os valores expandidos, então uma entrada que aponta para ela por meio de uma variável ainda conta como presente, e o aviso que faz o Explorer e os terminais abertos por ele enxergarem o PATH novo continua sendo enviado, sem gravar nada além do PATH. O aplicativo de desktop e os dois passos manuais da documentação receberam a mesma mudança. Um caso de teste novo, que só roda na integração contínua por mexer no PATH real, monta um PATH com uma variável, instala no PowerShell 7 e no Windows PowerShell 5.1, exige o formato e a variável intactos e devolve o valor original no fim. Numa execução de teste no Windows, sem a correção, o teste parou com o PATH gravado como texto simples e o script do aplicativo de desktop perdeu a variável; com ela, os dois preservaram o formato e a variável, e a integração contínua do projeto passou no Windows.

Valor entregue

Quem instala o ai-memory no Windows mantém o PATH como estava, com as variáveis funcionando e nenhuma pasta perdida, em vez de descobrir depois que outra ferramenta deixou de ser encontrada.

Ver o PR #1510 no GitHub

O problema

O arquivo de configuração que o ai-memory gera ao ser inicializado traz as opções desligadas como exemplos comentados, para quem opera o servidor ativar só o que precisa; é o mesmo arquivo que os pacotes RPM e AUR instalam e que o pacote Nix distribui. Dois desses exemplos são seções, a de variáveis de ambiente de um perfil de execução (desde a versão 2.6.0) e a de descarte de eventos de ferramentas no servidor (desde a 3.0.0), e ficavam acima de opções gerais. Num arquivo TOML, o cabeçalho de uma seção vale para todas as linhas até o próximo cabeçalho, então quem ativava uma dessas seções e depois uma opção geral mais abaixo colocava essa opção dentro da seção. Na seção de descarte, a reordenação dos resultados de busca por um modelo de linguagem e o ajuste que impede o OpenCode com modelos Gemini de falhar ao listar as ferramentas eram ignorados sem nenhum aviso. Na seção do perfil, um número ou um valor verdadeiro/falso, como o limite de eventos por segundo, impedia a configuração de carregar, e um texto virava variável de ambiente de toda execução com aquele perfil.

O que foi feito

O PR move os dois exemplos, com o texto intacto, para depois das opções gerais e acrescenta uma nota explicando por que exemplos de seção ficam abaixo da primeira seção real, no mesmo estilo do aviso que já protegia o fim do arquivo. Um teste novo confere que nenhum exemplo de seção volta a ficar acima da primeira seção real; depois ativa todos os exemplos de uma linha e verifica que o arquivo carrega com cada opção onde a documentação indica: a reordenação nas opções gerais, o perfil só com as suas duas variáveis e as duas listas de descarte preenchidas. A integração contínua do projeto passou com a mudança. Quem deixa os exemplos comentados não nota diferença, porque só linhas de comentário mudaram de lugar, e arquivos já existentes não são reescritos; a nota de versão explica como corrigir um à mão.

Valor entregue

Quem ajusta o ai-memory pelo arquivo de configuração tem cada opção ativada valendo onde a documentação indica, sem opção descartada em silêncio nem configuração que deixa de carregar.

Ver o PR #1507 no GitHub

O problema

O instalador para Windows baixa a versão, extrai numa pasta temporária, executa o programa uma vez para conferir a versão e então move a pasta para o destino. Nesse intervalo, um antivírus costuma estar analisando o arquivo que acabou de rodar e o mantém aberto de um jeito que permite ler, mas não renomear nem apagar. Mover exige justamente apagar o original, então o Windows recusava com o aviso de arquivo em uso, e o script parava com a pasta de destino criada, mas sem o programa.

O que foi feito

O instalador passou a copiar a pasta em vez de movê-la, já que copiar só lê os arquivos e a leitura é permitida. Se a cópia falhar no meio, a pasta parcial é removida antes de o erro ser exibido, para que a próxima execução não a confunda com uma instalação existente; a pasta temporária continua sendo limpa ao final, em melhor esforço. Um caso de teste novo mantém o programa aberto da mesma forma que um antivírus, no PowerShell 7 e no Windows PowerShell 5.1, e só passa se a trava realmente ocorrer. Antes da correção, o mesmo teste reproduziu o erro do relato nos dois ambientes; com ela, a instalação conclui nos dois.

Valor entregue

Quem instala o ai-memory no Windows com antivírus ativo deixa de ficar com uma instalação pela metade e uma mensagem de erro difícil de entender.

Ver o PR #1481 no GitHub

O problema

A ferramenta de consulta do ai-memory é a porta pela qual agentes de IA buscam o que o projeto já registrou, e aceita opções que não podem ser combinadas: o modo global com projeto ou escopos, escopos com projeto, uma consulta numa data passada com escopos e uma data passada que não seja um instante válido. Todas essas situações são decididas só pelos argumentos, antes de qualquer acesso ao armazenamento, mas eram respondidas com o código de erro interno do servidor. Um cliente lê esse código como falha do servidor e tenta de novo em vez de corrigir o pedido, então uma chamada malformada era repetida sem chance de dar certo.

O que foi feito

As quatro rejeições passaram a devolver o código de argumentos inválidos, o mesmo que as ferramentas irmãs de gravação e exclusão de páginas já usavam, e as mensagens continuam iguais. Falhas reais do servidor, como um erro do armazenamento, seguem com o código interno. Um teste novo cobre cada uma dessas situações e confirma que uma consulta bem formada não é rejeitada.

Valor entregue

Quem integra o ai-memory a outras ferramentas passa a distinguir um pedido errado de uma falha do servidor e deixa de repetir chamadas que nunca teriam sucesso.

Ver o PR #1469 no GitHub

O problema

O ai-memory transforma cada anotação em um vetor numérico, que permite buscar por sentido e não só por palavras, usando um provedor externo escolhido pelo usuário. As integrações com Google, Copilot e Voyage tratavam qualquer sobrecarga passageira como erro definitivo: Google e Copilot repetiam apenas o aviso de limite de uso, e a Voyage não repetia nada. Com um deles configurado, uma sobrecarga breve fazia falhar páginas do preenchimento em lote, deixava páginas gravadas sem vetor até o próximo preenchimento e tirava a busca por sentido daquela consulta, que seguia só com as demais formas de busca.

O que foi feito

As três integrações passaram a seguir a política que os provedores no padrão OpenAI já usavam: repetir tanto o limite de uso quanto a indisponibilidade, respeitar a espera pedida pelo servidor (até 32 s por tentativa), usar esperas crescentes de 2 a 32 s quando não há pedido e desistir, informando o último erro, quando o total de esperas passaria de 62 s. Sem pedido do servidor, Google e Copilot esperam exatamente o que esperavam antes diante de um limite de uso. Sete testes novos simulam o servidor e conferem, por exemplo, que duas indisponibilidades seguidas de um sucesso levam exatamente três requisições e que uma indisponibilidade sem fim termina em falha após seis.

Valor entregue

Uma sobrecarga momentânea do provedor deixa de resultar em memórias sem vetor e consultas com resultado mais pobre, dentro do mesmo limite de espera dos demais provedores.

Ver o PR #1467 no GitHub

O problema

Na suíte de testes de linha de comando, a simulação do servidor de download de backup configurava o receptor de conexões TCP em modo não bloqueante. No Windows, conexões aceitas herdam esse comportamento, fazendo com que leituras imediatas falhassem com erro de operação bloqueante caso os dados ainda estivessem em trânsito.

O que foi feito

O teste passou a restaurar expressamente o modo síncrono logo após aceitar a conexão TCP, adotando o mesmo padrão já consolidado nos demais testes de rede do projeto. A leitura segue protegida por tempo limite para evitar travamentos indefinidos.

Valor entregue

Garante estabilidade na validação contínua e evita alarmes falsos nos testes automatizados em ambientes Windows.

Ver o PR #1424 no GitHub

O problema

Para obter respostas num formato estruturado, o ai-memory obriga o modelo Claude a responder por uma ferramenta com o formato esperado. O Opus 5.5, o Sonnet 5.5, o Fable 5.1 e o Mythos 5.1 recusam essa obrigação com erro, e assim toda tarefa estruturada falhava antes de chegar ao modelo: consolidação, auditoria da wiki, melhoria automática e respostas da busca na memória, entre outras. Quem usava esses modelos, direto ou pelo catálogo do OpenCode, ficava sem todas elas.

O que foi feito

Nesses quatro modelos, o pedido passou a deixar a escolha da ferramenta no automático, e a descrição da ferramenta pede ao modelo que a use. Se o modelo responder com o resultado em texto, o ai-memory extrai o objeto do texto, esteja ele sozinho, num bloco de código ou no meio de uma frase. Os demais modelos continuam com o pedido de antes, e testes novos conferem o pedido enviado a cada modelo e a leitura das respostas em texto.

Valor entregue

Quem adota os modelos Claude mais recentes, direto ou pelo OpenCode, passa a contar com consolidação, auditoria e melhoria automática, e os modelos anteriores seguem com a mesma exigência de formato.

Ver o PR #1328 no GitHub

O problema

O ai-memory permite escolher quanto o modelo de linguagem raciocina, e a própria documentação recomendava desligar o raciocínio para que pensamentos ocultos não consumissem o espaço da resposta estruturada. Para isso, o ai-memory enviava a opção de raciocínio desativado, que o Claude Opus 5.5 e o Sonnet 5.5 recusam com erro em qualquer nível. Com esses modelos, inclusive pelo catálogo do OpenCode, toda consolidação, auditoria e exploração da memória falhava.

O que foi feito

O Opus 5.5, que não permite desligar o raciocínio, passou a receber o pedido sem essa opção, como já acontecia com o Fable e o Mythos. O Sonnet 5.5 passou a receber o ajuste mínimo que ele oferece para dispensar o raciocínio estendido. Os demais modelos e níveis seguem com o mesmo pedido de antes, e a documentação de instalação passou a citar os dois modelos; testes novos cobrem cada combinação, inclusive o identificador do Opus 5.5 no Bedrock.

Valor entregue

Quem seguiu a recomendação da documentação e usa os modelos Claude mais recentes volta a ter consolidação, auditoria e exploração funcionando, sem precisar trocar de modelo nem de configuração.

Ver o PR #1326 no GitHub

O problema

O ai-memory usa um modelo de linguagem em recursos como a exploração da memória e o teste de conexão com o provedor. Os modelos Claude mais novos, como Opus 5, Sonnet 5 e Haiku 5.5, podem raciocinar antes de responder mesmo sem pedido, e o Opus e o Sonnet a partir da 4.6 fazem isso quando se configura um nível de esforço; a resposta então começa com blocos de raciocínio. O leitor das respostas só conhecia texto e chamada de ferramenta, e qualquer outro bloco derrubava a chamada inteira.

O que foi feito

O leitor passou a aceitar e ignorar qualquer tipo de bloco que não usa, em vez de enumerar só os de raciocínio, para que um tipo novo não volte a quebrar todas as chamadas. O texto continua montado só a partir dos blocos de texto, e o resultado estruturado segue validado como antes. Um teste novo simula uma resposta com raciocínio, raciocínio oculto, texto e chamada de ferramenta e confere os dois caminhos de leitura.

Valor entregue

Quem usa o ai-memory com os modelos Claude mais recentes, direto ou pelo OpenCode, ou com um nível de esforço configurado, deixa de ver a exploração da memória e o teste do provedor falharem assim que o modelo raciocina.

Ver o PR #1325 no GitHub

O problema

O ai-memory permite mover uma sessão para outro projeto, levando junto suas observações, bastões e tarefas de consolidação. Duas coisas ficavam para trás: as frases com cara de preferência colhidas dos pedidos da sessão para o perfil do usuário e as chaves que impedem gravar o mesmo evento duas vezes e permitem retomar um evento interrompido. Assim, o perfil contava essas preferências no projeto errado, e expurgar o projeto antigo apagava dados de uma sessão que já pertencia a outro.

O que foi feito

Mover uma sessão passou a transferir também essas frases e chaves, na mesma transação que move o resto; quando o destino já tem um registro igual, ele é mantido e a duplicata é apagada. Frases vindas de páginas e chaves sem sessão continuam no projeto de origem, porque não pertencem à sessão. Os testes conferem que só os dados da sessão movida mudam de lugar e que eles sobrevivem a um expurgo posterior do projeto antigo.

Valor entregue

Quem reorganiza sessões entre projetos não perde mais, num expurgo posterior, as preferências colhidas delas, e o perfil passa a contar cada preferência no projeto certo.

Ver o PR #1265 no GitHub

O problema

A documentação diz que mudar um projeto de workspace atualiza todos os seus dados, mas a operação deixava sete tipos de dado para trás e ainda informava sucesso. Depois da mudança, mensagens pendentes entre projetos deixavam de ser encontradas, o projeto perdia uma das fontes da busca e os apontamentos em aberto sobre suas páginas, uma sessão expurgada podia ser recriada por um evento atrasado e a coleta do perfil recomeçava, gravando as mesmas evidências de novo.

O que foi feito

A mudança passou a atualizar os sete tipos de dado que faltavam, na mesma operação e com o mesmo critério dos demais, incluindo as duas pontas de cada mensagem. A documentação agora lista o que é atualizado. O teste novo põe um registro de cada tipo, move o projeto, confere que todos seguem para o destino e falha sem a correção.

Valor entregue

Reorganizar projetos entre workspaces deixa de perder em silêncio mensagens, dados de busca e apontamentos pendentes, e deixa de reabrir a porta para sessões que já tinham sido expurgadas.

Ver o PR #1196 no GitHub

O problema

Ao contrário do cliente nativo e dos scripts de captura, as integrações para OpenCode (nas duas versões), OMP, Pi e OpenClaw tratavam como recusa definitiva as respostas de "tente mais tarde" do servidor sobrecarregado. O evento não era guardado nem reenviado, e se perdia justamente quando o servidor pedia nova tentativa. Pior: o envio da fila local apagava cada evento guardado que encontrasse nessa situação, até 500, numa fila compartilhada com o cliente nativo.

O que foi feito

As três respostas que significam "tente mais tarde" passaram a ser tratadas como falha temporária do servidor: o evento vai para a fila local, e o envio da fila se interrompe, mantendo o que está guardado. A regra fica numa única função compartilhada, para que os três pontos que a usam não possam divergir. A documentação, que dizia que esses erros nunca são reenviados, foi corrigida.

Valor entregue

Quem usa esses agentes deixa de perder registros de sessão nos momentos de carga, e a fila mantida pelo cliente nativo não é mais apagada pelo plugin. O critério passa a ser o mesmo dos scripts de captura, e basta reinstalar a integração do agente para receber a correção.

Ver o PR #1188 no GitHub

O problema

O instalador sem Docker mantém à mão a lista de scripts de cada agente, e as listas tinham se afastado do que os pacotes publicados contêm. Para o Antigravity CLI, apresentado como suportado na documentação, ele pedia sete scripts quando o pacote tem quatro, e a instalação sempre parava com erro. Para Claude Code e Grok, os dois scripts que registram início e fim de subagentes nunca eram instalados, embora a configuração gerada apontasse para eles.

O que foi feito

O instalador passou a instalar exatamente os scripts que cada pacote traz: uma lista própria de quatro scripts para o Antigravity CLI e os dois scripts de subagentes para Claude Code e Grok. Um teste novo alimenta o instalador com os nomes reais dos arquivos de cada um dos nove agentes baseados em scripts e exige que o conjunto instalado seja igual ao publicado.

Valor entregue

A instalação sem Docker passa a funcionar para o Antigravity CLI e fica completa para Claude Code e Grok, incluindo os eventos de subagentes. O teste novo acusa qualquer nova divergência entre as listas e os pacotes.

Ver o PR #1185 no GitHub

O problema

Para quem não usa Docker, há um instalador que copia, da versão publicada, os scripts de captura de cada agente. Todos esses scripts começam carregando um arquivo de apoio compartilhado, que o instalador nunca copiava. Depois da instalação, cada script parava logo no início e nada chegava ao servidor, e rodar em seguida o comando de instalação do próprio ai-memory também não resolvia.

O que foi feito

O instalador passou a extrair o arquivo de apoio do mesmo pacote verificado da versão publicada e a colocá-lo onde os scripts já o procuram. Se o pacote não tiver o arquivo, a instalação é interrompida com erro em vez de deixar uma configuração quebrada, como já acontecia com um script ausente. O teste do instalador passou a exigir o arquivo e falha sem a correção.

Valor entregue

Quem instala a captura sem Docker passa a ter registros chegando ao servidor desde o primeiro uso, em vez de uma instalação que termina sem erro e não grava nada.

Ver o PR #1184 no GitHub

O problema

Sobrecarregado, o servidor do ai-memory responde, de propósito, "muitas requisições, tente mais tarde"; respostas de pedido que demorou demais ou chegou cedo demais pedem o mesmo. Os scripts de captura para macOS e Linux e a versão para PowerShell, no Windows, tratavam essas respostas como recusa definitiva. O evento era descartado em vez de ir para a fila local no disco, e o envio da fila apagava os eventos guardados ao receber essa resposta.

O que foi feito

As três respostas passaram a ser tratadas como temporárias nos dois conjuntos de scripts: o evento vai para a fila local, e o envio da fila pausa e mantém tudo para a próxima tentativa. Recusas definitivas, como pedido inválido ou falta de permissão, continuam descartadas como antes. Os testes incluem esse caso de controle, para mostrar que só as respostas temporárias mudaram.

Valor entregue

Evita a perda silenciosa de registros de sessão justamente quando o servidor está sob carga, para quem usa a captura por scripts, inclusive no Windows. O cliente nativo do ai-memory já tratava essas respostas como temporárias, e os scripts agora seguem o mesmo princípio.

Ver o PR #1146 no GitHub

O problema

O ai-memory conta, por cliente, quantas leituras e escritas cada agente faz, e esses números aparecem nas métricas de administração. A ferramenta que apenas lista os bastões pendentes ficou fora da lista de leituras, e toda ferramenta não listada conta como escrita. Cada consulta inflava o contador de escritas.

O que foi feito

A ferramenta foi classificada como leitura. Os testes passaram a cobrir a classificação de todas as ferramentas de leitura e de alteração, e um teste novo confirma que cada consulta soma uma leitura e nenhuma escrita.

Valor entregue

Quem administra o servidor vê a proporção real entre consultas e alterações de cada agente, sem escritas fantasmas. A regra conservadora de contar como escrita o que não foi classificado continua valendo para ferramentas novas.

Ver o PR #1088 no GitHub

O problema

O comando de restauração apagava as pastas de dados em uso antes mesmo de abrir o arquivo de backup. Se o arquivo estivesse truncado, corrompido ou viesse de uma versão incompatível, a pessoa ficava sem os dados antigos e sem os novos, justamente no momento em que costuma não ter outra cópia.

O que foi feito

O backup passa a ser extraído e conferido numa área separada. Só depois de validado ele substitui os dados em uso, e cada etapa da troca pode ser desfeita se algo falhar no meio. Quatro testes novos reproduzem cenários de arquivo ruim e falham na versão anterior.

Valor entregue

Elimina um caminho de perda total de dados na recuperação, que é o momento de maior risco da operação. Nada destrutivo acontece antes de conferir o que vai entrar no lugar.

Ver o PR #923 no GitHub

O problema

A wiki guarda seu histórico de alterações com o Git. Páginas com nomes que o Git reserva, como ".git" ou o apelido curto "git~1" do Windows, eram aceitas, mas o Git as recusava ao registrar a versão e o caminho ficava preso na fila, quebrando todos os registros seguintes. Já as gravações em lote da consolidação e as propostas de melhoria aprovadas pulavam a checagem de nomes incompatíveis com o Windows.

O que foi feito

A regra de nomes válidos passou a recusar nomes reservados pelo Git e a valer em todos os caminhos de gravação: página avulsa, gravação em lote, aprovação de propostas e as interfaces usadas pelos agentes e pela administração, que devolvem um erro claro. O registro de versões e o monitor de arquivos também ignoram esses caminhos, e páginas já gravadas continuam legíveis para não quebrar listagens.

Valor entregue

Quem depende do histórico de versões da wiki não o vê mais travar por causa de um único nome ruim, e a regra que mantém a wiki utilizável no Windows passa a valer também para o que o próprio sistema grava automaticamente.

Ver o PR #781 no GitHub

O problema

No macOS, a bateria de testes da linha de comando falhava de forma intermitente quando rodava em paralelo: cada execução quebrava em testes diferentes, que passavam quando rodados sozinhos. A principal hipótese do mantenedor era o esgotamento do monitoramento de arquivos do sistema, que cresce com o número de servidores ativos ao mesmo tempo, e todos esses testes ligavam o monitor da wiki sem precisar dele.

O que foi feito

Os servidores iniciados por esses testes passam a usar a opção, já existente no produto, que desliga o monitor de arquivos, e cada teste confere no registro do próprio servidor que o monitor não chegou a iniciar. O padrão do produto não muda e os testes que exercitam o monitor ficam intactos. Como a falha não se reproduziu fora da máquina original, o PR se apresenta como mitigação, não como cura comprovada.

Valor entregue

Quem contribui roda uma bateria mais leve e isolada, sem perder nenhuma verificação: um revisor mediu cinco arquivos abertos e três linhas de execução a menos por servidor de teste, alívio para o limite de arquivos abertos, que no macOS é baixo por padrão.

Ver o PR #753 no GitHub

O problema

O servidor não tratava o pedido de parada padrão enviado pelo Docker e pelos gerenciadores de serviço do Linux, e num dos modos de conexão não tratava nem o Ctrl+C. Em contêineres o pedido era descartado: a parada esperava todo o prazo de tolerância e acabava forçada, e no caso relatado o Ctrl+C não fazia nada. Fora deles, o processo morria na hora e cortava no meio a consolidação de fim de sessão.

O que foi feito

Os dois modos de conexão passaram a atender o Ctrl+C e o pedido de parada padrão, com a escuta ativa desde antes do fim da inicialização. O desligamento conclui o trabalho em andamento, com teto de cinco segundos por espera para que uma conexão presa não segure o processo. Três testes novos falham na versão anterior; na verificação manual, o servidor encerrou em 58 e 10 milissegundos.

Valor entregue

Quem roda o servidor em Docker passa a reiniciar e atualizar sem esperar o prazo inteiro nem forçar a parada, e o trabalho em andamento termina antes da saída. O contêiner também dispensa o processo auxiliar que antes era preciso só para repassar o pedido de parada.

Ver o PR #703 no GitHub

O problema

Ao iniciar sessões ou listar diretrizes do perfil compartilhado entre projetos, o sistema consulta anotações acumuladas sobre hábitos e regras de engenharia. Um teto fixo limitava a busca do banco de dados em duzentos itens em ordem alfabética de caminho. Em projetos maduros com mais páginas registradas, categorias inteiras ficavam de fora das telas administrativas e a rotina de consolidação interpretava a ausência como exclusão manual, marcando anotações legítimas como esquecidas.

O que foi feito

O PR propõe remover o teto fixo nas consultas de listagem, consolidação e geração de resumos do perfil, garantindo a carga integral das páginas existentes no escopo. O controle de volume passa a ser exercido apenas pelos limites já existentes de tamanho do texto e contagem de linhas exibidas na inicialização. Testes automatizados com mais de duzentos registros comprovam a preservação das categorias finais e a recuperação completa dos caminhos cadastrados.

Valor entregue

Impede a perda de diretrizes consolidadas em perfis extensos e assegura consistência absoluta entre a base de dados e os resumos de sessão.

Ver o PR #1955 no GitHub

O problema

A suíte de testes de relevância mede a precisão das respostas e da busca de contexto a cada nova versão do servidor. Os relatórios gerados apresentavam apenas médias agregadas de acerto, o que dificultava saber quais perguntas ganharam ou perderam posições de resposta no ranking. Além disso, quedas pontuais causadas por atrasos na geração de vetores de busca acabavam confundidas com regressões reais de qualidade.

O que foi feito

O PR propõe um comando para cruzar dois relatórios salvos e listar o deslocamento exato de cada pergunta entre os limites de corte de resposta. A ferramenta compara ganhos e perdas por categoria de consulta e sinaliza quando um resultado coincidiu com uma busca textual simples por falta de vetor. Testes de unidade cobrem a ordenação das mudanças por impacto, a detecção de buscas sem vetor e o carregamento de relatórios antigos.

Valor entregue

Permite auditar a precisão das respostas do assistente e diagnosticar variações no mecanismo de busca antes de publicar novas versões.

Ver o PR #1885 no GitHub

O problema

A ferramenta de edição granular de páginas de memória analisa os títulos de seções para identificar âncoras de navegação e aplicar alterações no texto. Ao interpretar cabeçalhos em Markdown, a rotina removia indiscriminadamente qualquer caractere de sustenido ao final da linha, tratando nomes legítimos de tecnologias como marcadores de fechamento de título. Com isso, seções sobre linguagens como C# tinham sua âncora truncada, colidiam com títulos de nomes parecidos e impediam atualizações e acréscimos diretos no conteúdo da wiki.

O que foi feito

O analisador de cabeçalhos passou a descartar sustenidos finais apenas quando precedidos por espaço ou tabulação, seguindo o padrão CommonMark de fechamento de títulos. Desse modo, nomes de linguagens mantêm a grafia integral na âncora e novos blocos são inseridos com o título correto. Um teste de unidade valida a identificação correta de âncoras em tópicos técnicos e a inclusão de novas seções terminadas em sustenido.

Valor entregue

Permite documentar e atualizar anotações sobre tecnologias como C# e F# sem falhas de localização de seções nem colisões de nomes na base de conhecimento.

Ver o PR #1860 no GitHub

O problema

Ao inicializar a base de conhecimento a partir do histórico do git, o filtro de data aceitava apenas intervalos no plural. Expressões comuns como um dia, uma semana ou um mês atrás não eram reconhecidas e desativavam o corte temporal, fazendo a ferramenta percorrer todo o histórico do projeto desde o primeiro commit e sobrecarregar o resumo com dados antigos. Além disso, intervalos negativos ou números gigantescos podiam zerar os commits coletados ou encerrar o processo por estouro numérico.

O que foi feito

O interpretador de intervalos temporais passou a reconhecer unidades no singular e semanas completas, ignorando espaços em branco nas extremidades. A rotina rejeita durações negativas e adota aritmética protegida contra estouro de inteiros. Testes de unidade cobrem variações no singular, semanas, rejeição de números negativos e proteção contra transbordamento.

Valor entregue

Evita o processamento desnecessário de milhares de commits antigos e garante recortes temporais exatos na geração da documentação inicial.

Ver o PR #1822 no GitHub

O problema

Quando o ciclo de desenvolvimento do ai-memory avançou para a versão seguinte, as diretrizes internas de governança foram atualizadas, mas os guias públicos para colaboradores e o modelo padrão de pull requests continuaram apontando para o ramo anterior. Quem consultava o guia ou seguia o checklist de envio corria o risco de basear novas funcionalidades ou inspecionar o histórico contra uma versão já encerrada em vez da linha principal em andamento.

O que foi feito

O PR propõe alinhar o guia de contribuição e o modelo de submissão de código para que ambos citem explicitamente o ramo ativo da versão 3.3. Com a alteração, colaboradores externos encontram orientações coerentes sobre qual ramo de trabalho escolher antes de abrir uma proposta de funcionalidade.

Valor entregue

Evita retrabalho no envio de contribuições e assegura que novas funcionalidades sejam desenvolvidas sobre o ramo correto do projeto.

Ver o PR #1660 no GitHub

O problema

As telas iniciais da interface web e as listagens gerais exibem o total de páginas e a data da última modificação de cada projeto e espaço de trabalho. Essas agregações contavam qualquer página vigente no banco de dados, incluindo anotações cuja validade temporal já havia expirado, distorcendo o volume de páginas e a indicação de atividade recente.

O que foi feito

As agregações de contagem e data máxima foram atualizadas com o filtro de expiração, contabilizando apenas páginas válidas. Novos testes no backend e na camada web garantem que projetos contendo apenas anotações expiradas registram zero páginas e não afetam datas.

Valor entregue

Os painéis e visões gerais exibem contagens fiéis do acervo documental em uso, sem números inflados por registros vencidos.

Ver o PR #1426 no GitHub

O problema

A consulta de integridade da base de conhecimento aponta páginas episódicas sem atualização há mais de 30 dias, títulos em duplicidade e páginas órfãs sem links de entrada ou saída. Páginas com prazo de expiração vencido entravam nessas três categorias e geravam avisos de alerta, poluindo o relatório de diagnóstico com anotações temporárias que logo seriam removidas na rotina de limpeza.

O que foi feito

As consultas de contagem e detalhamento de integridade passaram a desconsiderar páginas expiradas nos escopos de projeto e de espaço de trabalho. Testes dedicados confirmam que páginas vencidas não são contabilizadas como desatualizadas, duplicadas ou órfãs.

Valor entregue

Os relatórios de saúde da memória concentram a atenção em anotações ativas que realmente demandam revisão ou organização.

Ver o PR #1423 no GitHub

O problema

O resumo de status de um projeto calcula quantos outros projetos dependem dele e de quantos ele depende, contando links entre suas páginas. A contagem de dependências verificava apenas se as páginas eram as versões mais recentes, sem conferir a data de expiração. Links partindo de páginas vencidas ou apontando para elas continuavam inflando as métricas de interdependência mesmo após terem expirado.

O que foi feito

A consulta ao banco de dados passou a filtrar o prazo de expiração tanto na página de origem quanto na de destino, considerando apenas vínculos entre anotações vigentes. Novos testes automatizados comprovam que páginas expiradas com links entre projetos não alteram os contadores de dependência no resumo.

Valor entregue

O panorama de dependências entre projetos reflete a arquitetura viva e funcional, sem ruído de anotações temporárias do passado.

Ver o PR #1422 no GitHub

O problema

A auditoria percorre a wiki em busca de anotações de sessão antigas e nunca consultadas, regras que valeria copiar para os arquivos de instrução do projeto (como CLAUDE.md e AGENTS.md), títulos duplicados e contradições entre páginas, detectadas por semelhança ou por um modelo de linguagem. Páginas com validade vencida entravam em todas essas análises: a auditoria chegava a sugerir levar uma regra vencida para as instruções do projeto e gastava o limite de comparações com páginas à espera da limpeza.

O que foi feito

Cada uma dessas análises passou a pular páginas cujo prazo já passou, enquanto páginas com vencimento futuro continuam avaliadas normalmente. Testes novos confirmam que anotação velha, regra e título duplicado vencidos não geram alerta, que o instante exato do vencimento já conta como vencido e que a busca de contradições ignora páginas vencidas.

Valor entregue

Os arquivos de instrução dos agentes deixam de receber sugestões baseadas em regras que já perderam a validade, e a auditoria concentra o esforço de análise no conhecimento que continua em uso.

Ver o PR #1390 no GitHub

O problema

O relatório de curadoria antecipa o que a limpeza periódica vai remover e aponta oportunidades de manutenção, como anotações de sessões antigas pouco consultadas, páginas de contexto paradas e títulos duplicados. Páginas com validade vencida entravam nas três listas, embora a limpeza as apague por vencimento, e não pelo critério de pouco uso. Assim, o relatório previa errado o que seria removido, acusava páginas de contexto que já iam sumir e apontava como duplicado um título que só colidia com uma página vencida.

O que foi feito

O relatório passou a pular páginas vencidas ao avaliar candidatas a remoção e a usar, para páginas de contexto e títulos, a mesma listagem sem vencidas da interface web. Um teste novo monta uma anotação de sessão antiga e vencida com o mesmo título de uma página válida, mais uma página de contexto vencida, e confere que nenhum dos três alertas aparece.

Valor entregue

Quem usa o relatório para planejar a manutenção da wiki passa a ver só o que de fato depende de decisão, e a previsão do que a limpeza vai remover volta a bater com o que ela faz.

Ver o PR #1389 no GitHub

O problema

Agentes e usuários podem marcar uma página da wiki como desatualizada ou errada, e a auditoria lista essas marcações em aberto para que a página seja revisada. A consulta da auditoria considerava só a versão atual da página, sem olhar o prazo de validade. Uma página vencida, já fora da busca e à espera da limpeza periódica que vai apagá-la, seguia aparecendo na auditoria com o pedido de atualização ou correção.

O que foi feito

A consulta passou a aplicar o mesmo filtro de validade das demais leituras, e as marcações de páginas vencidas deixam de entrar na lista. As marcações de páginas vigentes continuam listadas como antes. Um teste novo registra marcações numa página vencida e numa válida e confere que só a da válida aparece.

Valor entregue

O trabalho de revisão apontado pela auditoria passa a se concentrar no conteúdo que continua em uso, sem esforço gasto corrigindo páginas que vão sumir sozinhas.

Ver o PR #1388 no GitHub

O problema

Antes de gravar as páginas que a consolidação gera a partir de uma sessão, o ai-memory confere se cada link e cada relação proposta aponta para uma página que existe, no próprio projeto ou em outro. A consulta usada nessa conferência tratava como existente uma página com prazo de validade vencido, que a próxima limpeza periódica vai apagar. A consolidação mantinha esses links, e as auditorias seguintes passavam a acusar links quebrados e relações sem destino.

O que foi feito

A conferência passou a desconsiderar páginas vencidas, com o mesmo filtro de validade das demais leituras, e um link ou relação para elas recebe o mesmo tratamento dado a um destino inexistente. Um teste novo confere que, entre os caminhos consultados, a página vencida fica de fora e a de vencimento futuro continua.

Valor entregue

A wiki deixa de nascer com links condenados: o que a consolidação grava aponta para páginas que vão continuar existindo, e as auditorias seguintes não herdam esses links quebrados.

Ver o PR #1387 no GitHub

O problema

O ai-memory atribui a cada página um grau de confiança, calculado a partir das evidências que a sustentam e usado na ordenação da busca e na explicação dos resultados. Uma contradição declarada com outra página vigente reduz essa confiança, mas uma contradição com página que saiu de circulação não deveria pesar, regra que a auditoria já seguia. O cálculo descartava destinos apagados, mas não os vencidos, e assim uma página perdia posição na busca por discordar de um conteúdo que já tinha expirado.

O que foi feito

O cálculo passou a contar só contradições cujo destino é a versão atual e não vencida de uma página, alinhado à separação entre conflito ativo e declaração desatualizada que a auditoria já fazia. Um teste novo compara uma contradição com página vencida e outra com página de vencimento futuro e confere a contagem e a confiança mostrada na explicação da busca.

Valor entregue

A ordenação da busca deixa de rebaixar páginas por conflitos que já não existem, e os agentes recebem primeiro o conhecimento que de fato merece confiança.

Ver o PR #1386 no GitHub

O problema

Além da ferramenta usada pelos agentes, o ai-memory tem um comando de terminal para ler uma página pelo caminho, que consulta uma rota administrativa do servidor. Como a leitura direta continua devolvendo páginas com validade vencida até a limpeza periódica, esse caminho também precisava avisar quando a página já tinha vencido. O comando, porém, exibia a página vencida exatamente como uma válida, e a saída em JSON só trazia a data crua, que um script teria de comparar sozinho.

O que foi feito

A rota administrativa passou a indicar a página vencida, tanto na leitura do arquivo quanto na cópia guardada no banco, e o comando imprime uma linha de vencida logo abaixo do caminho, com o mesmo campo na saída em JSON. Páginas válidas saem como antes, e um servidor de versão anterior, sem o campo, é lido como válido. Um teste novo lê pela rota uma página vencida, uma com vencimento futuro e uma vencida sem arquivo, e confere a marca só nas vencidas.

Valor entregue

Quem lê páginas pelo terminal ou automatiza a leitura em scripts recebe o mesmo aviso que os agentes e a interface web, e não toma por vigente um conteúdo prestes a ser apagado.

Ver o PR #1373 no GitHub

O problema

Uma página com prazo de validade vencido some da busca e das listagens, mas continua acessível pelo próprio endereço até a limpeza periódica apagá-la. O sistema já calculava se a página lida estava vencida, mas a tela da página na interface web ignorava essa informação. Quem chegava a ela por um link salvo ou pelo histórico via o conteúdo exatamente como o de uma página válida, sem saber que ele já tinha saído de circulação e seria apagado na próxima limpeza.

O que foi feito

A linha de metadados da página passou a exibir um selo de vencida ao lado das marcações de camada, tipo e fixação, reaproveitando o visual do selo de página fixada, sem alterar a folha de estilos. Páginas válidas aparecem exatamente como antes, e a documentação de uso menciona o selo. Um teste novo abre uma página vencida e uma com vencimento futuro e confere o selo só na primeira.

Valor entregue

Quem consulta a wiki pela interface web sabe na hora que está lendo um conteúdo prestes a ser apagado, e não o confunde com informação vigente.

Ver o PR #1372 no GitHub

O problema

Quando uma página passa do prazo de validade, a busca, a lista de recentes e o resumo de início de sessão deixam de mostrá-la, mas a leitura pelo caminho exato continua devolvendo a página, porque um pedido explícito não é uma busca. O projeto previa que essa resposta viesse marcada como vencida, mas a ferramenta de leitura dos agentes devolvia a página igual a uma válida. O único rastro era a data crua nos metadados, que o agente teria de interpretar sozinho.

O que foi feito

A resposta da ferramenta passou a trazer a indicação de vencida quando o prazo da página já passou, tanto na leitura do arquivo quanto na cópia guardada no banco, usada quando o arquivo some. Para páginas válidas, a resposta continua idêntica à de antes, e a documentação registra o novo campo. Um teste novo lê uma página vencida, uma com vencimento futuro e uma vencida sem arquivo, e confere a marca só nas vencidas.

Valor entregue

O agente deixa de tratar como atual um conteúdo que já saiu de circulação e só espera a limpeza, e pode avisar o usuário ou buscar uma versão vigente antes de agir com base nele.

Ver o PR #1371 no GitHub

O problema

Uma página com prazo de validade vencido deve sumir da busca, da lista de recentes e do resumo de início de sessão até a limpeza periódica apagá-la, e só a leitura pelo endereço exato ainda a devolve. As listagens da interface web e da API ficaram de fora dessa regra: a árvore do projeto, a atividade recente, as listagens de pasta e a lista de páginas continuavam exibindo a página. O mesmo endereço de recentes chegava a mostrá-la numa forma de consulta e a escondê-la na outra.

O que foi feito

As listagens mostradas a quem lê passaram a usar uma consulta com o mesmo filtro de validade da busca. A listagem completa continua disponível onde todas as páginas atuais são necessárias, como ao mover um projeto, que copia inclusive as vencidas para não perdê-las. Abrir a página vencida pelo endereço exato continua funcionando, e testes novos conferem cada listagem e a leitura direta.

Valor entregue

O que a interface web e a API listam passa a bater com o que a busca e os agentes enxergam, e conteúdo marcado para sair de circulação não reaparece por uma tela lateral.

Ver o PR #1369 no GitHub

O problema

Uma página pode depender de uma página de outro projeto por meio de um link, e a auditoria da wiki e o relatório de curadoria avisam quando esse destino não existe, sinal de uma dependência quebrada. A verificação só pegava links que nunca tiveram destino; o destino registrado na gravação continua lá depois que a página sai de circulação ou vence, e por isso links para páginas apagadas ou vencidas passavam como válidos. Páginas de origem vencidas, por outro lado, seguiam gerando alertas.

O que foi feito

A consulta passou a tratar como quebrado todo link entre projetos cujo destino não é a versão atual e não vencida de uma página, e a ignorar páginas de origem vencidas, como as demais consultas de links. Testes cobrem destino válido, com vencimento futuro, retirado, vencido e inexistente, projeto inexistente e origem vencida, e um teste do relatório de curadoria confere o alerta quando a página de destino sai de circulação.

Valor entregue

Quem mantém vários projetos na mesma memória descobre pela auditoria quando uma página de que depende foi retirada em outro projeto, em vez de seguir confiando num link que leva a lugar nenhum.

Ver o PR #1368 no GitHub

O problema

Uma página da wiki pode declarar que contradiz outra, e a auditoria trata isso de dois jeitos: se o destino existe, pede para conciliar as duas; se não existe, avisa que a declaração ficou velha. A auditoria decidia só pelo destino registrado na gravação, que continua lá depois que a página de destino sai de circulação ou vence, e por isso pedia conciliação com páginas que já não existiam. Páginas de origem vencidas também seguiam gerando esses alertas.

O que foi feito

A consulta passou a considerar resolvida só a contradição cujo destino é a versão atual e não vencida de uma página, e a ignorar páginas de origem vencidas, como já faziam as outras consultas de links. Testes cobrem destino válido, retirado, vencido, com vencimento futuro e inexistente, além de origem vencida, e um teste da auditoria confere o aviso de declaração desatualizada quando o destino sai de circulação.

Valor entregue

A lista de conflitos da auditoria passa a trazer só contradições reais entre páginas vigentes, e o tempo de revisão não se perde com páginas que já saíram da wiki.

Ver o PR #1367 no GitHub

O problema

Na consolidação, o modelo de linguagem pode indicar relações entre páginas, como uma que corrige, causa ou contradiz outra, registradas nos metadados da página. Quando o destino indicado não era uma página, como um título com pontos (3.0.0 para 3.1.0), uma pasta ou um .md sem nome, ele era gravado assim mesmo, e a limpeza das relações deixava passar justamente esses casos. Com o destino inválido no arquivo, o monitor da wiki, que relê os arquivos a cada 30 segundos, repetia o mesmo aviso em toda passada.

O que foi feito

Cada destino passou a ser validado, antes de entrar nos metadados, pela mesma regra que a wiki usa para ler relações, e um tipo de relação que fica sem destino válido é omitido. A limpeza das relações também passou a descartar entradas que não correspondem a nenhuma página. Testes novos misturam títulos, pastas, nomes vazios e caminhos fora da wiki com um destino válido e conferem que só o válido permanece.

Valor entregue

Os metadados das páginas guardam só relações que levam a algum lugar, e o registro do servidor deixa de repetir o mesmo aviso a cada 30 segundos.

Ver o PR #1366 no GitHub

O problema

A wiki do ai-memory usa links internos entre colchetes duplos, e a interface web transforma cada um num link clicável para a página de destino. Um link terminado em barra, que aponta para uma pasta, ou que só tinha a extensão .md, sem nome de página, também era convertido, para um endereço que nunca existe. Quem clicava caía numa página não encontrada, embora o restante da wiki já descartasse esses links como destinos inválidos.

O que foi feito

A interface web passou a recusar esses dois formatos antes de montar o link e a mostrá-los como o texto original, alinhada à regra que a wiki já aplica ao extrair links. Os links para páginas válidas continuam convertidos como antes. Um teste novo confere que link de pasta, link sem nome, link de pasta em outro projeto e link de pasta com rótulo ficam todos como texto.

Valor entregue

Quem navega pela wiki na interface web não esbarra mais em links que levam a lugar nenhum, e a tela passa a mostrar como link exatamente o que a wiki considera válido.

Ver o PR #1364 no GitHub

O problema

A melhoria automática propõe ajustes em páginas de regras e procedimentos seção por seção, localizando cada seção pelo título. Para não confundir títulos que aparecem dentro de exemplos de código, ela pula os blocos de código, mas encerrava um bloco em qualquer linha de marcação, mesmo de outro tipo ou mais curta que a de abertura. Um exemplo com uma marcação diferente dentro, como um script embutido, escondia os títulos seguintes, e trocar uma seção substituía junto as que vinham depois dela.

O que foi feito

O leitor de seções passou a lembrar qual marcação abriu o bloco e só o fecha numa marcação igual, do mesmo caractere e pelo menos do mesmo comprimento, a regra do padrão CommonMark que o ai-memory já usava ao extrair links. O formato das propostas não mudou. Um teste novo cobre um bloco marcado com tils que contém uma linha de crases e um bloco longo que contém um mais curto, e confere que o título seguinte é encontrado e o de dentro do código, não.

Valor entregue

Aprovar uma proposta de melhoria volta a alterar só a seção revisada, sem apagar por tabela trechos de regras e procedimentos que o revisor nem chegou a ver.

Ver o PR #1316 no GitHub

O problema

Na consolidação, o ai-memory pede a um modelo de linguagem que transforme o que aconteceu numa sessão em páginas da wiki, e uma mesma resposta pode trazer várias páginas. Caminhos com caracteres proibidos já eram corrigidos, mas um caminho começando com barra, com trechos . ou .. ou com uma pasta vazia não tinha conserto e fazia a consolidação da sessão inteira falhar. Bastava uma página assim para nenhuma das outras, mesmo válidas, ser gravada.

O que foi feito

Uma página com caminho sem conserto passou a ser pulada com um aviso no registro, e as demais páginas da resposta são gravadas normalmente, como já acontecia com caminhos reprovados na checagem de portabilidade. Falhas de armazenamento, da wiki ou do modelo continuam interrompendo a consolidação. Um teste novo envia três caminhos inválidos e um válido e confere que só a página válida é gravada.

Valor entregue

Um erro pontual do modelo deixa de custar o resumo inteiro de uma sessão: o conhecimento válido chega à wiki, e a página descartada fica apontada no registro.

Ver o PR #1315 no GitHub

O problema

O ai-memory mantém páginas de contexto fixas, como a de foco atual, que resume no que se está trabalhando no momento, e o relatório de curadoria avisa quando elas ficam paradas: em 7 dias para o foco atual e em 30 para as demais. Quando a instalação separa essas páginas por usuário, o foco de cada pessoa fica numa pasta própria, e a verificação só reconhecia o caminho compartilhado. Assim, o foco de cada usuário caía no prazo de 30 dias, e um foco abandonado só era apontado três semanas depois do previsto.

O que foi feito

A verificação passou a reconhecer a página de foco atual tanto no caminho compartilhado quanto na pasta de cada usuário, usando a mesma regra de nomes que o restante do sistema já aplica a essas páginas. As demais páginas por usuário continuam com o prazo de 30 dias. Um teste novo envelhece em 8 dias o foco e outra página do mesmo usuário e confere que só o foco é apontado, com o prazo de 7 dias.

Valor entregue

Em instalações com páginas de contexto por usuário, o foco atual desatualizado volta a ser apontado em uma semana, e não só depois de um mês, como já acontecia com o foco compartilhado.

Ver o PR #1314 no GitHub

O problema

A melhoria automática pede a um modelo de linguagem propostas para aprimorar a base de conhecimento, cada uma com uma nota de confiança de 0 a 1; as abaixo de um mínimo são descartadas e as demais vão para revisão. Nada barrava valores acima de 1: um modelo que respondesse em porcentagem (85 em vez de 0,85) passava do mínimo, aparecia como 8500% e ia para o topo da ordem por confiança. Um valor inválido, que nem é número, também passava.

O que foi feito

Propostas com confiança fora do intervalo de 0 a 1 passaram a ser recusadas com um motivo próprio e registradas junto com as demais rejeitadas, para que a próxima revisão veja o porquê. O valor é recusado, e não ajustado: adivinhar se 85 queria dizer 85% transformaria uma resposta malformada numa nota confiável. Propostas que já estavam na fila não são alteradas.

Valor entregue

Quem revisa as sugestões deixa de ver no topo da fila uma proposta com nota absurda, e uma resposta mal formatada do modelo não vira uma nota alta. A ordenação por confiança passa a comparar só valores válidos.

Ver o PR #1192 no GitHub

O problema

Na consolidação, cada regra do projeto vira uma página com nome derivado do título, aproveitando só letras latinas e números. Um título em cirílico, chinês, árabe ou grego não gerava nome algum e caía num nome fixo, igual para todos. No mesmo lote, a última regra apagava as outras; entre sessões, cada regra nova substituía a anterior, e só uma aparecia na lista de regras mostrada no início de cada sessão.

O que foi feito

Essas regras passaram a ganhar um nome próprio, com um código curto calculado a partir do título. O nome é estável entre execuções, então uma regra reafirmada atualiza a própria página, e duas formas de escrever o mesmo caractere acentuado levam ao mesmo nome. Títulos em alfabeto latino mantêm os nomes de antes.

Valor entregue

Projetos que registram regras em russo, chinês, árabe, grego e outras línguas de escrita não latina passam a ter todas elas ativas no início da sessão, e não só a mais recente.

Ver o PR #1191 no GitHub

O problema

O ai-memory permite gravar páginas com data de expiração; depois dela, a página some da busca, da lista de recentes e do resumo de início de sessão. Duas consultas ficaram de fora: o painel de links da interface web e a lista de páginas relacionadas que o agente recebe ao ler uma página. Ali, uma página vencida continuava aparecendo e ainda servia de ponte para chegar a outras páginas.

O que foi feito

As duas consultas passaram a usar o mesmo filtro de validade da busca: uma página vencida não aparece mais e não serve de caminho para chegar a outras. Abrir uma página vencida diretamente pelo endereço continua funcionando, de propósito, com a indicação de que expirou. Testes montam páginas válidas, vencidas e com vencimento futuro e conferem cada caso.

Valor entregue

A data de expiração passa a valer também na navegação por links: conteúdo marcado para sair de circulação deixa de chegar aos agentes por um caminho lateral, do mesmo jeito que já não aparecia na busca.

Ver o PR #1141 no GitHub

O problema

O ai-memory usa a primeira linha de cada pedido feito ao agente como título do registro. A regra só reconhecia o final de linha do Linux e do macOS, então no Windows sobrava um caractere invisível no fim do título, que podia chegar ao título da sessão e ao índice de busca. Os títulos de início de sessão, de notificações e dos resumos gerados quando o agente compacta a conversa nem passavam por essa regra e podiam guardar quebras de linha.

O que foi feito

Todos esses eventos passaram a usar a mesma regra de primeira linha, que reconhece o final de linha do Windows tanto quanto o do Linux e do macOS. Quando a primeira linha vem vazia, nenhum título é sugerido e o sistema usa o título padrão do evento, em vez de gravar um título em branco. Os testes cobrem pedidos com final de linha do Windows e os três tipos de evento que antes ficavam de fora.

Valor entregue

Quem usa os agentes no Windows passa a ter títulos de sessão e de registro iguais aos dos outros sistemas, sem caractere escondido indo para o índice de busca. Notificações e resumos também ganham títulos de uma linha, como os pedidos já tinham.

Ver o PR #1111 no GitHub

O problema

A interface web do ai-memory já tratava como inseguros os endereços que começam com file: (arquivos do computador) e vbscript: (scripts) e os mostrava como texto comum. O indexador de links da wiki não os reconhecia: lia o prefixo ("file", por exemplo) como o nome de outro projeto e registrava uma ligação falsa para ele. O índice de links e a exportação da wiki ficavam em desacordo com o que a página exibia.

O que foi feito

As duas verificações que identificam links na wiki passaram a recusar esses dois prefixos, igualando a lista de endereços bloqueados à da interface web. Foi preciso mudar as duas, porque corrigir só uma ainda registraria a ligação para o projeto "file". Um teste novo cobre os dois formatos de link aceitos pela wiki, inclusive um endereço que aponta para um arquivo do sistema.

Valor entregue

O mapa de links da wiki, usado na navegação entre páginas e na exportação, deixa de ganhar ligações falsas entre projetos. A regra sobre quais endereços contam como link passa a ser uma só, na indexação, na exportação e na exibição.

Ver o PR #1110 no GitHub

O problema

A interface web mostra o título da página no cabeçalho e retira o título repetido do início do texto. Com títulos sublinhados por sinais de igual, uma das formas de escrever títulos em Markdown, isso falhava em três casos: arquivos com finais de linha no padrão do Windows, sublinhado com espaços sobrando no fim e arquivo terminando logo após o sublinhado.

O que foi feito

A verificação passou a ignorar o caractere extra dos finais de linha do Windows e os espaços ou tabulações no fim do sublinhado, e a tratar o arquivo que termina na própria linha do sublinhado, como já acontecia com a outra forma de escrever títulos. Testes novos cobrem os três casos.

Valor entregue

Quem trabalha com a wiki no Windows vê as páginas com o mesmo acabamento das demais, sem o título repetido no topo.

Ver o PR #1108 no GitHub

O problema

Mesmo depois que os links passaram a preservar a indicação de seção (PR #1089), a interface web exibia os títulos internos das páginas sem identificador. Sem esse alvo, o navegador não tinha para onde rolar, e o link para uma seção abria o topo da página.

O que foi feito

Cada título passa a receber um identificador legível, derivado do próprio texto: em minúsculas, sem pontuação e com hifens no lugar dos espaços. Títulos repetidos na mesma página ganham sufixos numéricos para não colidir, títulos vazios recebem um nome padrão e identificadores já definidos pelo autor são mantidos.

Valor entregue

Completa a navegação por seções iniciada no PR #1089: quem segue um link da wiki ou um endereço compartilhado chega direto ao trecho certo da página.

Ver o PR #1105 no GitHub

O problema

A wiki aceita links internos que apontam para uma seção específica de outra página, notação padrão em wikis. Tanto na interface web quanto na exportação da wiki em arquivos, a parte que indicava a seção era descartada, e o link levava só ao início da página.

O que foi feito

As duas conversões de link passaram a separar a indicação de seção, e eventuais parâmetros do endereço, antes de localizar a página, recolocando-a no endereço final. Links sem seção e links para uma seção da própria página continuam como antes, e o índice segue apontando para a página certa.

Valor entregue

Quem consulta a base de conhecimento chega direto à seção citada, como o contexto de uma decisão, e os pacotes exportados mantêm as mesmas referências precisas.

Ver o PR #1089 no GitHub

O problema

O ai-memory reserva um espaço de páginas globais, legíveis por todos os projetos, que fica no workspace padrão. Um link para uma dessas páginas escrito num projeto de outro workspace era procurado no workspace de origem: na interface web levava a um endereço inexistente e no mapa de relações entre páginas ficava sem destino. Como as instruções do próprio consolidador geram esse tipo de link, o sistema escrevia links que não conseguia resolver.

O que foi feito

Links para o espaço global passam a apontar sempre para a sua sede fixa no workspace padrão, venham de onde vierem, tanto no índice quanto na interface web. As demais formas de link, inclusive as que nomeiam um workspace de forma explícita, não mudam. Links antigos gravados no formato quebrado são corrigidos na próxima gravação da página global.

Valor entregue

Para quem organiza o trabalho em mais de um workspace, regras e preferências compartilhadas passam a ser alcançáveis pelos links que o próprio sistema escreve. Nada novo fica exposto, porque as páginas globais já eram legíveis por todos os projetos.

Ver o PR #1064 no GitHub

O problema

A leitura dos links falhava em casos comuns. Um bloco de código aberto com um marcador mais longo ou de outro tipo era fechado antes da hora, e linhas de código viravam links enquanto o texto seguinte era tratado como código. Endereços com parênteses, como os da Wikipédia, eram cortados e descartados, links relativos iniciados por "./" davam página não encontrada na interface web e a exportação gerava links inválidos para páginas com espaço no nome.

O que foi feito

A leitura passou a seguir a especificação padrão do Markdown: um bloco de código só fecha com o mesmo tipo e tamanho de marcador que o abriu, parênteses balanceados e endereços entre os sinais < e > são reconhecidos, endereços com espaço são exportados entre esses sinais e o prefixo "./" é removido antes de abrir a página. Cada caso ganhou um teste que impede a volta do problema.

Valor entregue

Para quem documenta e consulta a wiki, links deixam de sumir do mapa de relações entre páginas, a exportação gera arquivos que outras ferramentas de Markdown aceitam e o clique em links relativos na interface web abre a página certa.

Ver o PR #985 no GitHub

O problema

Execuções repetidas e parecidas, como as do Grok Build, produziam páginas de sessão com o mesmo título genérico (por exemplo, "Adversarial Verification"), e a auditoria da wiki acusava títulos duplicados. Resolver só com mais instruções ao modelo não bastava: no menor limite de entrada aceito pela configuração, o texto extra deixava o modelo sem nenhuma observação da sessão para resumir.

O que foi feito

As instruções ganharam duas linhas curtas pedindo um título específico da sessão, e a lista de títulos já usados, com no máximo 15, só é enviada quando o projeto tem algum. Como garantia final, um título que ainda coincida com um existente, sem diferenciar maiúsculas nem espaços extras, recebe na gravação um sufixo com o identificador curto da sessão. Testes confirmam que o conteúdo da sessão segue chegando ao modelo mesmo no limite mínimo.

Valor entregue

Quem consulta a wiki do projeto encontra cada sessão pelo próprio nome e a auditoria deixa de acusar duplicatas, sem que a correção piore os resumos: o modelo continua recebendo o conteúdo da sessão mesmo na configuração mais enxuta.

Ver o PR #926 no GitHub