akitaonrails/ai-memory

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

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

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

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