OpenClaw Memória de Reset: Prove o alcance antes de apagar o estado

A memória de reset OpenClaw não é uma operação. Um chat /new ou /reset , uma reconstrução de índice de memória e o destrutivo openclaw reset CLI agem em diferentes camadas. Se o problema for uma conversa obsoleta, um reset completo do CLI é o padrão errado: o escopo documentado do full remove o diretório de estado, o banco de dados SQLite compartilhado e os diretórios do espaço de trabalho, incluindo os arquivos Markdown que possuem memória duradoura. O padrão de segurança é: 1. Identificar a primeira camada falhada; 2. Escolher a ação mais estreita que possa repará lo; 3. inspeccionar o plano destrutivo com uma corrida seca; 4. criar e verificar um backup que cobre cada camada que pretende preservar; 5. Obter aprovação explícita; 6. Verificar a configuração, os arquivos de memória, a prontidão de pesquisa e o resultado pretendido após a recuperação. Uma corrida seca é a prova do plano. Não é um backup, e a conclusão do comando não é prova de que a memória desejada sobreviveu. Decida qual "reset" queres dizer. O Documentação de memória OpenClaws diz que a memória duradoura vive em arquivos simples Markdown no espaço de trabalho do agente. O USER.md possui diretrizes de perfil estáveis, o MEMORY.md possui fatos e decisões duradouras, e os arquivos memory/YYYY MM DD.md contêm notas de trabalho. As ferramentas de pesquisa indicam essas fontes, mas o índice não é a fonte da verdade. Isso cria pelo menos quatro sintomas diferentes que as pessoas comprimem em reset memória: Sintoma Primeira camada a inspecionar Primeira ação razoável A conversa atual desviou se. Contexto da sessão Salvar decisões duradouras, depois começar uma nova sessão A pesquisa perde um fato conhecido Markdown Índice de memória ou fornecedor Verifique o estado da memória e reconstruir o índice MEMORY.md ou notas diárias estão erradas Espaço de trabalho Markdown Corrigir ou restaurar o arquivo afetado, em seguida, reindexar Configuração local, credenciais, sessões ou estado são irreparavelmente inconsistentes Estado de instalação Planejar o escopo de redefinição CLI mais estreito documentado Estas acções não são intercambiáveis. O início de uma nova sessão não deve apagar o duradouro Markdown. A reconstrução de um índice derivado não deverá exigir a exclusão do espaço de trabalho. A edição de uma entrada de memória ruim não deve excluir as credenciais. O CLI destrutivo pertence ao fim do diagnóstico, não ao começo. O Referência openclaw reset oficial define atualmente três domínios: Ámbito de aplicação Limite de remoção documentada O gateway parou primeiro. config Apenas arquivo de configuração Não config+creds+sessions Config, diretório OAuth/credenciais e diretórios de sessões por agente Sim full Directório de Estado, base de dados SQLite compartilhada e directórios de espaço de trabalho Sim O escopo certo segue a camada diagnosticada. Um sintoma de sessão não justifica a full . Uma configuração mal formada não justifica a exclusão de credenciais e sessões. Se o operador não puder nomear a camada quebrada, o estado é uncertain e o trabalho destrutivo deve esperar. Antes mesmo de considerar o CLI, recolha provas sem conteúdo: Este recibo não armazena pedidos, conteúdos de memória, segredos ou caminhos absolutos privados. Ele registra os limites de decisão. Leia a corrida seca, não apenas o código de saída. O CLI expõe o dry run . Usá lo com o escopo exato em consideração: Este comando não é destrutivo, mas a saída ainda precisa de interpretação. Regista a parada prevista, cada alvo de remoção resolvido, qualquer recusa e a etapa de embarque esperada posteriormente. Um código de saída zero sozinho é fraco demais. Eu corri a corrida em seco equivalente a todo o alcance contra o OpenClaw 2026.7.1 2 em 2026 07 30. Ele recomendou criar um backup, planejou parar o gateway, depois informou que os caminhos de estado e espaço de trabalho eram inseguros de remover naquela instalação. Essa observação é específica do hospedeiro; não significa que todos os resets completos falhem. A conclusão é mais útil: o sucesso de em operação seca e a resolução alvo são fatos separados . Use um pequeno registro de planos: A classificação correta é reset plan blocked , não ready to reset . Não contorne uma recusa de segurança excluindo manualmente diretórios amplos. Diagnóstico do motivo pelo qual o alvo foi rejeitado ou escolha uma ação mais estreita. A mesma regra aplica se quando a corrida seca revela mais do que o esperado. Se um operador quisesse limpar o estado de sessão, mas o plano inclui o espaço de trabalho, pare. Um plano destrutivo que atinge uma camada não aprovada é superado, mesmo que seja tecnicamente executável. Verificar o artefato de recuperação antes de excluir o estado A documentação de reset diz para executar openclaw backup create primeiro. A regra operacional mais forte é criar e verificar o arquivo: Escolha um destino privado com espaço suficiente, permissões adequadas, controle de criptografia e retenção. Os arquivos OpenClaw podem conter config, perfis de autores, credenciais de canal ou fornecedor, sessões, estado do plugin, bancos de dados e espaços de trabalho. Trate os com a mesma sensibilidade que o estado vivo. O Referência openclaw backup oficial documenta vários limites importantes: O arquivo contém um manifesto com fontes e layout resolvidos; Os arquivos existentes não são sobrecritos; são rejeitados os caminhos de saída dentro das árvores fonte de respaldo; Verificação das cargas úteis declaradas e segurança do percurso de arquivo; As bases de dados canônicas SQLite recebem verificações de forma, integridade e função; Os ficheiros de transcrição voláteis, log, socket, PID e ficheiros temporários podem ser ignorados; Os esquemas de propriedade do plugin podem permanecer opacos quando as suas capacidades definidas pelo proprietário não estiverem disponíveis. Essa última limitação é importante. Um arquivo verificado é muito mais forte do que existe um arquivo, mas não é uma prova universal de que todos os plugins podem ser restaurados em todos os hosts alvo. Cobertura de antevisão antes de escrever o arquivo: Na mesma instalação observada, o JSON listou o diretório de estado como o ativo de arquivo e marcou o espaço de trabalho aninhado como covered , em vez de listá lo como um segundo ativo. A contagem dos ativos teria dado a conclusão errada. Inscrever sourcePath , archivePath , coveredBy e ignorar as razões em vez disso. Para uma redefinição que possa remover espaços de trabalho, antes da aprovação, é necessário: O comando de backup foi concluído; A verificação do arquivo foi aprovada; O manifesto abrange o estado previsto e o espaço de trabalho; Os arquivos voláteis ignorados são aceitáveis para o objetivo de recuperação; O arquivo está fora do limite de exclusão; O operador pode identificar o procedimento de restauração; O destino de reserva está protegido. Porta o reset com nove casos inconvenientes A fixação sem conteúdo que acompanha verifica a decisão em vez de realizar qualquer redefinição. A sua classificação aplica esta prioridade: 1. rejeitar um âmbito de aplicação desconhecido; 2. Rejeitar um âmbito mais amplo do que a camada diagnosticada; 3. Requer uma corrida seca concluída; 4. exigir a resolução de todos os alvos previstos; 5. Requer um respaldo verificado; 6. Requer cobertura do espaço de trabalho para uma redefinição completa; 7. esperar a aprovação explícita; 8. Após a execução, verificar a configuração e a memória; 9. Verificar o resultado da tarefa prevista. Os resultados dos nove encontros foram: Todos os nove coincidiram com o estado esperado, e uma afirmação separada provou que um escopo destrutivo desconhecido não se fecha. A distinção entre os últimos três estados impede o falso sucesso. ready to reset significa o plano, o backup, o escopo e os portões de autoridade aprovados. Isso não significa que o reset já tenha acontecido. memory unverified significa execução concluída, mas faltam uma ou mais verificações após a redefinição. Só o verified reset requer também o resultado pretendido. Um recibo prático após a redefinição pode ficar livre de conteúdo: A presença de arquivos por si só é insuficiente. Verifique os arquivos duráveis esperados, depois teste a prontidão do índice e recupere um canário deliberadamente não sensível. Por fim, execute uma tarefa limitada cujo resultado pode ser verificado no seu destino. Uma resposta fluente não prova que a memória restaurada influenciou corretamente o trabalho pretendido. Sabem o que esta porta não pode provar A fixação valida os campos e a prioridade. Não executa OpenClaw, inspeciona o conteúdo da memória privada, restaura um arquivo em um segundo host ou descobre efeitos externos não documentados. Um real exercício de recuperação deve periodicamente restaurar em um destino isolado e testar o tempo de execução exato e os plugins que importam. Também não transforma todas as queixas de memória num incidente. Uma nova sessão pode legitimamente carecer de contexto de conversação não salvo. Um resultado de pesquisa pode ser vazio porque o fato nunca foi escrito. Um índice pode ser reconstrutivo. Estes são diferentes da exclusão duradoura da memória, e a incerteza deve permanecer visível até que a primeira camada falhada seja conhecida. A regra operacional é simples: preservar a memória fonte antes de reparar o estado derivado, preferir o menor limite suportado e exigir evidências após a ação. Nunca atualize o comando devolvido para o agente recuperado. A Sidewisp está atualmente em prévia privada. O seu adaptador de produção OpenClaw e o executor de recuperação não são geralmente enviados. O método aqui é um padrão de funcionamento inspecionável, não uma alegação de que o Sidewisp atualmente faz backup, redefine ou restaura instalações OpenClaw em funcionamento. A direção do produto da Sidewisp mantém o diagnóstico, a autoridade humana e os resultados verificados separados para que uma ação destrutiva não possa resolver um problema apenas porque foi executada.