2026-05-31. Um sistema de memória pode ficar mais difícil de usar mesmo enquanto registra mais trabalho corretamente. Um prompt de usuário, um evento de hook, uma decisão duradoura e um fato de serviço verificado não merecem o mesmo tratamento padrão quando um agente pede contexto anterior. Minha afirmação é que o protocolo precisa identificar essas finalidades na captura e tornar a recordação comum mais silenciosa sem fingir que material operacional de baixo sinal nunca existiu. A pergunta é se podemos melhorar o sinal apresentado ao agente e preservar uma rota explícita para inspecionar o material resfriado ou filtrado.
O protocolo agora infere um tipo de captura quando quem chama não o forneceu. Ele reconhece fatos de execução, prompts de usuário, eventos de hook, resumos de despacho e memória duradoura a partir da fonte, conteúdo ou tipo de pensamento disponíveis. Prompts e eventos de hook são ruído operacional por padrão. Quando não há nível solicitado, eles recebem memória de trabalho no nível frio. As consultas normais de busca e memória recente excluem esse ruído, enquanto quem chama pode incluí-lo deliberadamente para investigação. Esta é uma regra de recuperação, não uma afirmação de exclusão: ela impede que maquinaria transitória concorra com os registros que um agente normalmente precisa.
Essa separação segue o trabalho de a entrada de recuperação de 19 de maio. A telemetria pode mostrar uma falha ou resultados amplos, mas o protocolo também precisa dizer por que um registro entrou no repositório e como deve ser tratado. O construtor de consultas aplica o predicado de ruído tanto à busca semântica quanto à lista recente. Os testes cobrem a exclusão padrão e a inclusão opcional, inclusive a consulta sem alias usada para registros recentes. Eles também cobrem o resfriamento: um prompt sem nível se torna frio, enquanto um nível duradouro explícito é mantido. São verificações do contrato, ainda não evidência de que a recordação em uso esteja mais precisa.
Os fatos recebem uma rota separada. O serviço e a API expõem captura e consulta exata para uma chave e valor de fato, para que um fato operacional estável possa ser recuperado como tal em vez de reconstruído a partir de resultado narrativo. Isso não eleva toda afirmação capturada a verdade verificada. Estabelece uma forma de registro e contrato distintos para os casos em que quem chama armazena deliberadamente um fato. Os testes exercitam a recuperação exata e preservam as informações de projeto e principal passadas pelo endpoint.
A alteração também reforça procedência e etiquetagem. Um identificador de agente em branco é normalizado para o valor estável unknown-agent em vez de adotar formas vazias variáveis. As etiquetas canônicas de projeto, trilha e ramificação são reconstruídas para que etiquetas conflitantes de passagem não permaneçam junto às autorizadas. A suíte verifica que uma etiqueta de projeto errada ou de trilha antiga é removida, enquanto a correta permanece. Isso protege filtragem e atribuição contra etiquetas contraditórias introduzidas na captura.
Não trato este commit como prova de que as classificações estejam universalmente certas. Um prompt pode ser importante para uma investigação; um evento de hook pode revelar uma falha; um suposto fato pode precisar de correção. Por isso o desenho mantém a opção de incluir ruído e escolhas explícitas de nível. Seu resultado imediato é um protocolo mais legível, com tratamento padrão visível, substituições possíveis e registros usados pela recordação comum que têm razões nomeadas para sua colocação.
O que testarei em seguida
O próximo teste é a recordação em sessões reais. Compararei buscas comuns com uma busca de investigação que inclua tudo, procurarei material que não deveria ter sido resfriado e verificarei se a consulta de fatos reduz buscas narrativas evitáveis sem esconder o contexto necessário para validar um fato. O resultado deve ser estabelecido nessas sessões, não inferido da cobertura de unidades.
Base histórica: marco do repositório de 2026-05-31, commit 55d876d.