# Transformar a memória em um serviço durável 13 de maio de 2026. A VALESKA dá à sua API de memória um serviço Docker reiniciável e define as próximas perguntas para sua camada de conhecimento. Language: pt Canonical: https://avanticomplex.com/pt/blog/making-memory-a-durable-service-pt/ Published: 2026-05-13T12:00:00.000Z 13 de maio de 2026. A afirmação de hoje é modesta, mas importante: um sistema de memória precisa estar disponível como serviço antes de se tornar infraestrutura confiável para agentes. A superfície FastAPI da VALESKA está sendo levada ao Docker Compose junto com o PostgreSQL. A API deixa de ser um arranjo que depende de um processo específico de desktop iniciar na ordem certa. Ela tem uma imagem definida, uma porta publicada, uma política de reinicialização e uma verificação de saúde. O PostgreSQL precisa informar que está saudável antes de a API iniciar. Isso não responde a todas as perguntas sobre a qualidade da memória, mas dá ao sistema uma forma operacional que pode ser inspecionada e reiniciada. ## A pergunta de trabalho Um serviço local de conhecimento pode continuar utilizável em interrupções normais sem perder silenciosamente os registros que deve preservar? A pergunta trata de mais do que contêineres. Um processo reiniciável só tem valor se sua cadeia de dependências e seus dados armazenados forem visíveis. No arranjo local anterior, uma incompatibilidade entre o loop de eventos do Windows e o driver do banco de dados exigia uma solução alternativa no host. Mover a API para um contêiner Linux remove essa condição operacional específica do caminho da API. O serviço pode alcançar o PostgreSQL pela rede do Compose, enquanto os agentes podem usar o contrato HTTP de memória documentado na porta do host. ## O que as evidências estabelecem A alteração no Compose acrescenta um serviço dedicado `valeska_api` com `restart: unless-stopped`, uma solicitação de saúde à API e uma dependência explícita de PostgreSQL saudável. Suas configurações de conexão apontam para o serviço de banco de dados em vez do loopback do host. O armazenamento do banco de dados e do pgAdmin é montado em caminhos do host. Essa decisão de armazenamento importa porque os registros não devem existir apenas no disco virtual do Docker; o local de persistência faz parte do modelo operacional. O Dockerfile fornece o ambiente de execução da API e suas dependências de banco de dados, tornando a mesma definição de serviço disponível para uma inicialização nova, em vez de depender de uma sequência lembrada de comandos locais. O outro trabalho registrado hoje mantém esta mudança de infraestrutura em proporção. Um endpoint durável não torna a recuperação útil por si só. O plano da camada de conhecimento nomeia lacunas que permanecem: pacotes de contexto em vez de fragmentos isolados classificados; resumos hierárquicos para documentos longos; acesso governado a material tabular; recuperação por grafos; e solicitações de recuperação que declarem intenção, atualidade, confiança e orçamento. Ele também distingue o trabalho já presente daquele apenas planejado. Estruturas de governança e proveniência existem, enquanto várias formas de recuperação ainda são lacunas ou trabalho parcial. Essa distinção impede que um marco de implantação se torne a alegação de que a camada de conhecimento está concluída. ## Por que o serviço e o plano pertencem um ao outro Os agentes precisam de uma forma estável de solicitar e registrar conhecimento, mas a estabilidade por si só pode facilitar a repetição de um padrão pouco confiável. A API fornece uma rota durável para captura e recuperação. O plano apresenta perguntas para decidir o que essa rota deve devolver e sob quais regras. Uma solicitação que pede apenas texto semelhante pode omitir a política orientadora, o histórico relevante ou a origem de um registro. Uma resposta de contexto maior também pode tornar uma tarefa mais difícil se incluir material sem uso declarado. A direção pretendida é, portanto, contexto apropriado: material selecionado com autoridade, proveniência, permissões e incerteza disponíveis para revisão. ## Próximo teste O teste imediato é operacional. Iniciar o serviço Compose de um estado limpo, verificar o caminho de saúde e o contrato de memória, depois reiniciá-lo e confirmar que os registros armazenados continuam disponíveis pela API documentada. Em paralelo, o próximo teste de planejamento é transformar o trabalho de contrato de recuperação em uma proposta de implementação delimitada: quais campos o chamador fornece, como eles restringem a seleção e como a resposta mostra sua proveniência. Até que essas verificações sejam feitas, isto é uma fundação de serviço e um plano, não evidência de que a recuperação governada resolveu o problema de contexto do agente. **Base histórica:** commits de 13 de maio de 2026 `0876323` e `a5e3cd9`. ## Translations - en: https://avanticomplex.com/en/blog/making-memory-a-durable-service/ - es: https://avanticomplex.com/es/blog/making-memory-a-durable-service-es/ - pt: https://avanticomplex.com/pt/blog/making-memory-a-durable-service-pt/